Re: groff 1.23.0.rc2 readiness

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Fri, May 27, 2022 at 05:50:51PM -0500:

> I want to prevail upon man page authors to choose correct glyphs in
> their documents--so we can get a consistent experience on all output
> devices.

Ouch.  Those special rules for manual pages allowing to write plain
ASCII "-" on the input side to get plain ASCII "-" on the output
side were *device specific* (same for the other four characters),
which means that this text i wrote four years ago in mandoc_char(7)
was never accurate - right?

  In roff(7) documents, the minus sign is normally written as `\-'.
  In manual pages, some style guides recommend to also use `\-'
  if an ASCII 0x2d "hyphen-minus" output glyph that can be copied
  and pasted is desired in output modes supporting it, for example
  in -T utf8 and -T html.  But currently, no practically relevant
  manual page formatter requires that subtlety, so in manual pages,
  it is sufficient to write plain `-' to represent hyphen, minus,
  and hyphen-minus.

When considering PDF and HTML output, that was anpparently never true
(except with mandoc(1)), plain "-" on the input side always gave you
a hyphen in PDF output even in manual pages, right?

Now *making* that device independent would not be an improvement
because then manual page authors would have to write

  The --foo option can\(cqt be used together
  with a non\(hyzero bar argument.

which is clearly not easier than having to write

  The \-\-foo option can't be used together
  with a non-zero bar argument.

Consequently, using these five glyphs unescaped on the input side
in order to get the five ASCII output characters was always wrong
even in manual pages (not sure how i managed to fail to realize
that until now, or more likely forget it again).

I think the argument "this was always wrong and only worked on
some output devices at best" is stronger than my argument "but
manual page authors have become used to it and some style guides
including my own actively recommended it".  So i think i have to
retract my objection.  Yes, it causes a lot of work including
in OpenBSD, but when something is actually broken, calling that
a "make-work project" is not really fair.

Note that i can only retract my part of the argument; John
might still have points that are not invalidated by this mistake
i made.

Yours,
  Ingo