Re: "troff -a" is now communicating less information

"G. Branden Robinson" <[email protected]> Wed, 17 Dec 2025 10:06:34 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20251217160634.xyqruogxcncndsdo@illithid>
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 (application/pgp-signature, 833 B)