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

[Jeff Conrad]

On Saturday, February 2, 2019 8:58 AM, Ingo Schwarze wrote

> > I think you're incorrect there.  Using ` ' as input
> > has always been a correct way to get single left and right quotes;
> > see CSTR 54 2.1.
> 
> You seem to be right about that.  In modern roff implementations,
> that appears to be implemented as an input character translation,
> though, because i see this:
> 
>    $ echo "pre \`word' post" | troff -Tutf8 | grep ^C
>   Coq
>   Ccq
>    $
> 
> So the *input character* "`" is translated to \(oq internally.

It’s interesting that this only seems to happen with ‘-Tutf8’; for most
other devices, it seems to be handled in the font files.

> That has nothing to do with the question what a good *output glyph*
> for \(oq is on the -T ascii device.

But it does seem to make clear that ‘`’ and ‘'’ are markup idiom rather
than text to be rendered literally.

On Wednesday, February 6, 2019 6:39 AM, Ingo Schwarze wrote

> BENEFITS:
> ---------
>  - stop relying on a historic meaning of ASCII 0c60
>    that was never portable and that conflicts with Unicode

I think “historic” is pretty context dependent.  As nearly as I can
tell, ASA/ANSI X3.4 has called for 0x60 to encode “accent grave.”

That said, I need to qualify my earlier “always been wrong” comment.
Although it may have been in conflict with the standards, it wasn’t
always in conflict with implementations.  And in some cases, it still
isn’t.  On my HP LaserJet M401dn, if I specify either the ASCII or HP
Roman-8 character sets, ‘`’ and ‘'’ render as opening and closing single
quotes.  Of course, I can’t see why anyone would use nroff with a laser
printer today, so this is straining for an example.

When I first used AT&T troff (Elan Computer Group’s eroff) with LaserJet
printers, font support was pretty limited, restricted to the HP Roman 8
set.  I never tried something like

    echo "\`word'" | troff -Tlj

so I can’t say whether the output was the result of internal
translation or the font table mapping.  I also can’t recall what was
initially in the nterm tables, though I later made sure they mapped ‘`’
to ‘'’ (there was no ‘\(oq’).

> DOWNSIDES:
> ----------
 .  .  .
>  - looks worse with traditional fonts that provide an "opening quote"
>    glyph for ASCII 0x60 rather than an "accent grave" glyph

Again, I think “traditional” depends on which tradition one has
followed.

Double Quotes
-------------
This leads me to wonder about an arguably different issue: markup for
double quotes. ‘``’ and ‘''’ were long the traditional markup for
opening and closing double quotation marks.  As nearly as I can tell,
they were rendered as adjacent opening and closing single quotes, either
as direct rendering or the result of character translation (I don’t
think ‘\(lq’ and ‘\(rq’ existed).  Though clearly preferable to ‘"’,
it’s still inferior to true double quotation marks.

But things have changed, and it seems to me that ‘``’ and ‘''’ should be
translated to ‘\(lq’ and ‘\(rq’ as is done in TeX.  It’s a lot easier to
code (and read) the traditional markup; moreover, such a translation
would give a “modern” rendering to old source.  I’ve long handled this
by running a preprocessing script that handles the translation, but this
seems pretty clunky as a general solution.

This probably is another topic for another time.

Jeff