bugGNU roff - Bugs: bug #58581, doc/groff.texi,...

 
 

bug #58581: doc/groff.texi, man/groff_font.5.man: spacewidth value has incorrect units

Submitter:  Dave <barx>
Submitted:  Tue 16 Jun 2020 07:04:59 AM UTC
   
 
Category:  Font - others/general Severity:  3 - Normal
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 26 Sep 2021 06:37:00 AM UTC, comment #15: 


comment #14:

> Commit 5b60f113 seems to resolve all the remaining issues associated with this bug report.  Will close it if there are no objections.


Thanks for the prompt.  I'll wrestle the `sizescale` beast at another time.

G. Branden Robinson <gbranden>
Group administrator
Sat 25 Sep 2021 06:34:17 PM UTC, comment #14: 

Commit 5b60f113 seems to resolve all the remaining issues associated with this bug report.  Will close it if there are no objections.

Dave <barx>
Group Member
Fri 30 Jul 2021 06:35:29 AM UTC, comment #13: 

comment #12:

> So actually the unit for spacewidth is correct, but its value is
> based on the prerequisite of type size having the value "unitwidth".


That definitely clarifies things, though I don't think the documentation made this entirely clear, even if it was technically correct under that prerequisite.

Commit 7ae6d67b remedies this and explains it quite clearly, I think.  I would say it resolves this bug, though in its log message, Branden says he wants to expand the scope slightly to include a related attribute.

The commit does have one very small punctuation issue.  This sentence is added to both the Texinfo manual and to groff_font(5):

"groff achieves this using the system pioneered by AT&T device-independent troff; one size of a font is chosen as a norm, and all other sizes are scaled linearly relative to that basis."

However, the version in Texinfo is missing the semicolon, creating a run-on sentence.  A minor quibble to a fine explanation.

Dave <barx>
Group Member
Sun 25 Jul 2021 02:22:35 PM UTC, comment #12: 


comment #10:

> Hi Bjarni,
>
> comment #4:
> >   I read the definition of "unitwidth", so then I understood, that the
> > numbers in the font files are relative(!) to the "unitwidth" value.
> >
> >   So the actual size of a space is "spacewidth / unitwidth" part of the
> > point size of the font.
>
> This reasoning does not work for, e.g., the utf8 device.
>


  It does work.

Read the information about the "unitwidth".
Values in the font files are "normalized" with the value of "unitwidth".
So the formula is:

current spacewidth = spacewidth(font file) * (current type size) /
unitwidth

>
> Your formula would give an actual size of a space on the utf8 device of 2.4 times the point size.
>

 And the type size is a single value "10 s" = "10 p".

  So actually the unit for spacewidth is correct, but its value is based on the prerequisite of
type size having the value "unitwidth".

Bjarni Ingi Gislason <bjarniig>
Wed 21 Jul 2021 08:38:32 PM UTC, comment #11: 

To resolve this I need to properly understand the hocus pocus behind most of the measurements in DESC and font description files.

An expression like "inches/resolution" is pretty much impossible for me to fathom.  Since no one argues the claim that device resolution "res" is in basic units per inch, the aforementioned expression ends up being in square inches per basic unit.

That is unintelligible to me.  Even if it ultimately makes sense as a suggestion of how a font is scaled, a person should not have to bust out multiplication of fractions with cancellation arrows on the units to persuade themselves that they can understand these file formats.

G. Branden Robinson <gbranden>
Group administrator
Tue 20 Jul 2021 10:42:32 PM UTC, comment #10: 

Hi Bjarni,

comment #4:

>   I read the definition of "unitwidth", so then I understood, that the
> numbers in the font files are relative(!) to the "unitwidth" value.
>
>   So the actual size of a space is "spacewidth / unitwidth" part of the
> point size of the font.


This reasoning does not work for, e.g., the utf8 device.


$ grep unitwidth font/devutf8/DESC.proto
unitwidth 10
$ grep spacewidth font/devutf8/R.in
spacewidth 24


Your formula would give an actual size of a space on the utf8 device of 2.4 times the point size.

As it turns out the space width on the utf8 device is, as one would guess, 1 em.


$ ./build/test-groff -b -ww -Tutf8
.nr m \w'm'
.nr s \w' '
.tm m:\nm space:\ns
m:24 space:24


However, the horizontal resolution of this device is also 24, which exactly matches the space width.


$ grep hor font/devutf8/DESC.proto
hor 24


I think I'm going to go study CSTR #54 and #97; our own documentation really does not do a good job here IMO.

G. Branden Robinson <gbranden>
Group administrator
Tue 20 Jul 2021 10:27:42 PM UTC, comment #9: 

Chewing on this now.  I finally cleared my deck of a troff(1) man page revision I've been working on for ever.

G. Branden Robinson <gbranden>
Group administrator
Tue 20 Jul 2021 05:27:56 AM UTC, comment #8: 

comment #7:

> I had forgotten this ticket even existed.


This is why you keep me around.

The aforementioned commits have obsoleted the attached patch.

Dave <barx>
Group Member
Sun 18 Jul 2021 09:28:58 PM UTC, comment #7: 


comment #6:

> Commit 52a296a5 has changed doc/groff.texi, and commit a1366f79 man/groff_font.5.man, to say spacewidth is in "basic units."  This also does not match the behavior noted in previous comments, and moreover would, as Bjarni notes, result in a space whose width does not scale with the type size.


