[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jeff Conrad
Subject: Re: [groff] [patch] modernize -T ascii rendering of opening single quote
Date: Thu, 21 Feb 2019 10:01:07 +0000

On Wednesday, February 20, 2019 9:07 PM, G. Branden Robinson wrote:
> The Savannah ticket[1] says:
> rendering single quotes like `this' was considered an anachronism from
> the mechanical typewriter era."

I never did this with a mechanical (or electric) typewriter ...

The Chicago Manual of Style, 13th ed., says “a single quotation mark,
however, should not be used to indicate an accent, because it could be
either a grave or an acute accent” (2.14, p. 42)—so I guess it assumed
typewriter single quotes aren’t symmetrical.

> 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.

We still have the question about what is (or was) a Genuine ASCII™
device, since different manufacturers had different implementations.  I
must admit that, after consulting an HP 2392 manual, I see that it used
the HP Roman 8 character set, so I probably had a device that displayed
symmetrical left and right quotes until at least the late 1980s.

> 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.

This leaves the impression that the devices Knuth and Kernighan and
their associates rendered symmetrical left and right quotes.  Looking at
The Unix Programming Environment (1984), Chapter 9, Document
Preparation, it’s also apparent that double quotes were literal
renderings of “``word''” (‘‘word’’), printed on a Mergenthaler Linotron
202.  The same impression obtains from The C Programming Language
(1978), Preface; this was printed on a Graphic Systems (C/A/T?)

I notice that the 13th ed. of the Chicago Manual of Style also seems to
use adjacent single quotes for double quotes; the 17th ed. uses true
doubles. Things change ...

But is this literal or just markup?  For the AT&T folks, perhaps the
former.  With TeX, “``word''” gets mapped to “word”.  All I can say is
that it’s a lot easier to type (and read) “``word''” than
“\(lqword\(rq”.  I wish roff did the same thing (I still often use the
“traditional” markup and do the conversion with a front-end script).

> 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

Hard to disagree with this; as it stands, it seems like it’s always been
wrong, because I don’t think ISO 8859-1 or ECMA 6 ever provided options
ECMA 6 did speak of using APOSTOPHE to simulate an acute accent, but
the graphic shown in the 1985 and 1991 versions is vertical (GRAVE
ACCENT is sloping upward to the left).

> On truly ASCII output devices, 0x60 GRAVE ACCENT _might_ be a
> directional single quotation mark that pairs with 0x27; it therefore
> makes sense to map \[oq] to 0x60.

But the operative word is _might_, so you’ve got to ask yourself one
question: Do I feel lucky?

More practically, how many users are likely to get crummy output on a
Genuine ASCII™ device if the change is made versus how many are getting
crummy output with things as they stand?  No question that devutf8 is
the preferred way to go, but it’s not always an option for everyone.

> On a Latin-1, Windows-1252, or Unicode device, the foregoing WILL NOT
> be true.  Latin-1 lacks directional quotation marks altogether, and the
> other two encodings have dedicated code points for them, respecting 0x60
> in its sole role as a spacing grave accent diacritic.  On none of these
> will 0x27 APOSTROPHE be a copy of 0xB4 ACUTE ACCENT.

This raises another question: why not a devcp1252?  Many browsers treat
it as a de facto superset of ISO 8859-1, but capriciously adding
characters from the C1 area to devlatin1 is probably a bad idea.

In all the excitement here, I created such a device and it works fine.
I run a Windows environment that has some issues with UTF-8, and this
allows reasonable rendering of most characters, including the infamous
use of an en dash for a minus sign because MS apparently didn’t consider
the latter important.

I don’t know if this works with fonts on *nix machines.

Jeff Conrad

reply via email to

[Prev in Thread] Current Thread [Next in Thread]