Encoding italic (was: A last missing link)

James Kass via Unicode unicode at unicode.org
Sat Jan 19 21:14:21 CST 2019

(In the event that a persuasive proposal presentation prompts the 
possibility of italics encoding...)
Possible approaches include:

1 - Liberating the italics from the Members Only Math Club
...which has been an ongoing practice since they were encoded.  It 
already works, but the set is incomplete and the (mal)practice is 
frowned upon.  Many of the older "shortcomings" of the set can now be 
overcome with combining diacritics.  These italics decompose to ASCII.

2 - Character level
Variation selectors work with today's tech.  Default ignorable property 
suggests that apps that don't want to deal with them won't.  Many see VS 
as pseudo-encoding.  Stripping VS leaves ASCII behind.

3 - Open/Close punctuation treatment
Stateful.  Works on ranges.  Not currently supported in plain-text. 
Could be supported in applications which can take a text string URL and 
make it a clickable link.  Default appearance in nonsupporting apps may 
resemble existing plain-text italic kludges such as slashes.  The ASCII 
is already in the character string.

4 - Leave it alone
This approach requires no new characters and represents the default 
condition.  ASCII.


Number 1 would require that anything not already covered would have to 
be eventually proposed and accepted, 2 would require no new characters 
at all, and 3 would require two control characters for starters.

As "food for thought" questions, if a persuasive case is presented for 
encoding italics, and excluding 4, which approach would have the least 
impact on the rich-text world?  Which would have the least impact on 
existing plain-text technology?  Which would be least likely to conflict 
with Unicode principles/encoding model?

More information about the Unicode mailing list