Re: groff 1.23.0.rc2 readiness

[Alejandro Colomar]

Hi Branden,

On 5/26/22 17:23, G. Branden Robinson wrote:
[...]
> So, here's Mean Mr. Mustard.
>
> Anybody who's read the previous discussion(s) we've had on this list
> about it, or the current version of the groff_char(7) man page, will be
> aware of my objections (the latter because I think those objections
> follow from a historical understanding of troff special characters).

[...]
> I don't think man pages should have to be written one way for terminals
> and another for PDF, whence goes the road you and Ingo are walking.  It
> is therefore important to make these ASCII-degradations contingent on
> (1) usage of the man(7) package and (2) output to the 'utf8' device.
>
> If it were to go in man.local, it would look something like this.
>
> .if '\*[.T]'utf8' \{\
> .  char ' \[aq]
> .  char - \-
> .  char ^ \[ha]
> .  char ` \[ga]
> .  char ~ \[ti]
> .\}
>
> Is the foregoing enough to satisfy anyone?
[...]

FWIW, I sympathize with wanting the correct glypths, instead of 
workarounding within groff(1) the laziness of manual page writers.  The 
Linux man-pages are correct in that sense, at least as far as I know, 
and advise in man-pages(7) how to do it correctly (as groff_man*(7) also 
does).

We know there are still many manual pages that don't have the correct 
escapes, but I think we should aim to fix them, and by breaking them 
(not very badly; just a little bit), we might help get them fixed.

Many times, when I have to serach for a command option in a manual page, 
I notice '-' isn't correctly escaped, and report it (curl(1), gpg(1), 
...).  I have fixed a few packages in that regard, and expect to fix 
many more.  I would actually be slightly upset if groff(1) would hide 
that issue to me in the terminal so that I only notice later in the PDF 
(or HTML too?).


Cheers,

Sancho^W Alex

> Quixotically yours,
> Branden