On 9/30/2016 11:26 AM, Michael Everson
wrote:
On 30 Sep 2016, at 08:07, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:
Apart from specialized cases, the recommended approach is to use higher protocols (such as formatting or markup). So instead of trying to find superscript letters for “end”, you should consider using rich text or a markup language so that the word written with normal letters “end” is formatted or marked up as a superscript.
Even I don’t because I want stuff to be preserved in plain text.
It all boils down to what should be expressible (or as you write)
"preserved" in plain text.
Where selection of a particular appearance has the semantics of
turning a letter or symbol into a different unit of the writing
system (such as for modifier letters) the case for direct expression
in plain text is strong.
Where whole words, or part of words are superscripted; where
superscript is just one conventional style for something (1st vs. 1
st);
where there are multiple levels of superscript (math) -- in all
these cases the case for relegating this to the style layer is
strong.
Independent of that is the consideration for compatibility encoding
to match a (possibly different) decision in this matter by earlier
standards.
These three factors are the drivers for past and future encoding
decisions -- but the first two are also relevant for authors in
deciding whether to use rich text or not.
Using superscript code points instead of markup in mathematical text
should probably be considered a last resort - only in cases where
mathematical text needs to be "simulated" because of limitation of
rich text support, e.g. in keywords, titles and similar database
fields. However, note that the UTC long ago refused to encode some
Greek subscripts needed for medico-legal compliance databases;
something that would have seemed a pretty strong case.
The preferred answer is not in expressing more notation in
precomposed form, then, but to make sure, with diligent bug
reporting and customer demand that more systems support the
necessary markup.
A./
Received on Fri Sep 30 2016 - 15:20:46 CDT