Kern splitter: Different number of kern features per master

[madig]

In one of our fonts, with ufo2ft 2.29.0b1 I get the following message when compiling a VF:

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation:
GPOS.table.FeatureList.FeatureCount

The problem is likely to be in Something Cd Hair Italic:
Expected to see .FeatureCount==11, instead saw 9

Incompatible features between masters.
Expected: kern, kern, kern, kern, kern, kern, kern, kern, kern, mark, mkmk.
Got: kern, kern, kern, kern, kern, kern, kern, mark, mkmk.

Will dig deeper later.

[madig]

I think it's because one master has kerning for more scripts than the other (can happen during developement). So, the feature writer would need to probe all other masters or there should be special logic when merging.

[simoncozens]

The variable kern feature writer should help with this, but it currently has a bug: we only look for the set of kerning pairs in the default master, and then check other master for their values. If non-default masters have kern pairs that the default master doesn't have, they're not picked up. (I'm hitting the same issue in triangulate as well; funny how these things often come together.)

It will need to gather the set of kerning pairs from all masters, and assign a value of zero to those where the kern is not present. (Except presumably sparse masters, which should get "no value" when the pair is not present and not take part in interpolation. Twisty.)

[madig]

So far, we couldn't deal with sparse master layout because we couldn't subset feature files for them and then merging would be difficult on top. Will the variable feature writers fix that?

And yeah, sparse kerning is another topic.

[anthrotype]

one master has kerning for more scripts than the other (can happen during developement)

can it happen during production too? Can a font developer work around this limitation by adding dummy (0 valued) kern pairs to the masters with the missing scripts? I have a feeling that ufo2ft doesn't write out the kern pairs when the value is 0, but need to triple check.

[madig]

Yes it can. I made a test font here: Kern.zip -- kerning value in light (default source) and bold, but not regular. Currently, varLib seems to make the value interpolate across regular instead of inserting a zero, which I suppose is the behavior we want. Kerning values can have their own interpolation model I think, independent of the glyphs they relate to. Or maybe it's a design mistake? I don't know.

Maybe the "solution" here is to insert empty lookups where appropriate, just to make them line up for varLib?

[simoncozens]

We need to maintain a semantic difference between a zero kern and a non-existent kern.

Consider: Regular AV kern = -100, SemiBold AV kern = (sparse), Bold AV kern = -200.
I would expect the missing kern in the SemiBold master to be interpolated and end up at around -150 units.

If we start filling zeroes in, a kern = 0 in there would have a very different effect!

[madig]

Yes, my understanding is that every value has its own independent variation model, so missing explicit in-between values give you something interpolated instead.

[Hoolean]

In discussions and testing for googlefonts/fontmake#998, we identified that:

• Where a source has no kerning or GPOS features, fontmake will assume the kerning is interpolated at that position in the final font; and
• Where a source has any kerning or GPOS features, fontmake will assume any kerning pair with no entry has an effective value of 0 at that position in the final font (as it would have if the source were compiled as an independent UFO).

To encounter the incompatibility error in this issue, the source must have some kerning or GPOS features, and so we will always be supporting the latter case.

For this reason, we can implement a fix by adding kern lookups that kern pairs to 0 as necessary to reach compatibility, as the expected output is for these pairs to become unkerned with no per-pair interpolation, as would happen if they were absent from any of the already-existing lookups.

[Hoolean]

(the above is written under the assumption that sources with no kerning or GPOS are treated as sparse and will not receive compatibility errors; this appears to be correct for fontmake, but does this logic originate from ufo2ft?)

[madig]

Where a source has no kerning or GPOS features, fontmake will fill it with interpolated kerning; and

Do you mean fontmake won't do anything and the shaper will do the interpolation on the fly?

[madig]

For this reason, we can implement a fix by adding kern lookups that kern pairs to 0 as necessary to reach compatibility, as the expected output is for these pairs to become unkerned with no per-pair interpolation, as would happen if they were absent from any of the already-existing lookups.

It's still early morning for me; how does this interact with my thoughts in #635? As in, I think you have to take the union of pairs and backfill missing pairs for each individual source with lookupKerningValue? Wouldn't this be a pre-processing step you have to do before VF compilation and instance interpolation?

[Hoolean]

Do you mean fontmake won't do anything and the shaper will do the interpolation on the fly?

Potentially yes, thanks for the catch, my reply was muddling the variation model and how fontmake implements it. Corrected it now 👍

It's still early morning for me; how does this interact with my thoughts in #635? As in, I think you have to take the union of pairs and backfill missing pairs for each individual source with lookupKerningValue? Wouldn't this be a pre-processing step you have to do before VF compilation and instance interpolation?

I've just shot a reply to #635 📫 For this issue we could avoid the pre-processing step if adding empty lookups, as exception pairs cannot cross the per-script lookup boundary.