Freezing a stylistic set can cause other stylistic sets that replace overlapping glyphs to malfunction

[chris-morgan]

I have a font where certain glyphs are replaced in multiple stylistic sets. Out of the box, if I set both ss01 and ss02, the ss01 glyph “wins”. But when I freeze ss02 and enable ss01, the ss02 glyph wins, and based on the file size, I suspect (but haven’t confirmed) that it actually removed the conflicting ss01 glyphs.

I don’t what logic can be encoded in substitution tables, but it’d be good for this project to match it if at all possible. For example, if it’s a matter of sequential rules in a substitution table, I suppose you’d want freezing a feature to remove conflicting mappings from later in the table, while retaining those earlier in the table.

(The font in question is Triplicate; ss01 is the Poly variant, which makes the monospaced font not quite monospace, widening glyphs like m and narrowing glyphs like l; ss02 is the Code variant, which tweaks some of the glyphs for greater distinctness and clarity, like l which gets a tail. Unfortunately there are no glyphs for when both Code and Poly are enabled, but out of the box Poly wins on glyphs that both replace. On my website I always want Code enabled, and mostly want Poly, so I wanted to freeze Code on, but this had the effect of making Code trump Poly on conflicting glyphs, which made spacing look weird in a few places, most significantly around l.)

[twardoch]

If you have "a" and lookup1 associated with ss01 replaces "a" with "a.ss01", and lookup2 associated with ss02 replaces "a" with "a.ss02", then when you enable both features and you type U+0061, you get "a" which then gets replaced with "a.ss01" and the lookup associated with ss02 has nothing to replace.

If you "freeze" ss02, then U+0061 gets reassigned from "a" to "a.ss02" so it's the direct input. The lookup associated with ss01 then has no effect because it still expects "a" as input.

The tool is simple — it only reassigns the Unicode to another glyph (the one that is the result of a 1:1 replacement). It doesn't change the way other features work. That would be arcane and unpredictable (esp. in contextual subs). The tool is deliberately simple and works as designed.

[twardoch]

PS. The tool does not remove any glyphs, because a glyph from which it "steals" the Unicode may (or may not) be also used as an output glyph in some feature. So it's safer to "orphan" the glyph. (Because the tool is deliberately simple and does not try to be overly clever).

But you may use pyftsubset to remove these orphaned glyphs afterwards at your discretion.

[twardoch]

In the end, it really depends how the features are written in the font, on the order of the original lookups. The tool only changes the entry points to the OT features maze (reassigns the Unicode codepoints), but it keeps the maze untouched.