Instance kerning data should reflect switched masters

[LettError]

A glyph can have different masters in specific instances. This way a glyph can have a radically different construction in some weights or widths. In Superpolator this is the rules feature.

Currently the kerning is unaware of these new masters. That means the kerning data generated for that glyph will be invalid as they depend on the old glyph geometry. So the kerning will need to be manipulated to insert the kerning of the replacement masters.

Any number of glyphs may be switched, so it will probably need to be some sort of child element of the kerning element.

[LettError]

The instance needs to record which glyphnames need to be swapped. Some instances might have swaps, others might not. The elements could look like this:

<kerning>
        <!-- if swap elements are present, change one name for the other in kerning, groups -->
        <swap glyphname="a" with="a.alt">
</kerning>

• When are the glyphs swapped? Preferably before unwanted glyphs are removed from the instance.
• How is this element interpreted, what are the expected effects? Change all the kern pairs that have this name. How about the groups?
• Should there be any validation of the kerning afterwards?

[LettError]

It is useful to improve the mechanism for switching glyphs in generated instances.

Currently:

An alternative set of masters can be defined for a glyph in order to give it a different appearance. However, this can give unexpected results with components that now point to a new shape.

Rather than just replace a shape, a swap will give clearer results. Both the old and new shapes continue to be part of the font and components can be remapped to maintain appearance. The kerning can also be remapped.

Option 1: store the swaps

This means the swapping has to be done after generating the instance. It also means the information about the swap needs to available. The swaps could be explicitly recorded in each instance like this:

...as part of an instance element
    <swaps>
                <swap name="a" with="a.alt" />
                <swap name="adieresis" with="adieresis.alt" />
    </swaps>

When <swap> elements are present, the glyph elements in the instance should not have other masters.

Option 2: store the rules

Or the rules and conditions could be stored separately and executed. This means a more compact notation, but it means more work for the rules logic. The xml could look like this, a rules element at the same level as instances and sources:

    <instances.../>
    <sources.../>
    <rules>
        <rule logic="all">
            <condition axisname="weight" operator="&gt;" xvalue="500.000000"/>
       ...more conditions
            <swap glyphname="a" with="a.alt">
            <swap glyphname="adieresis" with="adieresis.alt">
       ...more swaps
        </rule>
    </rules>

This allows several swaps be combined into a single set of conditions. The use of wildcard naming might be considered, but it might create confusing situations.

Discussion

• Option 1 is an extension of what is possible now. Using swapping will improve reliability. But the instance elements might contain considerable numbers of swap elements. It will not be possible to reconstruct the rules from this data.
• Not sure if the old replace behaviour needs continued support if swap is implemented.
• Option 2 is more ambitious. The code that interprets and executes the rules could be fairly independent with its own test cases.
• Could always just start with implementing option 1.

[LettError]

Option 1 implemented in this branch. Test font works as expected.

[LettError]

Given the pending implementation of conditional GPOS and GSUB, I'm rethinking the role of rules in Sp. A preview / editing functionality of those things will have to be closer integrated in the font editor.

[LettError]

Closing this for now.