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: Ingo Schwarze
Subject: Re: [groff] [patch] modernize -T ascii rendering of opening single quote
Date: Sat, 2 Feb 2019 17:57:31 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

Hi Ralph,

Ralph Corderoy wrote on Sat, Feb 02, 2019 at 02:59:21PM +0000:
> Ingo Schwarze wrote:

>> It is not outright impossible, but i doubt that would be a wise
>> course.

> I agree, given your reasoning.

OK, so we can exclude fiddling with each individual macro sets.

>> And the correct way to mark up a single-quoted string in low-level
>> roff(7) is \(oq...\(cq, with the rendering decided by the output
>> device.

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

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

>> in man(7), i'm not aware of any reasonable alternative to writing
>> \(oq...\(cq directly in the manual page source code when authors want
>> single quoting.

> Due to some, all?, man renderers trying to keep a shell backquote as a
> paste-able backquote, for example.
> 
>     .\" For UTF-8, map some characters conservatively for the sake
>     .\" of easy cut and paste.
>     .
>     .if '\*[.T]'utf8' \{\
>     .  rchar \- - ' `
>     .
>     .  char \- \N'45'
>     .  char  - \N'45'
>     .  char  ' \N'39'
>     .  char  ` \N'96'
>     .\}

Exactly.  Which reinforces my point that you have to use \(oq
to get a left single quote in man(7).

>> It doubt that the benefit of avoiding the ugly ` ' in ASCII output is
>> worth these (at least) three downsides.

> Whom is this change is meant to benefit?  I've lost track.

People reading roff(7) documents with nroff(1) or man(1) in a terminal
window while they have LC_CTYPE=C set and while they are using a modern
font.

> Surely all you hepcats with your UTF-8 TTYs and Unicode fonts
> see [UTF-8 single quotes].

Yes, that is almost accurate.  It doesn't depend on the UTF-8 capability
of the terminal nor on the fonts available on the system but on the
LC_CTYPE setting the user chose; but that detail doesn't weaken your
argument.

> Could it be those that will see ASCII output in practice align with
> those that are happy to stick with seeing «`'»?

To some degree, probably.  Assuming there may be an overlap between
people who continue to use LC_CTYPE=C and people who continue to
use old-style US-ASCII fonts that are not compatible with Unicode
seems somewhat reasonable to me; Werner and yourself appear to be
examples of this group.

There are also people who almost always work under LC_CTYPE=C and
who are still OK with the change, for example Jason McIntyre.
I see no reliable way to guess the relative sizes of both groups.

Besides, LC_CTYPE is not merely a personal choice, but there are
technical reasons to sometimes use a UTF-8 LC_CTYPE (for example
when working on UTF-8-encoded natural language text files from the
shell with basic POSIX tools) and for the same person to use
LC_CTYPE=C in different contexts (for example when working on a
build system).  The latter situation is what caused people to
repeatedly report what they perceived as "the `quoting' oddity" to
me in the past: people who normally use UTF-8 but sometimes switch
to LC_CTYPE=C for specific tasks (like Ted Unangst or Anthony
Bentley, if i understand correctly).

Yours,
  Ingo



reply via email to

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