Fwd: Why incomplete subscript/superscript alphabet ?

[Jukka K. Korpela]

6.10.2016, 19:27, Ken Whistler wrote:

> Their functions have been completely overtaken by markup conventions
> such as <sub>...</sub> and <sup>...</sup>, which *are* widely supported
> already, even in most email clients, ri^ght out of the b_ox .

They are widely supported, but very widely in a typographically inferior 
way. This is essential especially when it comes to things like “3ème”, 
where one might want to display the letters in superscript style as a 
matter of typography-

> And I suspect that Yucca's statement "so it would usually be best to
> give up the superscripting idea here" is intended to mean give up on
> asking for a separately encoded superscript character for each Latin
> letter, including accented ones

Not quite. Adding superscript characters for all Latin letters is not a 
good idea at all, but I was not referring that. Instead, I suggested 
that in a case like “3ème”, it’s best to give up the idea of 
superscripting the letters using any techniques available now (including 
e.g. <sup> markup), in most situations. Flat rendering of “3ème” is 
better than a typographically poor rendering with superscripts.

> Because, after all, this stuff already
> just works: «3^ème » (and not «3ᵉ̀ᵐᵉ», by the way!).

It works for a rather limited range of values for “works”. I’m not sure 
what happens in my reply... it seems that Thunderbird does something 
funny here. Anyway, what I saw in my Thunderbird is what I usually see 
when <sup> is used: “ème” in slightly reduced font in elevated position, 
messing up line spacing, and looking rather different from superscript 
glyphs designed by a typographer.

Independently of the technique used to ask software to show something as 
a superscript (e.g. using a superscript character code point in Unicode, 
using <sup>, using superscript formatting in a word processor, or using 
^{...} in TeX), typographically accepted rendering must use a 
superscript glyph, designed by a typographer to match the overall style 
of the font, or maybe a sophisticated algorithm that constructs the 
rendering from a normal glyph.

In a sense, superscript code points make this easier: the rendering can 
simply pick up the corresponding glyph for the font – if it has one (a 
big “if”). But this is not a good argument in favor of adding such 
points en masse. It is, however, a good argument in favor of using 
existing superscript code points, like “²”, with good font support.

Yucca