On Mon, Jan 21, 2019 at 12:29:42AM -0800, David Starner via Unicode wrote: > On Sun, Jan 20, 2019 at 11:53 PM James Kass via Unicode > <unicode@unicode.org> wrote: > > Even though /we/ know how to do > > it and have software installed to help us do it. > > You're emailing from Gmail, which has support for italics in email.
... and how exactly can they send italics in an e-mail? All they can do is to bundle a web page as an attachment, which some clients display instead of the main text. The e-mail's body text supports anything Unicode does, including ππ‘ππππ and even πππ ππππππ, but, remarkably, not italic umlauted characters, thai nor han. > > Splendidly! (smile) Social platforms, plain-text editors, and other > > applications do enhance their interfaces based on user demand from time > > to time. User demand, at least on Twitter, seems established. > > Then it would take six months, tops, for Twitter to produce and > release a rich-text interface for Twitter. Far less time than waiting > for Unicode to get around to it. Similar to many mail clients, Twitter does have a rich-text interface. It will present that rich-text as a link -- it will even has specific support to reduce the full URL to conserve the character count. But the primary interface is plain text, which unlike anything "rich" is interoperable with pretty much anything. > > Copy/pasting from a web page into a plain-text editor removes any > > italics content, which is currently expected behavior. Opinions differ > > as to whether that represents mere format removal or a loss of meaning. > > Those who consider it as a loss of meaning would perceive a problem with > > interoperability. > > Copy/pasting from a web page into a plain-text editor removes any > pictures and destuctures tables, which definitely loses meaning. > > It also removes strike-out markup, which can have an even more > dramatic effect on meaning than removing italics. As you pointed out > below, it removes superscripts and subscripts; unless you wish to > press for automatic conversion of those to Unicode, that's going to > continue happening. It drops bold and font changes, and any number of > other things that can carry meaning. Ie, any non-standard additions. There's a common base that's supposed to be interoperable, developed by a certain consortium -- and that base is pretty much guaranteed to work everywhere. Even if a specific display engine can't display some fancier elements, at least the underlying transport will transfer the text unmolested. There still are some issues here and there (like eg. people rejecting UCS2/UTF-16 on Windows which Microsoft insisted on, thus UTF-8 as system encoding is a new thing there and AFAIK even not the default yet AFAIK) -- but pretty much we're there. Last holdouts of ancient encodings are dying fast. There's a need to agree on a boundary between "this is what all means of interchange are supposed to support" and "fancy client-specific markup", and Unicode served at defining the former admirably. Meow! -- β’⣴⠾⠻⒢⣦β β£Ύβ β’ β β β£Ώβ‘ Remember, the S in "IoT" stands for Security, while P stands β’Ώβ‘β β ·β β β for Privacy. β β ³β£β β β β
