2016-09-30 18:54 GMT+02:00 Jukka K. Korpela <jkorp...@cs.tut.fi>: > 30.9.2016, 19:36, Philippe Verdy wrote: > > 2016-09-30 17:54 GMT+02:00 Jukka K. Korpela <jkorp...@cs.tut.fi >> <mailto:jkorp...@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).