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