Investigation: Subscript and Superscript

[DJMcNab]

I have been doing some research into what it would take to implement subscript and superscript. For my current use case, I think that the current state is actually sufficient (however, this assessment was made is before any code is written). See the details section for a sketch of how this can be done.

Implementing subscript with the current Parley

To implement a "good-enough" version of subscript in current Parley, we can emulate it with a marker associated with the brush, and a font size modifier. When we see the marker, we manually adjust the glyph.y down by (say) 30% of the line's (or possibly run's?) line height. These numbers are all tweakable, and aren't the point of this section.

Raph did point out that this has edge cases with ligatures (e.g. if you have a normal run of ff with font size of 12, then a subscripted i with a font size of 16), then this pattern would accidentally combine them together. This also applies to languages with more complex shaping.

Some sources about implementing this with full fidelity:

• Vertical alignment and the concept of a "parent" font and style #291 is tracking the vertical alignment part of this. I haven't yet dug into whether subscript and superscript in the general case run into the described issue around parent styles.
• The font-variant-position CSS attribute https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/font-variant-position. In particular, this describes the subs and sups opentype features.
• The OS/2 metrics for this - https://learn.microsoft.com/en-us/typography/opentype/spec/os2#ysubscriptxsize. The CSS spec for font-variant-position has a note on this which is worth reading. https://drafts.csswg.org/css-fonts/#font-variant-position-prop:~:text=glyphs%2E-,The,glyphs

[nicoburns]

Some notes:

• I totally agree that it makes sense to start by just reducing the font size rather than trying to use the opentype feature. That could be added later.
• Re: "we manually adjust the glyph.y down by (say) 30% of the line's" - there are "subscript" and "superscript" baselines in (the BASE table of) most fonts, which tell you exactly where the glyph should be positioned (vertically) relative to the baseline of regular glyphs in the font. There are also sensible fallback offsets (2/5th IIRC - it was 1/5th down for subscript or 1/3rd up for superscipt - see https://www.w3.org/TR/css-inline-3/#baseline-shift-property) for this in one of the CSS specs.
• Extracting the subscript and superscript baselines from the font could be done in Layout::push_run. We already have access to a read_fonts::FontRef of the font at that point, which we use to extract some other font metrics.
• It may make sense to control this with a vertical-align style with baseline (default value - existing behaviour), subscript and superscript variants. This could then be extended with some of the other variants.
• (but perhaps there is an alternative model from a non-css source - I'd be interested to see how it is handled elsewhere)

In my mind, the trickiest bit of this is working out what a given glyph needs to be aligned relative to. For example, what if you have nested subscript. Or subscript immediately followed by superscript. CSS solves this by having a tree structure for the spans, and aligning everything relative to it's parent / the line. I'm not sure how you solve this in a flat structure.

Raph did point out that this has edge cases with ligatures (e.g. if you have a normal run of ff with font size of 12, then a subscripted i with a font size of 16), then this pattern would accidentally combine them together.

I might be wrong (might have changed with HarfRust changes), but I believe that so long as the ff and i are in spans with different styles, they won't be shaped together in current Parley.

[DJMcNab]

Re: "we manually adjust the glyph.y down by (say) 30% of the line's" - there are "subscript" and "superscript" baselines in (the BASE table of) most fonts, which tell you exactly where the glyph should be positioned (vertically) relative to the baseline of regular glyphs in the font. There are also sensible fallback offsets (2/5th IIRC - it was 1/5th down for subscript or 1/3rd up for superscript - see https://www.w3.org/TR/css-inline-3/#baseline-shift-property) for this in one of the CSS specs.

I'm finding it quite hard to understand how to actually use this. From a (very quick) scan of the Microsoft Page, it looks like this would be something you need to use in combination with the subs opentype feature. That is, it isn't relevant for the near-term plan. I think the OS/2 metrics however do meet your description, but obviously I've already mentioned those. Happy to be corrected if I'm wrong - I've not found a docs page which makes this especially clear.

In my mind, the trickiest bit of this is working out what a given glyph needs to be aligned relative to. For example, what if you have nested subscript. Or subscript immediately followed by superscript. CSS solves this by having a tree structure for the spans, and aligning everything relative to it's parent / the line. I'm not sure how you solve this in a flat structure.

I do agree, although for my use case I'm in the fortunate position where we only support a single level of sub/superscript.
(The general case of the hacky version could be made to work though, by just manually calculating the offset from the shared baseline, presuming that you have the tree structure available).

I might be wrong (might have changed with HarfRust changes), but I believe that so long as the ff and i are in spans with different styles, they won't be shaped together in current Parley.

Thanks for info. That seems plausible to me. I'll make sure I test it either way 🙃

[nicoburns]

You may well be right about the metrics. I didn't realise these were available in OS/2. Although it may also still be the case that the BASE metrics are better (and provide things like script-specific baselines for fonts with multiple scripts). Either way, starting with os2 sounds like a good plan.

I should also point you towards #579 which implements subscript and superscript! It's currently just using hardcover fallback metrics for everything except x_height, but I believe it should be easy to plumb through extra metrics (copy how it's done for the x_height and primary baseline).