groff
[Top][All Lists]
Advanced

[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: Fri, 22 Feb 2019 00:01:55 +0000

On Thursday, February 21, 2019 3:10 AM, G. Branden Robinson wrote:

> At 2019-02-21T10:01:07+0000, Jeff Conrad wrote:
> > 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.
> 
> Not paired, I think you mean.  A vertical apostrophe would certainly be
> perfectly ambiguous with respect to a grave or acute accent.

I stand corrected :-).  There is little ambiguity in a quotation,
however, ’cause the left straight apostrophe (usually) comes before a
word and the right straight apostrophe comes after a word.  Of course,
I’ve just illustrated the main real potential ambiguity.

> If we actually have a userbase for ASCII output devices, I think we have
> only 2 choices:
> 
> 1. Provide 2 different "devascii"s to suit the different conventions; or
> 2. Give devascii a man page and tell people how to hack up their dot
>    files to override our default.
> 
> Maybe devascii should have a man page anyway, to explain this annoying
> issue.

Sounds pretty reasonable to me.  They really _are_ different devices.
Younger folks probably don’t know the history, and—quite reasonably—
probably don’t care. Unless they get mysterious “weird” 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?) phototypesetter.
> 
> Yes, and it is a shame that the number of people _reading_ these books
> and applying them to practice on glass screens was probably multiple
> orders of magnitude larger than those--including the authors--who did
> daily work on noisy, grindy, smelly teletypes.

I actually didn’t see this markup in the examples I cited, but it was
clear from the output that this is what was done.  I still see adjacent
single quotes sometimes in the Federal Register (no comment ...)

We probably should recognize that, in 1978, not enough characters were
available even on computer-assisted typesetters.

> > ECMA 6 did speak of using APOSTOPHE
> 
> Sic?  Did they really misspell it?  If so it's definitely going into my
> arsenal of mockery on this topic.

Er, sick ... IBLUIT ... It was getting late ...

> No, but 8-bit encodings are what is actually used on everything with a
> glass screen that _isn't_ Unicode-capable.

And it’s been that way for what, 40 years?  It was possible to set our
HP terminals to 7-bit mode.  I had a sysadmin who couldn’t seem to match
my results; turns out her terminal was set to 7-bit.  Suffice to say we
immediately made sure everyone was set to 8-bit mode.

> That's why I find the ASCII-puritanical position disingenuous (or
> perhaps simply ignorant); first, ASCII was sadly semantically unchaste
> in the first place when it came to 0x27 and 0x60,, and secondly, the
> people complaining about the proposed change almost assuredly _aren't
> using ASCII devices_.  They're using something considerably more
> powerful, and are viewing characters like 'á" right now without
> difficulty.

Amen.

Wasn’t the main justification for Genuine ASCII™ in its later years
avoiding problems with devices that couldn’t handle 8-bit characters?

> > 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.
> 
> Apart from the development effort, there's no reason not to, especially
> if the Windows console these days actually supports it.  If it doesn't,
> then supporting code page 437 in addition might make sense.
> .  .  .
> > 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,
> 
> Neat!

Glad to send it if anyone else is interested.  It’s obviously not the
ultimate solution, but suffice it to say there are some issues with Code
Page 65001 on Windows.  As you know, you go to war with the army you
have; it’s not the army you want or might wish to have at a later time.

> I have little love for Microsoft but I find Windows-1252 to be a useful
> test for minimal acceptable glyph coverage in a font, and as you point
> out [snipped] even then it can be considered deficient even for
> elementary mathematical typography.

Code Page 1252 is better than Genuine ASCII™ or Genuine ISO 8859-1.
Using en dash for minus is no worse than many other nroff
approximations; ya do what ya gotta do ...

> At 2019-02-21T21:22:42+1100, John Gardner wrote:
> > — We're applying polish to a +50-year old documentation system whose
> > biggest feature is *remaining unchanged.*
> 
> I disagree with that statement too.  Remaining unchanged of itself is
> _not_ a virtue.

But if most of the displays _have_ changed, something else may need to
change so that the user actually _sees_ doesn’t change.  Isn’t preserving
that the real objective?

Regards,
Jeff


reply via email to

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