Re: Encoding italic

On 16/01/2019 02:15, James Kass via Unicode wrote:
>
> Enabling plain-text doesn't make rich-text poor.
>
> People who regard plain-text with derision, disdain, or contempt have
> every right to hold and share opinions about what plain-text is *for*
> and in which direction it should be heading. Such opinions should
> receive all the consideration they deserve.

Perhaps there’s a need to sort out what plain text is thought to be
across different user communities. Sometimes “plain text” is just a
synonym for _draft style_, considering that a worker should not need
to follow any style guide, because (a) many normal keyboards don’t
enable users to do so, and (b) the process is too complicated using
mainstream extended keyboard layouts.

 From this point of view, any demand to key in directly a text in a
locale’s accurate digital representation is likely to be considered
an unreachable challenge and thus, an offense.

But indeed, people are entitled not to screw down their requirements
as of what text is supposed to look like. From that POV, draft style
is unbearable, and being bound to it is then the actual offense.

The first step would then be to beef up that draft style so that it
integrates all characters needed for a fully featured representation
of a locale’s language, from curly quotes to preformatted superscript.
Unicode makes it possible, in the straight line of what was set up
in ISO/IEC 6937. The next step is to design appropriate input methods.
Today, we can even get back the u̲n̲d̲e̲r̲l̲i̲n̲e̲ that we were deprived of,
by adding an appropriate dead key or combining diacritic, but that’s
still experimental. It already works better, though, than the Unicode
Syriac abbreviation control, whose overline is *not* rendered in
Chrome on Linux, The same way, Unicode could encode a Latin italic
control, or as Victor Gaultney proposes, a Latin italic start control
and a Latin italic end control, directing the rendering engine to
pick italics instead of drawing a linie along the rest of the word.

However, the discussion about Fraktur typefaces in the parent thread
made clear that reasoning in terms of roman vs italic is not really
interoperable, because in Roman typefaces, italic is polysemic, as
it’s used both for foreign words and for stress, while in Fraktur,
stress is denoted by spacing out, and foreign words, by using roman.
That would require a start and end pair of both Latin foreign word
controls and Latin stress controls.

As we see it from here, that would be even less implemented than
the Syriac abbreviation format control. It might be considered
Unicode conformant, since it would be part of the interoperable
digital representation of Latin script using languages, and its
use could be extended to other scripts.

But that is *not* what I’m asking for. First, we aren’t writing
in Fraktur any more, at least not in France nor in any other
language using preformatted superscript abbreviation indicators.
And second, if we need a document for full-fleshed publishing,
we can use LaTeX or InDesign.

What I’m asking for is simply that people are enabled to write
in their language in a decent manner and can use that text in
any environment without postprocessing *and* without looking
downright bad.

That might please even those who are looking at draft style
with disdain.

Best regards,

Marcel
Received on Tue Jan 15 2019 - 21:54:16 CST