Re: Treatment of Variation Selectors in the Client

Maybe instead of reserving tags to put UVSes in FeatureRecords we could add UVSRecords parallel to FeatureRecords (with a new offset for the former), and instead of featureTag we could have variationSelector.

Skef
________________________________
From: Skef Iterum <siterum@adobe.com>
Sent: Thursday, October 17, 2024 9:12 AM
To: public-webfonts-wg@w3.org <public-webfonts-wg@w3.org>
Subject: Treatment of Variation Selectors in the Client

How do we want to, or plan to, handle Uncode Variation Selectors in IFT? Specifically, are we treating them as codepoints or not?

I may be reading the code wrong, but both the HarfBuzz and fontations subsetters variation alternates are treated as potential substitutes for "individual" Unicode regardless of the unicode values to be included. That is, the implementation doesn't look to see whether the variation selector itself has been requested to be included. So, in effect, UVS mappings are supported by default (unless I'm misreading).

It's not clear to me why this is the case. I suppose one explanation would be that certain shapers might use variation selectors implicitly, and therefore they aren't considered to be "real" codepoints. But in that case maybe we should treat them like layout features that are used by default, giving the option to a shaper, and therefore a client, to skip them when they aren't needed.

I'm thinking about this in relation to glyph-keyed patches. It seems to me that using a UVS is probably the exception rather than the rule. So why include all of the UVS alternates for a codepoint in its patch when you could (for example) stick them in a separate glyph-keyed patch for the selector itself? (Of course, you may have a lot of them, in which case I suppose one would need the equivalent of the special support for ligatures that Garrett has sometimes advocated for. Or I guess you could make a UVS-mapped patch for all of the high-frequency codepoints and then put the mappings for mid- and low-frequency codepoints in those patches.)

Another alternative would be to optionally treat each UVS like a layout feature, maybe by reserving some "tags" for them.

Skef