On Tuesday, 1 September 2026 17:11:22 British Summer Time G. Branden Robinson wrote: > 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.
Hi Branden, I suspected as much, since the change was obviously deliberate, but a little bit more than a "trivial refactor" since it changed behaviour as well. > 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. Or complain when its value is attempted to be used as a register value. > 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 1c" is using an explicit unit. > 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]) I believe the 'presentps' script includes a CropBox in the postscript which ps2pdf uses to create the pdf, and the cropped size is 720,540 (approx Landscape Executive). Using gropdf to produce a similar size I had to include "-P-p7.6i,10i" and a ".po 1.8c" to achieve similar results > 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. This is the same as the p5/6 overflow I mentioned above, probably the same reason, 1v less before footer, although it looks like it definitely would fit in the space. In this document setting pg*below-text-gap to 0 (line 1395 of m.tmac) stops both "overflows" happening. > And for some reason the top line of the title on the very first slide > ("Better documentation") seems incorrectly centered. I put the .po 1.8c in the wrong place (after .TITLE). New version of the presentation (with fixes) using -Tpdf installed:- https://chuzzlewit.co.uk/eurobsdcon2018-mandoc.pdf Cheers Deri > Regards, > Branden > > [1] https://tkurtbond.github.io/troff/mm-all.pdf > [2] > https://www.politico.com/news/2025/10/23/trump-ballroom-donors-list-0062023 > 0 > 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
