At 2026-01-28T20:49:25+0000, Deri wrote: > I agree with Bruno, the fix can wait. I'm not sure about this one > though, it seems to be only in current groff:- > > [derij@pip build (master)]$ echo "\X'pdf: xrev'"|groff -Tpdf -ms -Z > x T pdf > x res 72000 1 1 > x init > p1 > troff: src/roff/troff/input.cpp:3107: const char* > token::description(): Assertion `0 == "unhandled case of `type` > (token)"' failed. > groff: error: troff: Aborted (core dumped)
This specific problem is resolved. The assertion failure is fixed. However, an issue with "janky" output remains. It appears that a page location trap springs at once when the device extension command is processed, which defeats it and puts part of its text into the document. (Why not just have GNU troff internally shut off vertical position traps when processing device extension commands? See below.) > It only dumps if the -ms is included. It does not matter what text > appears in the \X command. As observed in Savannah #65977,[1] this issue (of "janky" output) also affects the me(7) and mm(7) packages. It probably _would_ affect mom(7) too, but mom (except in nroff mode) always starts a page no matter how minimal the input.[3] That turns out to matter. By the time you can hit the output with your `\X'pdf: xrev'`, the first page of the document has already begun. This is too big a stumper for me to handle for groff 1.24.0. There are several interlocking issues. * These packages (me, mm, ms) all configure page header traps (vertical position traps at vertical drawing position 0) upload being loaded. * '\X' is "formattable" text. As of groff 1.24.0, the presence of a `device` request is as well. This means it is a "productive input line", creating formattable output. * Does treating it thus make sense? Well, that depends on what `\X` does. Maybe it configures something in the output device that doesn't affect output of the document, like flashing a blue light on the printer's panel. Or maybe it changes paper trays.[4] * Or maybe the `\X` device extension _does_ affect output in the sense of "ink on the page". As with (arguably) `pdf: xref`. (Mirror- reversing glyphs doesn't change their metrics as far as the formatter is concerned, so in a sense this device extension command is nilpotent upon output; a human reader of a document with this command unexpectedly in effect might have some choice words for that interpretation.) Or, more obviously, `pdf: pdfpic`. * The question is: how is GNU troff supposed to _know_ which of the foregoing cases is true? The whole point of .device/\X is to punch through the formatter's floor and talk directly to the output device. When you do that, you accept responsibility for keeping the formatter's state consistent with that of the output device. * We've now arrived at Savannah #66187.[2] Fortunately I have a workaround. If the very first thing you want to do in a document is blast a device extension command to it, and you have already configured a vertical position trap within the first vee of the document--or a macro package has done so for you--then prefix that request or escape sequence with the `\&` (dummy character) escape sequence. So I think I'm going to treat Savannah #65977 as a documentation issue, and I'll attempt to summarize the foregoing in discussion of device extension commands. Long story short, do this instead. $ printf '\\&\\X"pdf: xrev"\n'|groff -Tpdf -ms -Z Regards, Branden [1] https://savannah.gnu.org/bugs/?65977 [2] https://savannah.gnu.org/bugs/?66187 [3] \# Instruct grops to use square linecaps and joins. \# This instruction is also executed in DO_B_MARGIN, NEWPAGE, and HEADER \# .if !n \X'ps: exec 0 setlinejoin'\X'ps: exec 0 setlinecap' A careful observer will note that this conditional, if its branch is taken, put a word space on the output (because that's how the newline after the device extension commands is interpreted when filling is enabled). [4] The traditional example was to instruct the device to pause in the middle of a job so that the operator could physically reconfigure the device. While manipulating paper trays is probably more familiar to us younger folks, I think the original Bell Labs troff application for pausing a device like the C/A/T phototypesetter was to permit an operator to change out the--my supposition here--microfiche-like plates in the slots of the typeface carousel--that is, to literally manipulate the "font mounting positions".) I've never seen a C/A/T, not even a photo of one, but after reading descriptions from various sources, my imagination conjures an intimidating Rube Goldberg (en_GB: Heath Robinson) contraption the size of a Peel P50, bolted to the floor in a metal drip pan like you'd use for an indoor HVAC unit but for collection of smelly and rabidly carcinogenic fluid, the entire apparatus a freakish combination of slide projector, pizza oven, and laundry mangle.
signature.asc
Description: PGP signature
