Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Ingo Schwarze]

Hi,

after reviewing all feedback, i come to the conclusion that there is no
consensus for the change:

OPPOSED:  Mike Bianchi, Tadziu Hoffmann
SCEPTICAL:  Ralph Corderoy
NO EXPLICIT PREFERENCE STATED:  Doug McIlroy, Werner Lemberg
APPEAR TO NOT OBJECT:  Dave Kemper, Jason McIntyre
IN FAVOUR:  Anthony Bentley, Bertrand Garrigues, Colin Watson,
            Ingo Schwarze, Jeff Conrad, Ted Unangst

I think that established behaviour can be changed if there is
consensus.  I also think that established behaviour can be changed
if there is an overwhelming majority together with strong technical
reasons or very significant benefit from the change.  I doubt that
it is wise to change established behaviour based on a majority when
the benefit is, as John aptly put it, "nice to have" and substantial
arguments have been presented for both sides that nobody managed
to fully reconcile.

So i think it is best that i do not commit my patch, do not change
the behaviour of the mandoc toolkit either, close the bugtracker
ticket as WONTFIX in a few days, and instead consider whether the
mandoc_char(7) manual or the "ASCII Output" section in the mandoc(1)
manual should instead explain why the ASCII output device renders
single quotes as 0x60/0x27 - which, as the thread has extensively
demonstrated, is no longer obvious even for some experienced computer
users nowadays.

Sorry for the considerable time you all spent on this; while i
expected that some concerns i overlooked might possibly be raised
(that's why i brought it up rather than just committing it), i did
not quite expect that such a large number of different aspects might
need to be taken into account for such a deceptively simple-looking
matter.

Yours,
  Ingo


P.S.
My final summary of the main arguments, for easy later reference:

BENEFITS WOULD HAVE BEEN:
-------------------------
 - stop relying on a meaning of ASCII 0x60/0x27
   that conflicts with ISO646 and with Unicode
 - compatibility with modern (Unicode-compatible) fonts
   that treat ASCII 0x60 unambiguously as "accent grave"
   (admittedly, people often use -Tutf8 together with those)
 - but still useful when using LC_CTYPE=C temporarily, for example
   in build system contexts or when logged into remote machines,
   and for those people always using LC_CTYPE=C with modern fonts
 - symmetry with the ASCII rendering of \(lq
 - symmetry with groff error messages etc.
 - compatibility with the GNU coding standards
   https://www.gnu.org/prep/standards/html_node/Quote-Characters.html
   (admittedly, for roff output, historic precendent may be more
    important than GNU coding standards, so i give this argument last)

DOWNSIDES WOULD HAVE BEEN:
--------------------------
 - ASCII clearly states that 0x60/0x27 are intended to be used
   as symmetrical single quotes (even though it also permits the
   use of the same bytes as accents)
 - several people still use fonts that support this usage of ASCII,
   so for them, the output would actually look worse
 - it would be a change of established behaviour
   for a benefit of the "nice to have" class
 - may cause issues when post-processing -Tascii output with scripts
   (but how many people do that, and rely specifically on quotes?)
 - may break existing documents that incorrectly use \(oq to
   specifically get the ASCII 0x60 ` output glyph
 - typos of \(oq vs. \(cq are no longer obvious in ASCII output
   (but ASCII is weak for detecting typos in the first place)