varLib.featureVars needs rethinking

[simoncozens]

I'm trying to complete the implementation of the variable FEA syntax by adding support for conditionsets and the variation block. I presumed that I would implement the builder for the variation block by using varLib.featureVars, but...

• It seems like this only supports GSUB, not GPOS. According to OTSpec, either table can take a FeatureVariation.
• It seems like this only supports (and takes as parameter) single substitution rules. According to OTSpec, any feature index can be substituted by any other feature index.

I think what we need to do to correctly implement feature variations is to first change addFeatureVariationsRaw so that it takes a table parameter, and then do the right thing for GPOS as well as GSUB. This part is easy.

But the next part I can't quite figure out. Instead of passing in a list of (Region, Substitution)s, I think we want to pass in a list of (Region, FeatureRecord)s. But what this means for overlayFeatureVariations, I have no idea.

Here's the example variation block from the proposed FEA spec:

conditionset heavy {
    wght 700 900;
} heavy;
variation rvrn heavy {
    lookup symbols_heavy;
} rvrn;

But one could equally imagine

variation mkmk heavy {
    script arab;
    language ARA;
    lookup heavy_arab_mkmk_anchors;
    language URD;
    lookup heavy_urdu_mkmk_anchors;
} mkmk;

[justvanrossum]

[varLib.featureVars]

• It seems like this only supports GSUB, not GPOS. According to OTSpec, either table can take a FeatureVariation.
• It seems like this only supports (and takes as parameter) single substitution rules. According to OTSpec, any feature index can be substituted by any other feature index.

Yes, it was a concious decision to make feature variations at least possible for the most common and obvious use case, one that could also easily be added to .designspace. Making it as general as the OT spec allows would have prevented getting this stuff done within a reasonable amount of time, because it's so much more complex. At least that's how I remember seeing it back then.

[simoncozens]

That's fine; I understand the historical basis for it, and it was the right thing at the time. But now we are thinking about extending things to take full advantage of the possibilities of the OTspec, I am wondering how to take things forward.