Why incomplete subscript/superscript alphabet ?

[Philippe Verdy]

2016-09-30 18:54 GMT+02:00 Jukka K. Korpela <jkorpela at cs.tut.fi>:

> 30.9.2016, 19:36, Philippe Verdy wrote:
>
> 2016-09-30 17:54 GMT+02:00 Jukka K. Korpela <jkorpela at cs.tut.fi
>> <mailto:jkorpela at cs.tut.fi>>:
>>
>>     Using HTML, for example, the way to achieve that at present would be
>>     to use markup like <span class="sub">...</span> (to avoid the
>>     problems caused by the default formatting of <sub> and <sup>) and to
>>     use a CSS style sheet that sets font-family suitably and uses
>>     OpenType font feature settings to select subscript or superscript
>>     glyphs. In practice, you would need to use @font-face to embed a
>>     suitable OpenType font. So it’s doable, but not trivial like just
>>     slapping <sub> and </sub> around some text.
>>
>>
>> Not needed. the <sup> and <sup> elements in HTML can be styled directly
>> as well (also with CSS)
>>
>
> I didn’t want to go into details, but probably I now need to mention that
> some browsers, rather unpleasantly, interpret relative font sizes for <sup>
> and <sub> as relating to their default font size in that browser, against
> CSS specs.


Bug the authors of these browsers. But most probably those browsers are
antique and no longer supported. So bug users of these old tools and ask
them to switch. I've not seen any decent modern browser not correctly
respecting the CSS styles you set for the relative size and positioning for
superscripts/supbscripts. It is very easy to do with basic CSS stylesheet
for your document (or website/application).

There's not a lot of modern browsers. The antique browsers no longer
supported are those you find in embedded systems (in their limited
firmware), but they are not the best systems to use to read a technical
documentation, and generally not used by programmers; they all have a
decent PC with a decent browser, or TeX tools, or decent word processors.

These bugs will be solved sooner or later IF there are people requesting
their resolution and a demonstrated usage of these tools (or fonts,
rendering libraries...), or if they pay developers for these needed
corrections. Unicode encodes characters for the long term, but not because
some current tools may have some rendering bugs (that are already resolved
is similar tools). Most of these tools already have several alternatives
some ill disappear new one will be created offering better support.

The only thing that cannot be corrected are historic documents used as
sources and for which there's a need to find an appropriate representation
: if this can be done at character level, may be they will be encoded,
provided that there's evidence thhat they require distinction.

But in your case there's no distinction: the "start" and "end" words in the
formulas are regular English words that should better encoded using normal
Latin letters (the extra layout needed for the formula is not encodable);
using some encoded superscript/subscripts to write them is really a hack,
don't expect them to have a coherent layout or style matching what you
expect in your formulas, they were mostly encoded for compatibility with
old encoding standards (because old archived documents won't be
reencoded/recreated for use with newer tools).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20160930/b8f4233b/attachment.html>