When a SinglePost lookup is compiled, pretty much all compilers do some compression by combining similar ValueRecords into a single subtable. This compression produces different lengths of the list of subtables between source fonts. The original code required that all SinglePos lookups have the same subtables, often doesn't work.
I fixed this in varLib.merger.py by first flattening a SinglePos lookup to a single subtable, using the same record format for all records, and then merging the source fonts. After the merge is complete, I call fontTools.otlLib.builder.buildSinglePos() to rebuild the lookup subtables.
Also, the TTFont.getGlyphOrder() automatically makes up a dummy
glyph order from the maxp.numGlyphs, we simply need to ensure
'maxp' is decompiled before 'glyf'.
When transforming glyf, the glyf.glyphOrder is guaranteed to
be present (as the glyf table has been already decompiled), so
we don't need to deal with it being missing or incorrect
(hence removed spurious tests).
some tests were failing when shuffling the order of the tests with
pytest-randomly. That's because calling TTFont.getTableData method
on 'loca' table before having compiled 'glyf' returns an empty b""
string.
the buildGSUB function creates an empty GSUB with no FeatureRecords, so the
FeatureIndex list should be empty initially; the index of the newly created
rvrn feature record will be appended later on by addFeatureVariationsRaw
function.
The code was setting GlyphClassDef.classDefs for the base font to an
empty dict then reading it from all fonts. It accidentally works when
creating variable fonts because the GlyphClassDef of the other fonts
will be used, but when mutating there is only one font.
Fix by reading the glyph classes before assigning to an empty dict.
When --recalc-bounds option is used the font extents in the head table
need to be updated, but since tables are lazy-loaded by default the
table will not be recompiled and will keep the old value. Force
recompiling the table by adding it to prune_post_subset tables, though
I’m not 100% sure this is the best approach.
