(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?
Received on Sat Jan 19 2019 - 21:14:43 CST
This archive was generated by hypermail 2.2.0 : Sat Jan 19 2019 - 21:14:43 CST