bugGNU troff - Bugs: bug #58581, [PATCH] doc/groff.texi,...

 
 

bug #58581: [PATCH] doc/groff.texi, man/groff_font.5.man: spacewidth value is missing units

Submitted by:  Dave <barx>
Submitted on:  Tue 16 Jun 2020 07:04:59 AM UTC  
 
Category:  Font devps Severity:  3 - Normal
Item Group:  Documentation Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.6