Hi Deri, At 2026-09-02T00:27:16+0100, Deri via discussion of the GNU roff typesetting system and related software wrote: > On Tuesday, 1 September 2026 17:11:22 British Summer Time G. Branden > Robinson wrote: > > At 2026-08-31T13:48:32+0100, Deri wrote: > > > 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. > > 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.
That turns out to be true. I can document only my intentions, and results I have _measured_ in commit and change logs. How might we measure groff mm's behavior better, you might ask? By writing more test scripts for it. The skills necessary to do so are not esoteric; while POSIX shell is not the most pleasant language on Earth (nor are C and C++), the knowledge required to contribute a test script groff is not, in my opinion, large. It's easy to copy a script I've written, and if something about the copied logic sucks...well, I'm easy to find and allocate blame to. :) Thus, anyone who wants to see me make fewer mistakes when refactoring, trivially or otherwise, knows how they can help. The jargon for these practices is "fail fast principle" and "test-driven development". > > 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. Right, yes. The reason using a string works--now, sort of--is because it "defers" interpretation of the argument until it's handed to the formatter in a numeric expression context. One reason I don't endorse reverting the commit as a fix (cf. a diagnostic tool, for which it's clearly useful) is that a bogus macro argument won't necessarily be diagnosed until later, after the macro package gets around to "using" it by constructing a request. If that usage is not immediately within the macro call that the user made, then it works like many frustrating memory corruption bugs in C or C++--the place where things "blew up" can be a long way from where the invalid operation occurred. In software generally, I favor draconian input validation at the earliest possible point so that the user gets a clearer idea where they went wrong, instead of clattering along until one demands the impossible. > > 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. Indeed it is, and that's why I filed <https://savannah.gnu.org/bugs/?68667>. > > 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. A less esoteric workaround might simply be to slightly extend the page length...while I suspect issuing a `pl` request is unlikely to work well, setting the `L` register on the command line is supposed to be idiomatic. Here are Ingo's instructions, from his mm document source. .\" Build instructions: .\" groff -st -mm -mpresent talk.roff > talk.pps .\" presentps -l talk.pps > talk.ps .\" ps2pdf talk.ps For the foregoing reason, and because soelim(1) appears unnecessary (there are no `so` requests in the document), I drop the `-s` option. $ groff -t -r L=12i -mm -mpresent talk.roff > talk.ps.in $ presentps -l talk.ps.in > talk.ps $ ps2pdf talk.ps For groff 1.26, I hope we can replicate your ms(7) PDF work in mm(7) and turn 3 commands into one. > > 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 Looks clean to me! I'll be delighted if we can bring PDF features to the me(7) and mm(7) packages for 1.26. Regards, Branden
signature.asc
Description: PGP signature
