[instancer] _instantiateFeatureVariations() limitation when a range rule becomes applicable

With current logic, it’s possible that, as a result of pinning one axis, a rule becomes default-applicable, but we do not apply it by default. That is wrong.

Let me take an example from the test suite’s InstantiateFeatureVariationsTest::test_partial_instance, second test. Imagine the font has these rules:

        font = makeFeatureVarsFont( 
            [ 
                ([{"wght": (0.20886, 1.0)}], {"uni0024": "uni0024.nostroke"}), 
                ([{"cntr": (0.75, 1.0)}], {"uni0041": "uni0061"}), 
                ( 
                    [{"wght": (-1.0, -0.45654), "cntr": (0, 0.25)}], 
                    {"uni0061": "uni0041"}, 
                ), 
            ] 
        ) 

Now if we pin {"wght": -1.0}, currently the test suite says no appliedSub, and the following expectedRecords:

                [ 
                    ({"cntr": (0, 0.25)}, {"uni0061": "uni0041"}), 
                    ({"cntr": (0.75, 1.0)}, {"uni0041": "uni0061"}), 
                ], 

However, this is wrong. Because now the rule ({"cntr": (0, 0.25)}, {"uni0061": "uni0041"}) is default-applicable because it starts at 0, so we should also copy its substitution into appliedSub.

But if we do that, the appliedSub will be applied to the entire space. So we then need to disable that at the end with a catch-all rule. That is:

                [ 
                    ({"cntr": (0, 0.25)}, {"uni0061": "uni0041"}), 
                    ({"cntr": (0.75, 1.0)}, {"uni0041": "uni0061"}), 
                    ({}, {}),
                ], 

Fixing this is hard but doable. I can do it but I prefer to do after merging the L4 branch.

[anthrotype]

most implementations do NOT process variation-specific tables at the default-instance (0) location

I see… that’s the part I was missing…

[behdad]

I like to attack this one soon. Need to get in the zone.