[dropping coreutils list and several people from distribution; looping in the groff list and man-db maintainer Colin Watson]
Background/parent thread: https://lists.gnu.org/r/coreutils/2026-05/msg00021.html At 2026-05-11T10:46:39-0400, Chet Ramey wrote: > On 5/9/26 12:15 AM, G. Branden Robinson wrote: > > 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. > > If it's a no-op in nroff, and does something reasonable in troff, man > page authors don't have to write .if t and .if n conditionals. > (Speaking as someone who used to use \f(CW to force a constant-width > font in troff.) I get that, but there are also cases like this: https://unix.stackexchange.com/questions/771162/grep-error-warning-cannot-select-font-i I don't want people having to write conditionals in their man pages, either, unless they're trying to do something really clever (risking the wrath of mandoc(1)), or are fiddling the typography for a typesetter in an OCD way--as I've been known to do with groff's own man pages. The problem I see is that, in nroff, the font `CW` isn't unavailable in a different way than `i` or `ZZ` are. All just flat don't exist on the output device. And that's always been true. I'm finding it hard to reconcile the goals of empowering the software system to help people find errors with the desire of the document author--or maybe it's not the document authors themselves, but others, like people downstream of them who have a poor grasp of man page composition practices--to not be told about errors. Complaints appear to be coming from people running validation programs like Debian's "lintian" who then get cross because "lint" is found. Hapless users employing the man(1) command don't see these diagnostics because man-db man(1) (at least) turns off _all_ diagnostics from the formatter. I struggle to understand the mindset of someone who employs an automated verification tool and then gets upset when it has something to say. That attitude seems to "embrace the suck" of Goodhart's Law.[1] But I have a more immediate problem: I'm having trouble getting man-db man(1) to show me warnings at all, even when I ask for them--sometimes. $ command man --version man 2.9.4 $ type man man is a function man () { if command man "$@"; then command man --warnings=w "$@" > /dev/null; fi } What this does is, only if the first man(1) command succeeds, I re-run it with warnings turned on, and discard the normal output (which I've already seen in my pager). I've used this function for several years to inform myself about (a) the comprehensibility and impact of GNU troff's warning (and error) diagnostics as applied to diverse inputs (as man pages go); and (b) what sorts of problems are common in real-world man pages. The foregoing works for me--usually. But not when I use "man -l /dev/stdin". When composing an earlier version of this email to prove how the font warnings that some people have been complaining about affect only linters, or people who deliberately configure man-db man(1) to elicit those warnings, I found I could prove my point _too_ well. $ printf '.TH foo\n.SH Name\nfoo \\- bar\\@baz\n.Sh\n.nr a A\n' \ | MANWIDTH=72 MANPAGER=cat /usr/bin/man --warnings -l /dev/stdin foo() foo() Name foo - bar@baz foo() What? That input _certainly_ should have harped at me. And indeed it does if I hand it directly to nroff. $ printf '.TH foo\n.SH Name\nfoo \\- bar\\@baz\n.Sh\n.nr a A\n' \ | nroff -ww -r LL=72n -man troff:<standard input>:3: warning: ignoring escape character before '@' [-w escape] troff:<standard input>:4: warning: name 'Sh' not defined [-w mac] troff:<standard input>:5: error: ignoring invalid numeric expression containing character 'A' foo() foo() Name foo - bar@baz foo() If I screwed myself with that shell function, I don't see how. $ bash --norc ##bash-5.3$ printf '.TH foo\n.SH Name\nfoo \\- bar\\@baz\n.Sh\n.nr a A\n' \ | MANWIDTH=72 MANPAGER=cat /usr/bin/man --warnings -l /dev/stdin foo() foo() Name foo - bar@baz foo() Colin, can you help me understand this discrepancy? For the groff list's benefit, and Colin's, I'll now repeat some (slightly edited) material Chet's already seen (or will see) in a separate message of mine to the coreutils list. > > I know I'll never get man page authors as a whole to give up their > > font escape sequences; the best I can do is try to convince people > > that using them has drawbacks, by spelling out what those drawbacks > > are. > > > > * The formatter can't distinguish typos from intentional but > > impossible demands; > > * because font escape sequences "punch through the floor" and > > directly command the formatter, the macro package can't help you > > by checking font availability for itself and then falling back to > > something "reasonable" in context (and taking output device > > capabilities into account); > > * the identity of the "previous font", as selected by `\fP`, is > > inconsistent among implementations if an un-fulfillable selection > > is made;[1] > > * input like `\fIthis\fP` frustrates many spell checkers; and > > * groff man(7), at least, knows to apply italic corrections when the > > document sets upright and slanted glyphs adjacently. > > > > Maybe I should stick the foregoing into the "Notes" section, a kind > > of FAQ--except people mostly don't ask questions, but instead > > proclaim groff and its maintainers as stupid--of the > > groff_man_style(7) document. Thoughts? Should I grow groff_man_style(7) in this way? Regards, Branden [1] https://en.wikipedia.org/wiki/Goodhart%27s_law
signature.asc
Description: PGP signature
