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