bugGNU roff - Bugs: bug #60707, [troff] want...


bug #60707: [troff] want configurable/predictable adjustment direction in typeset output

Submitter:  Dave <barx>
Submitted:  Mon 31 May 2021 12:03:01 AM UTC
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 31 May 2021 07:11:12 PM UTC, comment #2: 

Good point!  Changed now.

Dave <barx>
Group Member
Mon 31 May 2021 12:24:56 PM UTC, comment #1: 

This wish probably needs renaming since it is clear from the information in comment #1 that the problem is not with grops which produces the postscript but with groff which produces the intermediate file which grops reads.

Deri James <deri>
Group Member
Mon 31 May 2021 12:03:01 AM UTC, original submission:  

A groff behavior has mystified me for many years, but never enough for me to delve into its cause.

The mystery is this.  Periodically I would make some change to the underlying troff code of a document that had no visible effect on the rendered page.  Yet there would be a huge number of changes in the generated PostScript code, every one of them some page movement changing by exactly one one-thousandth of a point, or one "basic unit" for the PostScript device, or a bit over .00001 inches.  In other words, effectively no change.  But any actual (visible) changes that might also have happened were obscured by all these false positives.

At last, thanks to Branden's analysis in bug #60665, I know what's been happening: Something changed the pattern of the "direction" that lines were adjusted.  Each subsequent line was then adjusted in the opposite "direction" from what it was before, causing a raft of invisible changes from that point on.

It turns out, once you know the mechanism, that the effect is easy to illustrate, using the observation (from bug #57836) that a diversion, even if never output, still affects the direction of adjusting.

Consider this example file.

$ cat honest_men
.ll 3i
.di ignore-me
S.O.S. and red alert, all across the universe, calling all honest men.
S.O.S. emergency, sinking fast and getting worse, where's your honest men?

It defines, but never uses, a diversion, then outputs text that spans two output lines, the first of which gets adjusted.

But the very act of defining the unused diversion changes the reversal pattern of the adjustment algorithm.  For comparison, remove the diversion definition, and output the same text.  This results in the following PostScript code diffs:

$ diff <(groff honest_men) <(sed '/^\.di /,/^\.di$/d' honest_men | groff)
< /F0 10/Times-Roman@0 SF 2.913(S.O.S. emer)72 12 R(genc)-.18 E 4.213 -.65
< (y, s)-.15 H 2.913(inking f).65 F 2.914(ast and getting w)-.1 F(orse,)
> /F0 10/Times-Roman@0 SF 2.914(S.O.S. emer)72 12 R(genc)-.18 E 4.214 -.65
> (y, s)-.15 H 2.913(inking f).65 F 2.913(ast and getting w)-.1 F(orse,)

The only differences in the output are in the thousandths place of the horizontal movements: 2.913 becoming 2.914, 4.213 becoming 4.214, and so forth.  Similar "changes" are visible in diffs of groff's intermediate output ("groff -Z"), so Deri's suggestion in bug #60655 is no help here.

It would be better if groff didn't inject invisible changes into output.  And it seems to be a conceptually simple fix: distribute_space() simply needs to be aware, or told by its caller, whether the granularity of the space it's adjusting is visible without a microscope and a ruler with nanometer marks, and choose whether to do its alternate-line-reversing trick accordingly.

(This, incidentally, simplifies Branden's dilemma in bug #60665 of how to describe this reversal algorithm to the documentation reader without bogging down in implementation details for devices where this algorithm produces no visible effect.  Get rid of invisible effects, and the documentation no longer has to worry about it.)

Dave <barx>
Group Member


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

Attach Files:

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 gbranden (Updated the item)
  • -email is unavailable- added by deri (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-21 gbranden SummaryRequest predictable adjustment in typeset output [troff] want configurable/predictable adjustment direction in typeset output
    2021-05-31 barx SummaryRequest predictable PostScript output Request predictable adjustment in typeset output

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code