Hi Deri, At 2026-08-31T13:48:32+0100, Deri wrote: > On Saturday, 22 August 2026 17:12:43 British Summer Time Ingo Schwarze > wrote: > > I think the best example i have is this one: > > > > https://www.openbsd.org/papers/eurobsdcon2018-mandoc.roff > > https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf [...] > I tested this out using git master and unfortunately it is not working > correctly, it looks like the commit 0afa651fd in 2024 to BVL > converting a string register to numeric is the culprit. This is the > patch I used to get .LI working properly:-
You've found a bug, but a reversion is not the correct fix. I maintain that the commit was valid. Here's the change: https://lists.gnu.org/archive/html/groff-commit/2024-07/msg00020.html My retyping of the internal datum `li*text-indent` from string to register was deliberate, because that datum is passed down through further layers of macro processing (namely, `LB`) to the formatter _as a register value_. If the argument to the `BVL` macro is syntactically invalid as a register value, we want to know it. Consider the following exhibit: $ cat ATTIC/BVL-lists.mm .P Hello, world! .BVL 10 .LI alpha 2 neutrons and 2 protons .LI beta an electron .LI gamma a photon, usually highly energetic .LE .P Next paragraph. .BVL foobar .LI delta a small increment of the independent variable .LI epsilon a small increment of a dependent variable .LE Now let's put groff mm to work on it: $ ~/groff-1.23.0/bin/nroff -mm ATTIC/BVL-lists.mm -z 2>&1 | grep . || echo NO DIAGNOSTICS NO DIAGNOSTICS $ ~/groff-1.24.0/bin/nroff -mm ATTIC/BVL-lists.mm -z 2>&1 | grep . || echo NO DIAGNOSTICS troff:ATTIC/BVL-lists.mm:14: error: ignoring invalid numeric expression starting with character 'f' Thus, groff 1.24 mm helps the document author to locate and correct defects in their use of macros. Here's the description of this GNU extension to DWB mm. groff_mm(7): Except where noted, mm assumes that horizontal measurements are reckoned in ens (scaling unit n) and vertical ones in vees (scaling unit v). groff mm permits use of non‐integral typographical points (scaling unit z). Use explicit scaling units for clarity and predictable behavior. ... BVL [text‐indent [mark‐indent [1]]] Begin broken variable‐item (or “tagged”) list. Each item should supply its own mark. The line is always broken after the mark; contrast VL. A text‐indent argument overrides register Pi; mark‐indent sets the distance from the indentation of the current list to the mark. A third argument suppresses the vertical space that normally precedes each list item; see register Lsp. Vertical space in the amount of Lsp precedes the list itself, but does not accumulate with pre‐item space when this list is nested in another. BVL calls LB; use LI to declare list items, and LE to end the list. However, that last sentence in the first quote reveals a problem, and this is the bug you found. I think traditionally, mm authors tend _not_ to specify units, since DWB mm inculcated a doctrine of "ens and vees only".[1] What we need here is to use groff's extended syntax for interpolating numeric quanities with an "implied" scaling unit. groff_diff(7): Numeric expressions GNU troff permits spaces in a numeric expression within parentheses, and offers three new operators. e1>?e2 Interpolate the greater of expressions e1 and e2. e1<?e2 Interpolate the lesser of expressions e1 and e2. (c;e) Interpolate expression e using c as the default scaling unit, ignoring scaling units in e if c is empty. Arithmetic in GNU troff saturates instead of wrapping. I've known that groff mm needed "porting" to use `(c;e)` in more places, as Jörgen Hägg didn't exercise that operator (much?) initially, but I wasn't aware of any specific places where leaving it out caused a problem. Now I am, so I'll fix it. Changing one line of my input exhibit manifests the problem. $ diff -u ATTIC/BVL-lists.mm ATTIC/BVL-lists-busted.mm --- ATTIC/BVL-lists.mm 2026-09-01 09:54:38.159256301 -0500 +++ ATTIC/BVL-lists-busted.mm 2026-09-01 10:32:17.038845525 -0500 @@ -1,6 +1,6 @@ .P Hello, world! -.BVL 10 +.BVL 10n .LI alpha 2 neutrons and 2 protons .LI beta $ nroff -mm ATTIC/BVL-lists-busted.mm -z troff:ATTIC/BVL-lists-busted.mm:4: warning [page 1, line 10]: cannot adjust line; overset by 180n troff:ATTIC/BVL-lists-busted.mm:5: warning [page 1, line 11]: cannot adjust line; overset by 181n troff:ATTIC/BVL-lists-busted.mm:5: warning [page 1, line 12]: cannot adjust line; overset by 188n troff:ATTIC/BVL-lists-busted.mm:5: warning [page 1, line 13]: cannot adjust line; overset by 183n troff:ATTIC/BVL-lists-busted.mm:5: warning [page 1, line 14]: cannot adjust line; overset by 181n troff:ATTIC/BVL-lists-busted.mm:5: warning [page 1, line 15]: cannot adjust line; overset by 187n troff:ATTIC/BVL-lists-busted.mm:6: warning [page 1, line 17]: cannot adjust line; overset by 180n troff:ATTIC/BVL-lists-busted.mm:7: warning [page 1, line 18]: cannot adjust line; overset by 182n troff:ATTIC/BVL-lists-busted.mm:7: warning [page 1, line 19]: cannot adjust line; overset by 188n troff:ATTIC/BVL-lists-busted.mm:8: warning [page 1, line 21]: cannot adjust line; overset by 180n troff:ATTIC/BVL-lists-busted.mm:9: warning [page 1, line 22]: cannot adjust line; overset by 181n troff:ATTIC/BVL-lists-busted.mm:9: warning [page 1, line 23]: cannot adjust line; overset by 187n troff:ATTIC/BVL-lists-busted.mm:10: warning [page 1, line 24]: cannot adjust line; overset by 187n troff:ATTIC/BVL-lists-busted.mm:10: warning [page 1, line 25]: cannot adjust line; overset by 186n troff:ATTIC/BVL-lists-busted.mm:10: warning [page 1, line 26]: cannot adjust line; overset by 189n troff:ATTIC/BVL-lists-busted.mm:14: error: ignoring invalid numeric expression containing character 'f' Ingo's document manifests the same problem, and because older versions of GNU troff did not diagnose garbage in numeric expressions, the formatter did not assist him. $ grep BVL eurobsdcon2018-mandoc.roff .BVL 1c .BVL 1cm .BVL 1cm .BVL 1cm .BVL 1cm .BVL 1cm .BVL 1c .BVL 1c .BVL 1cm $ echo '.nr a 10cm' | ~/groff-1.23.0/bin/nroff -ww 2>&1 | grep . \ || echo NO DIAGNOSTIC NO DIAGNOSTIC $ echo '.nr a 10cm' | ~/groff-1.24.0/bin/nroff -ww 2>&1 | grep . \ || echo NO DIAGNOSTIC troff:<standard input>:1: warning: expected end of line or an auto-increment argument in register definition request; got character 'm' I point out that no _behavior_ change arises from the above; in the past, GNU troff behaved like AT&T troff and _silently_ stopped interpreting a numeric expression as soon as it read a character that was invalid therein. Now, GNU troff diagnoses the invalid character if the user enables warnings in category `number`. That permits the user to more readily infer the change of parser state that results. > A more minor issue (which I did not pursue) is that the last line of > page 5 no longer fits on the page and is thrown to a new page. The document doesn't explicitly identify a paper format in its rendering instructions. Canada traditionally uses U.S. letter paper. (Maybe that will change now thanks to my Tech Bro President.[2]) The following documented 1.24 change could also be responsible, alone or in combination with the foregoing.[3] * The m (mm) macro package now uses a 3v bottom margin rather than 2v. (Using the default type size and vertical spacing, the result is a half-inch margin, just like the existing top margin.) When formatting for terminals, content aligned to the bottom of the page (footers, footnotes, `BS`/`BE` bottom blocks, and similar) now sets one line higher than before. Further, the margin between the body text and any page footers is now 2v, like that between the body text and page headers, not 1v. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.24.0#n587 > I don't know whether the problems are deliberate changes of behaviour > or unintentional. I also tested whether gropdf could produce the > document (without presentps, but with ".pdftransition SLIDE Wipe 1 H" > added), the result is here:- > > https://chuzzlewit.co.uk/eurobsdcon2018-mandoc.pdf[...] > > This also shows the minor problem of page 5 (which also occurs with > current grops/presentps as well). Apart from that I see no gross formatting problems (which is a relief!), but I do observe that the slide content is much longer and "denser" (i.e., many more words on each slide or "foil") than is idiomatic in environments I'm used to. But BSD convention culture may differ, so it's not necessarily a problem. I note that the historical mv(7) "viewgraph" package for presentations, which refers to a nearly forgotten technology for photographic transparency preparation and goes all the way back to the AT&T USG in the 1970s, used media formats in landscape orientation and markedly smaller than either U.S. letter or ISO A4 paper.[4] I note that economist Paul Krugman's slide deck style[5] should be well within groff mm's capabilities. :) It looks like there might have been overflow of Ingo's "thanks" slide (pp. 59-60), but I didn't bother to check if that was true with groff 1.23 rendering as well. And for some reason the top line of the title on the very first slide ("Better documentation") seems incorrectly centered. Regards, Branden [1] https://tkurtbond.github.io/troff/mm-all.pdf [2] https://www.politico.com/news/2025/10/23/trump-ballroom-donors-list-00620230 https://www.forbes.com/sites/kylemullins/2026/05/04/the-billionaire-donors-behind-trumps-midterm-superweapon/ [3] In nroff mode, one gets a page length of 66v on U.S. letter paper and 70v on ISO A4 paper (when both are in portrait orientation). [4] https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/lib/macros/vmc [5] https://www.nobelprize.org/uploads/2018/06/krugman-slides.pdf
signature.asc
Description: PGP signature
