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
Received on Thu Oct 06 2016 - 13:20:36 CDT
This archive was generated by hypermail 2.2.0 : Thu Oct 06 2016 - 13:20:36 CDT