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

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Thu, Feb 21, 2019 at 04:07:28PM +1100:
> At 2019-02-20T20:06:17+0100, Ingo Schwarze wrote:

>> 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'm sorry for the late arrival.  I've moved and taken a new job.

No problem, this wasn't an urgent matter, but instead merely an
attempt at long-term cleanup.

> The Savannah ticket[1] says:
> 
> "If i remember correctly, some time ago, people went through error
> messages and manual pages and changed single-quoted strings where the
> opening quote was an "accent grave" to the normal ASCII U+0027
> APOSTROPHE-QUOTE because rendering single quotes like `this' was
> considered an anachronism from the mechanical typewriter era."
> 
> I'm one of those people, and I particularly did it for diagnostic
> messages.  The GNU Coding Standards no longer prescribe using
> "symmetric" quotation marks drawn from valid ASCII code points, for the
> very good reason that they don't exist in modern fonts.
> 
> My view is as follows:
> 
> 1.  I would not mess with the ASCII device because `this' is sometimes a
> reasonable way to get symmetric quotes on an _actual_ ASCII output
> device.  I wouldn't _recommend_ it as it's not forward-compatible.  It's
> fine for roff input just as it is in TeX, even if it looks a little
> funny in document maintenance on fancy modern systems.  Were the issue
> important enough, we could have separate ascii_60_is_oq and
> ascii_60_is_ga devices (or whatever we ended up naming them).

Thanks for describing your view on the matter.  It indeed clarifies
the situation because it effectively adds you to the OPPOSED line,
reducing the chance that someone might regard the situation as an
overwhelming majority.

> In my opinion the ambiguity deliberately baked into ASCII in the 1960s
> was unfortunate, and doubly so because both Knuth and the *roff
> progenitors decided on DWIM semantics for ` and ', building heavily on
> that ambiguity.  Cf. `foo' and `bar', \('a and \'a, speaking in *roff
> first and then TeX, respectively, in each pair.

I think i now agree with that perspective, even though i wasn't
fully aware of the history at the time i proposed the patch.

> (I grant that the ASCII [ASA, ANSI] committee had a hard job.  The
> temptation must have been great to placate partisans by mapping multiple
> semantics onto each glyph to inflate the encoding's "coverage".  Douglas
> Kerr has some interesting anecdotes about Bell yielding to the ASCII
> then-future by replacing the 5-pointed star and diamond lozenge symbols
> on their then-innovative touch-tone phone keypads with the mysterious
> "asterisk" and "octatherp/octotherp/octothorpe" symbols.[2][3])
> 
> 2.  I _would_ change the latin1 device because there is no rational
> defense of 0x60 ` as an opening quote in Latin-1 (a.k.a. ISO 8859-1).
> In Latin-1 (and I think all the other ISO Latin alphabets, including
> ISO 8859-15), 0x60 is the GRAVE ACCENT and is never[4] mirror-symmetric
> with 0x27 ' APOSTROPHE but is instead mirror-symmetric
> with 0xB4 ´ ACUTE ACCENT.

I'm entirely indifferent in that respect.  I consider the latin1
output device utterly obsolete and don't think it will be many
years before it can be deleted outright.  Of course there is no
rush to delete it, it doesn't eat any bread.

Being able to process LATIN-1 input is still relevant because various
legacy documents exist (including substantial numbers of manual
pages) that are encoded in LATIN-1.  But producing LATIN-1 *output*?!
Gimme a break!

The only reason i included the latin1 device in the patch was to
keep it consistent with the ASCII device as long as it is still in
the tree - but if you want to maintain it independently, fine with
me, i certainly don't object to that, do whatever you want with
it...

Yours,
  Ingo