Re: grohtml: confused about constant-width font handling

"G. Branden Robinson" <[email protected]> Fri, 23 Jan 2026 14:10:29 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260123201029.ozpk7om2jqjefbno@illithid>
At 2026-01-21T09:55:16+0000, Colin Watson wrote:
> On Tue, Jan 20, 2026 at 11:49:09AM -0600, G. Branden Robinson wrote:
> > At 2026-01-20T16:18:11+0000, Colin Watson wrote:
> > > - but doesn't any more.  What's going on?
> > 
> > The font name "C" is not portable and is now deprecated.
> 
> I think you misunderstand my "What's going on?" complaint.

Apparently so.  Sorry!

> If I could make out _how_ the combination of ".nf" and ".ft C" is
> having this effect on grohtml output, I might be able to get
> somewhere.  But I have entirely failed to trace the actual code,
> especially given that post-grohtml is explicitly special-casing the
> "CR" font to have what looks like a similar effect - but in a way that
> I haven't been able to get to work.

My guess is that it has to do with the MTSM, the mini-troff state
machine that is part of grohtml's design but which required an incursion
into the formatter itself.

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/mtsm.h?h=1.23.0
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/mtsm.cpp?h=1.23.0

This machinery is known to be buggy:

https://savannah.gnu.org/bugs/?65894 (fixed)
https://savannah.gnu.org/bugs/?64453 (open)

...but worse than that, it lacks a specification, is undocumented beyond
the Mulley/Lemberg white paper[1] that is aimed at an audience other
than groff users or developers, and has no supporting automated tests.

My **ROUGH** idea of how it works is:

Macro packages, and the formatter itself, can inject "tags" into the
grout command stream.  These are in the form of device extension
commands.  So far, so good.[2]  These tags, with names like EOL, BR, FI,
IN, LL, PO, RJ, SP, TA, and CE, serve to smuggle information about
*roff requests issued to the output device.  Moreover, the formatter
doesn't _simply_ pass these through, but for reasons I'm not clear on,
maintains a stack of these tags.  I don't know under what circumstances
the formatter pops the stack or clears/flushes it.  I also don't know if
the grohtml output driver also maintains a tag stack, because I haven't
looked closely enough to see.

My wild guess as to what's happening is that either the formatter or the
output driver is inspecting the tag stack and inferring that if `nf`
(not FI, I guess) and `ft C` (I don't know how this is
captured/represented as a tag) are in propinquity then what is "really
meant" is a "<pre>" region, and grohtml generates HTML elements
accordingly.

That's a hypothesis, and a hard one to test due to my gripes above.  So
take it with a shaker of salt.

> I'm explicitly not looking for an explanation of the typography at
> this time.  I'm just trying to figure out the code flow.

Let me know if I can be of assistance.  Beyond becoming an expert on
MTSM overnight, which isn't likely.

Regards,
Branden

[1] https://www.gnu.org/software/groff/grohtml.pdf
[2] Except the part about the formatter itself doing this, which I
    philosophically object to, but is necessary if you want to produce
    good HTML from "raw" *roff input.  I think that's a mistaken
    objective, because there's no demand for that.  Macro packages can
    inject any "tags" that are required.
signature.asc (application/pgp-signature, 833 B)