Update of bug #67992 (group groff):
Category: Macro package - others/general => Core
Item Group: Rendering/Cosmetics => Documentation
Summary: [me,mm,ms] janky output seen when user breaks
initialization rules with device extension command => warn users about how to
employ `\X` very early in a document
_______________________________________________________
Follow-up Comment #19:
Quoting [https://lists.gnu.org/archive/html/groff/2026-02/msg00025.html my own
post to the _groff_ list]...
... 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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67992>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
