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
Description: PGP signature
