At 2026-01-20T16:18:11+0000, Colin Watson wrote: > Further confusion with groff 1.23.0. ".nf" then ".ft C" results in > <pre>.
Taken together, that almost makes sense. But only almost. This was a bad idea because disabling filling does not have the same semantics as HTML's <pre>, even if you ignore font selection issues. (At which point someone says "what? there are semantics other than the font selection?" Whereupon grizzled old text formatting system veterans smile wanly and nod.) When filling is disabled, all *roff formatters still: * apply inter-sentence spacing (groff: if configured); * interpret control lines; and * interpret escape sequences. They also still honor character translations, which isn't very "<pre>" or "\verb". Fortunately, only a madman would use character translations in a man page. People need to not get carried away with what "no-fill" or "disabling filling" means. It *roff systems, it is limited to that and its logical consequences (no automatic breaking, no hyphenation, no adjustment). > ".ft C" on its own does not result in <tt> even though you might think > it would based on the behaviour in combination with ".nf". ".ft CR" > has no effect with or without ".nf". > > I can see why the author of this page decided to use ".ft C" for the > HTML device even though it doesn't seem to actually make any sense, > since it _works_ in 1.23.0 As far as I know, that idiom wasn't _documented_ anywhere. > - but doesn't any more. What's going on? The font name "C" is not portable and is now deprecated. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.24.0.rc1#n366 Regards, Branden
signature.asc
Description: PGP signature
