bugGNU roff - Bugs: bug #64142, .spreadwarn undocumentedly...

 
 

bug #64142: .spreadwarn undocumentedly converts units to be relative to font size

Submitter:  Dave <barx>
Submitted:  Wed 03 May 2023 09:26:17 PM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Documentation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 09 Oct 2023 08:03:27 PM UTC, comment #1: 

original submission:

> Given what .spreadwarn does, this is a reasonable design, but
> surprising compared to how most roff requests work,


For instance, the .hys request also deals with the amount of stretch added to interword space, and also has ems as the default unit of its parameter, so it would be reasonable for groff to scale this value when the font size changes, but it does not.

$ groff << EOF
> .hys 0.3
> .tm .hys is \n[.hys]
> .ps 40
> .tm new font size: .hys is \n[.hys]
> .hys 0.3
> .tm new hys value: .hys is \n[.hys]
> EOF
.hys is 3000
new font size: .hys is 3000
new hys value: .hys is 12000


Dave <barx>
Group Member
Wed 03 May 2023 09:26:17 PM UTC, original submission:  

Experienced roff users expect requests that take numeric values with units to store those quantities in basic units, so that even if font-size-relative units were initially specified, subsequent changes to the font size do not change the magnitude of those stored values.

The .spreadwarn request appears to work in the opposite direction: even if its parameter is specified as an absolute value (e.g., in inches), it seems to be stored as a font-relative one, so that it scales to the current font size.  Examples below illustrate this.

Given what .spreadwarn does, this is a reasonable design, but surprising compared to how most roff requests work, so should be documented.

.spreadwarn is a groffism, though Heirloom troff has also implemented it.

(Not relevant to this issue, but linked here since I chased it down before opening this bug: the .spreadwarn documentation was recently updated in response to bug #58035.)

Examples


$ cat spreadwarn_scaling
.spreadwarn 1
.ll 70p
one two three\p
.ll 75p
one two three\p
.ps 40
.ll 290p
one two three\p
.ll 300p
one two three\p
$ groff -a spreadwarn_scaling
<beginning of page>
one two three
troff: spreadwarn_scaling:5: warning [p 1, 0.2i]: spreading 1.0335m per space
one two three
one two three
troff: spreadwarn_scaling:10: warning [p 1, 0.5i]: spreading 1.0335m per space
one two three

The lack of a warning above about the third output line is mildly surprising, given the way many requests taking a parameter in ems (.spreadwarn's default) store it as an absolute value.  But more surprising (to me) is that this still holds when explicitly providing an invariant unit as the parameter:

$ sed 's/spreadwarn 1/spreadwarn 0.14i/' spreadwarn_scaling | groff -a
<beginning of page>
one two three
troff: <standard input>:5: warning [p 1, 0.2i]: spreading 1.0335m per space
one two three
one two three
troff: <standard input>:10: warning [p 1, 0.5i]: spreading 1.0335m per space
one two three

Both 40-point output lines have well over 0.14 inches of space added, but still only the last gets the warning, as only that one exceeds the threshold in ems.

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code