Open palemieux opened 2 months ago
The Timed Text Working Group just discussed Superscript/subscript support w3c/imsc#583
, and agreed to the following:
SUMMARY: Investigation into requirements to continue, agenda+ for TPAC
@nigelmegitt @palemieux Note that #derivation-fontVariant says that [font-variation-position
]() applies for normal
, super
, and sub
, which in turn says here that:
Because of the semantic nature of subscripts and superscripts, when the value is either ‘sub’ or ‘super’ for a given contiguous run of text, if a variant glyph is not available for all the characters in the run, simulated glyphs should be synthesized for all characters using reduced forms of the glyphs that would be used without this feature applied. This is done per run to avoid a mixture of variant glyphs and synthesized ones that would not align correctly. In the case of OpenType fonts that lack subscript or superscript glyphs for a given character, user agents must synthesize appropriate subscript and superscript glyphs.
@skynavga in your experience/mind, subscript/superscript is no different than bold and italic, i.e., a different variation of a font for a given character?
I was also surprised that Chrome did not support font-variation-position: super
if it is equivalent to <sup>
@palemieux
in your experience/mind, subscript/superscript is no different than bold and italic, i.e., a different variation of a font for a given character?
Yes, for higher end fonts (where the designer pays attention to these matters). However, many fonts contain a small set of sub/super glyphs without having the corresponding OpenType substitution table, and, indeed, Unicode itself codes a few sub/sup variants as characters in their own right. I don't actually recall seeing an independent font resource for sup or sub or both (in the sense that one encounters bespoke bold, italic, and bold-italic font resources).
A good text layout/rendering engine will take heed of the language I cited from CSS3 Fonts regarding the need to synthesize glyphs on demand. Indeed, I used this approach to synthesize ruby glyphs in ttt/ttt-ttpe
.
@skynavga Any reason why font-variation-position: super
is not supported in Chrome, but <sup>
is? Could we say, in TTML2, that tts:fontVariant="super"
is the same as <sup>
?
@skynavga Any reason why
font-variation-position: super
is not supported in Chrome, but<sup>
is? Could we say, in TTML2, thattts:fontVariant="super"
is the same as<sup>
?
@palemieux Couldn't say. Haven't been connected to the Chromium project in ages (is it still a thing?). I wouldn't want TTML2 to make a reference to HTML5 to obtain the semantics of <sup>
. I think the semantics described in CSS3 Fonts are just fine, as it gives plenty of latitude for implementation behavior. Note, however, that TTML2 doesn't normatively use the CSS3 Fonts semantics in this context, but, rather, it is merely an indirect reference as such. Think of it as a hint.
See discussion at https://github.com/w3c/csswg-drafts/issues/7441
font-variant-position is a bit useless - as it may or may not generate superscript, everyone just uses font-size and vertical-align
Ok. I view this as an implementation matter. TTML2 doesn't actually reference font-variant-position
in a normative manner. So it is up to a presentation processor's implementation to decide how to render tts:fontVariant
, whether it be custom rendering code, mapping to font-variant-position
, font-size
with vertical-align
, or <sup>
, etc.
Notwithstanding this, I agree that the current normative language defining tts:fontVariant
focuses only on glyph selection without mentioning fallback strategies in the absence of selectable glyphs. I wouldn't object to a Note being added (to §10.2.23) that elaborates potential fallbacks, which I would probably write in terms similar to that found in CSS3 Fonts as cited above.
For the use case where both a superscript and subscript are needed (chemical symbols etc), vertically above each other, I think font-variant-position
does not work, but Firefox at least does seem to do what CSS says and synthesise superscript and subscript for ordinary letter-like symbols.
I created a codepen to demonstrate different HTML and CSS techniques for superscript and subscript. In many ways the easiest to implement is the one using table layout, though I haven't worked out a more elegant way to get only superscripts to work than putting a non-breaking space character into a <span>
so that there's something occupying the subscript row, which pushes the superscript row up to the top.
Firefox rendering:
The Timed Text Working Group just discussed IMSC superscript/subscript support w3c/imsc#583
, and agreed to the following:
SUMMARY: EBU positive about requirement, unclear if anyone "cannot live without" the feature.
IMSC currently does not support superscript/subscript text, which is desirable (if not essential) in some languages.
French, for example, uses superscript to abbreviate ordinal numerals. The same is true in English, albeit perhaps less necessary, e.g., 1st might be as acceptable as 1st.
Couple of observations:
sup
/sub
markup.tts:fontVariant="super"
which is mapped to CSSfont-variant-position
, but (a) few fonts have super variants and (b) subscripting/superscripting seems more of a semantic or layout issue than a font/glyph selection issue.CEA 708 has the concept of superscript/subscript (offset pen attribute).
In fact it looks like
tts:fontVariant
was introduced, at least in part, to match CEA 708 capabilities, although, as mentioned above, it is not clear that it is a perfect match (or at least the mapping to CSS is not ideal).