At 2025-12-16T17:25:52+0000, Deri wrote: > I had difficulty understanding Branden's response, particularly the claim > "<--->" is "meaningful" (by claiming it is not meaningless).
It tells you that the device's glyph for the special character that renders at that point in the input has no name. ...a significant fact, in my opinion, since most fonts' glyphs _do_ have names. > The output from '-a' previously was a diagnostic tool concerning the > users input, rather than what groff will send to the output driver. I dispute this. '-a' never told you which of the user's macros or string definitions were being interpolated at any point, either. If you look at DWB 3.3 troff's '-a' output for documents that employ device extension commands, you find telltale disclosures thereof. $ pwd /home/branden/src/GIT/DWB3.3 $ dwb troff -a -mm tests/mm_tests/mm02 | grep -C1 '^\\X' | head -n 20 \XINFO:[SECTION: LEVEL = 1, NUMBER = 1. , HEADING = PARAGRAPHS AND HEADINGS] 1. PARAGRAPHS AND HEADINGS -- \XINFO:[SECTION: LEVEL = 2, NUMBER = 1.1 , HEADING = Paragraphs] 1.1 Paragraphs -- \XINFO:[SECTION: LEVEL = 2, NUMBER = 1.2 , HEADING = Numbered Headings] 1.2 Numbered Headings -- \XINFO:[SECTION: LEVEL = 3, NUMBER = 1.2.1 , HEADING = Normal Appearance.] 1.2.1 Normal Appearance. The normal appearance of headings is as shown in this document. The effect of .H varies according to the level argument. First-level headings are preceded by two blank lines (one -- \XINFO:[SECTION: LEVEL = 3, NUMBER = 1.2.2 , HEADING = Altering Appearance of Headings.] 1.2.2 Altering Appearance of Headings. Users satisfied with the default appearance of headings may skip to the section titled ``Unnumbered Headings''. One can modify the appearance of headings quite easily by -- DWB and Heirloom do similarly with drawing commands. First I'll use nroff to demonstrate that the input is not ill-formed. $ printf '.nf\n.sp\nbefore line and circle\n\\D!l1m1m!\\D!c1m0!\nafter line and circle\n' | heirloom nroff | cat -s before line and circle after line and circle $ printf '.nf\n.sp\nbefore line and circle\n\\D!l1m1m!\\D!c1m0!\nafter line and circle\n' | dwb troff -a before line and circle \Dl. \D\Dc0 \D after line and circle $ printf '.nf\n.sp\nbefore line and circle\n\\D!l1m1m!\\D!c1m0!\nafter line and circle\n' | heirloom troff -a before line and circle \Dl. \D\Dc. \D after line and circle My view is that "approximate output" is an effort to present the interested user with something easier to digest than the device-independent output format--which is nevertheless a pretty simple format. I've nursed ambitions to make it _more_ readable, meeting some resistance from you. https://savannah.gnu.org/bugs/?64360 That ticket has been awaiting your feedback for over two years. > This is another example of the > change:- [snip] > The first example (1.23.0) is showing the input and the second (git > HEAD) shows what would be sent to the output driver. Given this change > in behaviour, Branden's claim that "trademark" (in Dave's original > example) has no sense to an output driver is correct (so has to be > shown as '---'), but -a has always reported the input side, before > groff converts to the groff font glyph name. In 2019, Dave considered that a bug, and once I developed sufficient understanding of GNU troff internals to form an opinion, I agreed with him. > I don't know whether reverting to reporting the input is > insurmountably difficult, but Branden's example of using .pline to > discover the input shows that the information is certainly still held > and could be output within the "<> rather than "---". Output how? Can you contrive an unambiguous syntax that can represent both the name of the special character (at this point "a composite node") expanded and the representations of its contents? Don't forget that every printable ASCII character is valid in a troff identifier. Regards, Branden
signature.asc
Description: PGP signature
