Re: Why incomplete subscript/superscript alphabet ?

From: Asmus Freytag (c) <>
Date: Fri, 30 Sep 2016 13:18:56 -0700
On 9/30/2016 11:26 AM, Michael Everson wrote:
On 30 Sep 2016, at 08:07, Jukka K. Korpela <> 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. 1st); 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.

Received on Fri Sep 30 2016 - 15:20:46 CDT

This archive was generated by hypermail 2.2.0 : Fri Sep 30 2016 - 15:20:47 CDT