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

[Ingo Schwarze]

Hi Ralph,

Ralph Corderoy wrote on Fri, Feb 01, 2019 at 06:42:48PM +0000:
> Doug wrote:

>> Still, this is a cautionary tale. What other sorts of
>> documents would suffer badly under this change?

> groff_char(7) here currently contains
> 
>     Output  Input   PostScript      Unicode Notes
>     ...
>     \[oq]   \e[oq]  quoteleft       u2018   single open (left) quote
>     \[cq]   \e[cq]  quoteright      u2019   single closing (right) quote
> 
> and renders as
> 
>     Output   Input   PostScript       Unicode   Notes
>     ...
>     `        \[oq]   quoteleft        u2018     single open (left) quote
>     '        \[cq]   quoteright       u2019     single closing (right) quote
> 
> That ` would become a '.  Technically correct, that is the new
> `Output', but hides some history and may make things less clear.
> 
> Ingo, you originally mentioned
> 
>     However, the -T ascii output device still renders \(oq as "accent
>     grave", also affecting macro packages that implement single quoting
>     macros in terms of \(oq, for example mdoc(7) .Sq.
> 
> If it's the `modern' mdoc output that's primarily of concern, could its
> macros that use \(oq make a subjective choice to pretty it up for
> -Tascii and -Tlatin1?

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

First, from a semantic perspective.  When authors says .Sq, they want
the argument marked up as a single-quoted string.  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.  So the macro set
should really use the logical low-level feature, as a matter of
separation of structure and presentation, rather than re-inventing
its own presentational choices for individual output devices.

Second, from a presentational perspective.  While mdoc(7) does have
quoting macros, and while personally, i would like man(7) to die, it
is a fact that many manual pages still exist written in man(7), and
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.  So changing mdoc(7) would make -T ascii output
of mdoc(7) and man(7) manual pages inconsistent.  Besides, it might
even cause inconsistencies *inside* mdoc(7) documents.  While it is
very rarely needed and almost always better mdoc(7) style to use
the .Sq or .So macros, it is not outright wrong to use \(oq in
places where nesting macros is unusually inconvenient for some reason.
That would then results in a mixture of different renderings for
opening single quotes inside the same document.  Also, i'd like
to avoid introducing more differences between manual page rendering
and groff rendering in general, unless there are very strong reasons.

Third, from a technical perspective.  Implementing your proposal to
treat \(oq differently in -T ascii and -T utf8 output would result
in very ugly code in mandoc because mandoc does not really provide
any way to make the treatment of a macro depend on the output mode -
intentionally so.  Macros are supposed to have semantic value and
not imply presentational choices.  Even in groff, the implementation
would be quite ugly.  Yes, .Sq is implemented in terms of a string
defined by the macro set, \*[doc-left-singlequote], which is already
defined separatly in tmac/doc-ditroff-u and tmac/doc-nroff-u -- even
though to the same value, \[oq].  But that split would not be enough
because -T ascii and -T utf8 both use tmac/doc-nroff-u, so we would
have to goof around with ".ie '\*[.T]'utf8'" which i disklike quite
strongly.

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

Consequently, i think that we should either change the rendering
of \(oq in -T ascii for all documents or leave it as it is, but
not make the rendering (of some instances) in (some) manual pages
different from the normal rendering.

> I doubt many worry about old mdoc source rendering differently
> over time.  :-)

That is likely true.

> And it would leave the rest of the world alone for those of us
> with symmetric «`'», old documents, and groff_char(7).

More people voiced an opinion on this than i expected.  To see
whether a consensus is emerging, here is the list as far as i'm aware:

Doug McIlroy       -- opposed because incorrectly marked up existing
                      documents that now (by chance) render correctly
                      to ASCII might then render incorrectly
Mike Bianchi       -- opposed because he highly values keeping -T ascii
                      rendering exactly as it used to be historically

Ralph Corderoy     -- slightly sceptical, considers whether
                      preserving historical rendering has value,
                      and likes fonts rendering ` ' symmetrically
Werner Lemberg     -- not quite explicit, but does not seem to
                      dislike ` ' in the first place

Anthony Bentley    -- clearly in favour
Bertrand Garrigues -- clearly in favour
Dave Kemper        -- seems to not object
Ingo Schwarze      -- in favour without feeling too strongly
Jason McIntyre     -- would be OK with changing it
Jeff Conrad        -- clearly in favour
Ted Unangst        -- would be happy with the change

To me, that doesn't look like a consensus yet, and unfortunately,
i don't see how to argue futher, because the arguments for and
against feel incommensurable to me: "preserve historical ASCII
rendering" or "make it nicer logically and less ugly with fonts
commonly used today" can't be compared as "right or wrong", but
simply look like different priorities, both reasonable in their
respective way.

Any ideas how to resolve this clash of priorities?

Yours,
  Ingo