Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

[G. Branden Robinson]

Hi Michał,

At 2023-04-06T19:41:44+0000, Michał Kruszewski wrote:
> So it is now explained why .bp is broken.  I am attaching yet another
> reproducer.  This time there is a problem with the .sp before
> Abstract.  In 1.23.0.rc3 this .sp is simply ignored, while in 1.22.4
> it is correctly applied.

While at first blush this problem seems analogous to the one with .bp, I
don't think it is, quite.

There are three issues I want to raise about it:

1. How other *roff and ms implementations cope with this input;
2. Whether it is, strictly, a valid ms document;
3. How closely its solution resembles the simple one to Savannah #64005.

So, first, given this input:

1a. nroff from groff 1.22.4 places the lines as follows:
      line  6: Title
      line 10: Revision 0.0
      line 12: date
      line 25: abstract
      line 27: lorem ipsum
      line 37: keywords
1b. nroff from groff Git places them as follows:
      line  7: Title
      line 10: Revision 0.0
      line 12: date
      line 14: abstract
      line 16: lorem ipsum
      line 26: keywords
1c. nroff from Heirloom Doctools troff places them as follows:
      line  8: Title
      line 11: Revision 0.0
      line 13: date
      line 26: abstract
      line 28: lorem ipsum
      line 38: keywords
      line 64: date (appearing again because .ND was not called)[1]
1d. nroff from DWB 3.3 troff places them as follows:
      line  9: Title
      line 12: Revision 0.0
      line 13: garbage[2]
      line 14: garbage[2]
      line 29: abstract
      line 31: lorem ipsum
      line 41: keywords

While groff Git is indeed a bit of an outlier in that it ignores your
.sp request after the date on your cover sheet, we can see that precise
control of positioning is not in the cards anyway with respect to this
input.

I put in some tracing:

diff --git a/tmac/s.tmac b/tmac/s.tmac
index 343b5024a..309be157c 100644
--- a/tmac/s.tmac
+++ b/tmac/s.tmac
@@ -109,6 +109,12 @@ along with this program.  If not, see 
<http://www.gnu.org/licenses/>.
 .      if \\n[@saved-no-space-mode] .ns
 .      rr @saved-no-space-mode
 ..
+.als @ns ns
+.de ns
+.      tm GBR: NS ENCOUNTERED
+.      backtrace
+.      @ns
+..
 .
 .de @init
 .if !rPO .nr PO \\n(.o

...and the output made it clear that, sure enough, your use of a display
to set your cover information caused essentially the same problem as
Savannah #64005 (the break page problem).

$ ./build/test-groff -z -ms ATTIC/michal-cover2.ms
GBR: NS ENCOUNTERED
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':115: macro 'ns'
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':644: macro 
'pg*start-col'
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':636: macro 'pg@top'
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':217: trap-called 
macro 'cov*first-page-init'
troff: backtrace: file 'ATTIC/michal-cover2.ms':1
GBR: NS ENCOUNTERED
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':115: macro 'ns'
troff: backtrace: '/.../src/GIT/groff/build/../tmac/s.tmac':1022: macro 'DE'
troff: backtrace: file 'ATTIC/michal-cover2.ms':12

[directory names edited for brevity]

This leads me to wonder whether it is kosher for an ms cover page to use
display macros.  Before answering "of course!  yes!", recall that the
display distance \n[DD] is supposed to be applied before and after all
displays (except at page boundaries) overriding and not accumulating
with inter-paragraph distance.  That is the lesson I learned from
re-typesetting the "Typesetting Mathematics" paper by Kernighan and
Cherry last year, and which prompted the changes that led your input to
grief with `bp` and `sp` requests.

Displays are conceived of in ms documentation (not just groff's, but
Lesk's original paper presenting it) as occurring in the main matter of
a document.  I am not certain it is appropriate to use them on a cover
page.

Strictly, I think the answer (is it kosher for a cover page to use
macros?  Or equivalently, is your cover page a valid ms document?) is
"no"--see the end of this mail--but in practice I propose that we can be
a bit flexible.

I tried modifying your document to remove the display but ensure that
the `ce` requests would apply to everything you originally had centered.
You were already using `ce` to center lines, so it is not clear to me
what purpose was being served with a centered display while
request-based centering was already in effect.

Please find the revised cover page attached.  I also eliminated the
mysterious (to me) `\c` escape sequence from the beginning.  I know
pretty well what that escape sequence _does_, but not why it appears in
your cover sheet.

nroff from groff Git places the output lines as follows:
      line  7: Title
      line 10: Revision 0.0
      line 12: date
      line 23: abstract
      line 25: lorem ipsum
      line 35: keywords

This is pretty close to what you had before, and furthermore, since it's
now all pure *roff requests, you should be able to tune the `sp` request
arguments to get things spaced exactly the way you want, and not have to
worry about ms's display distance \n[DD] messing things up.

The last point was this:

3. How closely its solution resembles the simple one to Savannah #64005.

I don't think there is likely to be an easy fix here, or at least not
one that looks just like the one to #64005.  When someone breaks a page
I know they want a page break, so it seemed reasonable to (temporarily)
shut off no-space mode to perform one.

But the whole point of no-space mode is to keep `sp` from doing things.
If I use a similar wrapper for `ns` that would mean making the no-space
mode request nilpotent...and breaking the macro package in multiple
respects.

I admit that `sp` is one of the only four *roff requests that Mike Lesk
documented as usable with the package.  (The full set was `bp`, `br`,
`sp`, and `na`.)  But I'll blaspheme here and venture that this set was
not rigorously arrived at.  Whither `de`, `ds`, and `nr`?  Lesk
explicitly mentions the last with respect to `PS`, and implies the use
of the first two when discussing header and footer strings and `PT` and
`BT` macro replacement.  And if `na` is okay, why not `ad`?

I think the take-away here is that ms(7) is not as rigorously specified
as some other typesetting projects.  There's never been a TRIP test for
it.  I don't have a resource I can turn to with those four different
renderings of your cover page at the beginning of this email such that I
can point to each on a line by line basis and declare them correct or
incorrect.  One would think this would be easy with simple `sp`
requests, but they're not so simple.  If you change the type size and/or
vertical spacing, then in nroff mode should unitless `sp` requests
place the text where it would go if the output device had infinite
vertical resolution, or just ignore all this stuff and count lines?
What if the vertical spacing is an exact multiple of the nominal amount
used by the output device?  Further, on a cover page, should initial
spacing be measured from the first vee on the page (as it would be in a
"raw" roff document, where ms(7) would normally place its header?

I don't doubt that we can come up with answers to all of these but I
don't think they are necessarily obvious, especially to *roff novices,
and I'm pretty sure they're not documented in any user's guide or
reference to ms that is widely available--I make this claim because I
have tried to obtain and read them all.

As a final point I will note that Lesk 1978 says this:

"Warning: You can't just begin a document with a line of text.  Some -ms
command must precede any text input.  When in doubt, use .LP to get
proper initialization, although any of the commands .PP, .LP, .TL, .SH,
.NH is good enough."

Strictly, this admonition would seem to foreclose customized cover
pages.  Happily, I think we might be able to support them anyway if
people stick to raw *roff requests (or their own macros) and break the
page when they're done.  I hope that my fix for Savannah #64005 will
realize this state of affairs.

Regards,
Branden

[1] This is a documented difference between groff ms and AT&T-descended
    ms.

[2] Due to a form of string interpolation that DWB *roff doesn't
    recognize.  Not really important for this issue.

michal-cover3.ms
Description: Troff MS-macros document

signature.asc
Description: PGP signature