[bug #60707] Request predictable PostScript output

[Dave]

URL:
  <https://savannah.gnu.org/bugs/?60707>

                 Summary: Request predictable PostScript output
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Sun 30 May 2021 07:03:01 PM CDT
                Category: Core
                Severity: 1 - Wish
              Item Group: New feature
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

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.
.br
.di
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)
233,234c233,234
< /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.)




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60707>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/