Italics get used to express important semantic meaning, so unicode should support them

[Sławomir Osipiuk]

I think you forgot the most important part: Which email clients?
None of the markup has the intended effect for me, and in pure plaintext none of it (currently) can. Whatever client you're using is interpreting the markup and applying the formatting.

-----Original Message-----
From: Unicode <unicode-bounces at unicode.org> On Behalf Of Martin J. Dürst via Unicode
Sent: Tuesday, December 22, 2020 7:15 PM
To: unicode at unicode.org
Subject: Re: Italics get used to express important semantic meaning, so unicode should support them

Hello everybody,

Just for what it's worth, here are a few details on how at least some email clients handle ASCII email styling conventions (/ for italics, _ for underscore, and * for boldface).

On 22/12/2020 04:42, Ken Whistler via Unicode wrote:
> 
> On 12/21/2020 11:05 AM, abrahamgross--- via Unicode wrote:
>> The only reason why things like_italics_  or*italics*  are around is 
>> because of the lack of real italics. I would go as far as to say that 
>> the very existence of*italics*  in plain text shows that theres a 
>> real need for italics when writing plain text.
>> This is a workaround around a real problem of the lack of italics if 
>> I've ever seen one…

The two places above are displayed without styling in plaintext, probably because they are quoted. They show up styled in HTML because that contains additional tags (<b>,...).

> Actually, simple markup conventions like that mostly date from early 
> days of email, when plain text (and usually just ASCII at that) were 
> all you got. (By the way, the most usual interpretation of those is 
> _underscore_, /italic/, and *bold*, but whatever.)

These show up styled in plaintext display, but not in HTML, presumably because Ken entered the styling characters by hand (in the HTML version, there is no markup).

> Nowadays, presto chango, most email clients support rich text (in 
> HTML, usually), and you get to _underscore_, /italicize/, and *bold* 
> your text correctly whenever you want to, and even change the font 
> size to SHOUT, if you want.

These show up styled in HTML, most probably because Ken used the text editor to style them that way. The plaintext version contains ASCII email styling characters (but the HTML version doesn't), and my guess is that they were added when the mailer produced the plaintext version.

Your mailer and your mileage may vary.

Regards,   Martin.

> Some folks here seem to be viewing the "problem" here the wrong way 
> round. The issue isn't that plain text cannot preserve all the "meaning"
> conveyed in writing systems. When dealing with meaning conveyed with 
> conventions that involve styling, font change, color and such, you 
> simply depend on properly tiered text architecture and build support 
> for that in rich text and markup. It is ass-backwards to try to 
> continue to clot up plain text as the backbone of text interchange by 
> trying to import all the complications of styling directly into it as 
> if that representation were a plain text issue -- it isn't.
> 
> Instead the *real* problem here is that in some communication contexts 
> that should be supporting rich text, implementations are still 
> restricting people to plain text when what they really want is easily 
> accessible and dependable rich text to convey more nuances accurately 
> (or just to be more expressive). If Twitter is half-assed about 
> supporting text styling, then direct your concerns in the proper 
> direction. You don't fix Twitter's or texting apps' use of text by 
> trying to force styling into the Unicode encoding of plain text.
> 
> --Ken