Follow-up Comment #2, bug #68261 (group groff): Yesterday I had occasion to visit this well yet again, on the [https://lists.gnu.org/r/coreutils/2026-05/msg00026.html GNU coreutils mailing list].
...
> - inline examples
> Switching to Courier font works fine in PDF output and not
> at all in HTML. It would be nice to see this translate to
> CODE, TT, or some such, but it probably doesn't need any
> macro support.
This is hard to support because while one can intercept _requests_ in
GNU troff, there's no way to intercept an escape sequence. So when
people use `\fC` or `\f(CW` or even `\f(CR` (the last being otherwise
supported by groff) in nroff mode, it's hard for the macro package to
help them by falling back to some sensible alternative--the document has
already gone behind the package's back.
As I've noted elsewhere, I'm hearing a bit of grousing from people
running linters on their man pages who are upset that groff now throws
warnings when a font selection fails. They are upset even when the
warning occurs in nroff mode, and accuse me of having withdrawn support
for monospaced typefaces in their man pages.
That is, of course, false. Terminal devices _can't change the font
family_ and every terminal emulator that even weakly implements ECMA-48
lays out the screen as a uniform grid of character cells. That means
that the font in use is _already monospaced_.
Further, nothing about the rendering has changed on these devices.
`\fC` was _always_ doing nothing in nroff mode.[3] It's just that now,
GNU troff is _telling_ you that your command to it is, and always has
been, futile (in nroff mode). Evidently that is unwelcome information.
...
[3] You _could_ exercise a GNU troff extension to remap the `C` font,
say to `R` or `B`. But a man page should *never* do that. Only a
system's "man.local" file or similar should be so meddlesome. And
it's hard to know which choice aligns better with the intention of
the man page author in any case. Moreover, it's not always
warranted to assume that said intention is consistent within a
document. Man pages tend to get fiddled by many different hands
over the years.
I think trying to get at inline Courier in man pages is a fool's
errand. I'm not 100% opposed to introducing yet another new macro
(pair--see below) to support it, because at least with a macro the
package can evaluate the font-change instruction and try to do
something sensible, and perhaps even string-configurable--but this
solution faces multiple strong headwinds.
First, many man(7) authors are besotted with `\f` escape sequences.
If they don't change their input habits, a new macro won't help
them. As noted above, if you use an escape sequence, a macro
package is impotent. You've punched through the floor already.
Second, the next most obvious thing to implement and to type is yet
another font macro, say `C`. Apart from the combinatorial impact of
an orthogonal design implying a need for font alternation macros
with every other face, producing CB, CI, CR, BC, IC, and RC--a major
bloat to the lexicon I really do want to keep lean, there is a big
hazard here...what happens when the renderer doesn't support these
macros? Recall what a formatter does with an unrecognized macro.
The call is ignored. Text vanishes. Worst, some of the most
important text in the document is precisely what goes missing.
Third, we could solve most of the foregoing problems with a _pair_
of new macros. Call 'em `CS` and `CE`. Two drawbacks to that: (a)
it clashes horribly with man(7)'s existing design, making the
package harder to learn; and (b) without font alternation macros, a
lot more people are going to have to learn how to use `\c`, and that
might be enough to kill the plan right there, even if we solved the
problem of po4a aborting as soon as it sees one of these.
https://github.com/mquinson/po4a/issues/527
Fourth, if you apply inline Courier to multiple words, how does the
reader know where the boundaries of the "literal text" are when the
material is copied-and-pasted? Granted, this is a problem with bold
and (less often) italic styling too, which is why I recommend that
man page authors use quotation. But that faces a headwind as well,
some of the original man(7)'s own making but fanned up to gale
strength by GNU/Linux distributors' own decisions.
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in?h=1.24.1#n4697
So, no, not 100% opposed, but maybe 95%. Who has a solution to all
of the foregoing problems?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68261>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