Oops.  I was unsure about this, consulted the source code, and thought I understood it.  I had forgotten this ticket even existed.

Thanks, I'll have a fresh look.

G. Branden Robinson <gbranden>
Group administrator
Sun 18 Jul 2021 09:19:54 PM UTC, comment #6: 

Commit 52a296a5 has changed doc/groff.texi, and commit a1366f79 man/groff_font.5.man, to say spacewidth is in "basic units."  This also does not match the behavior noted in previous comments, and moreover would, as Bjarni notes, result in a space whose width does not scale with the type size.

Dave <barx>
Group Member
Sun 29 Nov 2020 07:51:26 PM UTC, comment #5: 

comment #4:

>   Actually the "spacewidth" can't have any absolute unit,
> as it must apply to any point size of a font;
> that is, a 10 point font must have a smaller space width than a 50
> point font.


Yes.  This is why I used the units of m in my original post.

>   I read the definition of "unitwidth", so then I understood, that the
> numbers in the font files are relative(!) to the "unitwidth" value.
>
>   So the actual size of a space is "spacewidth / unitwidth" part of the
> point size of the font.


This bug concerns end-user documentation.  Such documentation should state the unit as concisely as possible, without sacrificing any accuracy.  The internals of how groff arrives at this unit are unimportant to end users.

Are there any situations where this calculation results in something other than a unit of 1/1000 of an m for spacewidth?

Dave <barx>
Group Member
Thu 26 Nov 2020 11:19:27 PM UTC, comment #4: 

 
  Yes, the unit can't be absolute scaled points.

  Actually the "spacewidth" can't have any absolute unit,
as it must apply to any point size of a font;
that is, a 10 point font must have a smaller space width than a 50
point font.

  I read the definition of "unitwidth", so then I understood, that the
numbers in the font files are relative(!) to the "unitwidth" value.

  So the actual size of a space is "spacewidth / unitwidth" part of the
point size of the font.

  In the case of ps- and pdf-fonts it is 250/1000, 1/4 part of the point
size of the font, or (1/4)m, as you already have found out.

  Or

  The text about "sizescale" says:

"The arguments to the unitwidth and sizes commands are given in scaled
points."

  So, if "unitwidth" has an unit (s), then "spacewidth" has the same
unit, as the quotient of them must be dimensionless.

Bjarni Ingi Gislason <bjarniig>
Wed 25 Nov 2020 10:33:27 PM UTC, comment #3: 

comment #2:

>   The unit is "scaled points" (s).


That does not match observed behavior.  In -Tps or -Tpdf output, a 0.25m space visually matches the default space; a 250s space is substantially smaller.  Witness:


.nf
M M M M M M M
M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M
M\h'250s'M\h'250s'M\h'250s'M\h'250s'M\h'250s'M\h'250s'M


Dave <barx>
Group Member
Wed 25 Nov 2020 07:00:44 PM UTC, comment #2: 

  The unit is "scaled points" (s).

  One point (p) = "scalesize"s.

  See groff(7).

Bjarni Ingi Gislason <bjarniig>
Tue 27 Oct 2020 11:26:57 AM UTC, comment #1: 

If my analysis is correct, the attached patch gives a possible fix.

doc/groff.texi fully explains the unit "em" elsewhere, so I've no hesitation using it in the "spacewidth" section.  But this patch intoduces the term to man/groff_font.5.man without ever defining it.  This might be OK, or a bit more explanation might need to be added here.

(file #50134)

Dave <barx>
Group Member
Tue 16 Jun 2020 07:04:59 AM UTC, original submission:  

Both doc/groff.texi and man/groff_font.5.man document a key in the font file called "spacewidth" by saying only: "The normal width of a space is n."  This leaves the reader wondering: n what?

Looking at the values of spacewidth in the various prepackaged font files:


grep ^spacewidth font/devps/*


leads only to more questions.  The space in TR being (as I understand it) 0.25m, the spacewidth value of 250 implies the unit is 1/1000 of an m (or 1/10 of an M).

But CR has a spacewidth value of 600.  Being a monospace font, the space should have the same width as every other character in the font, which by definition should be 1m, not 0.6m.

Nonetheless, experimentally, the TR space does appear to be 0.25m and the CR space 0.6m:


.nf
M M M M M M M M M M
M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M\h'0.25m'M
.fam C
M M M M M M M M M M
M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M\h'0.6m'M


Really, the info file and groff_font(5) should just tell me the units so I don't have to guess and/or experiment.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50134:  spacewidth.patch added by barx (704B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-05 gbranden CategoryFont devps Font - others/general
    2021-09-26 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2021-07-20 gbranden StatusNeed Info In Progress
        Assigned toNone gbranden
    2021-07-20 barx Summary[PATCH] doc/groff.texi, man/groff_font.5.man: spacewidth value is missing units doc/groff.texi, man/groff_font.5.man: spacewidth value has incorrect units
    2020-11-29 gbranden StatusNone Need Info
    2020-10-27 barx Attached File- Added spacewidth.patch, #50134
        Summarydoc/groff.texi, man/groff_font.5.man: spacewidth value is missing units [PATCH] doc/groff.texi, man/groff_font.5.man: spacewidth value is missing units

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code