Although the specification writes the exact opposite, makeotf does
accept script and language statements inside named lookup blocks.
Since Glyphs.app (and possibly other tools, too) produce feature files
that make use of this syntax, enforcing the spec would break existing
files.
Resolves https://github.com/behdad/fonttools/issues/501.
After this change, feaLib synthesizes the same lookups as makeotf v2.0.90
for `feature aalt` in the example of section 8.a of the OpenType Feature
File specification.
Before this change, feaLib would group glyph-based pair positionings
by value formats. After this change, this logic happens in otlLib.
But clients can still do their own grouping if they wish, by calling
the buildPairPosGlyphsSubtable() method directly.
Before this change, feaLib had assigned a lookup index at the same
time as compiling each lookup. For chains, the implicit assumption was
that the chain's targets would always come before the contexual chain.
Normally this was indeed the case, but feaLib (and also makeotf)
sometimes merge several chain targets into one single lookup,
and then this assumption was not true anymore.
In the new version, the lookups get compiled in a separate pass,
after assigning lookup indices.
https://github.com/behdad/fonttools/issues/463
Not sure if empty ComponentRecords can be optimized away.
For the time being, leaving the output unchanged so that
the refactoring has no effect on the generated files.
In f0eb7e98ca0642f17ac82433db8c957fffd6a9d3, the various subclasses
of otTables.ClassDef were merged into one single class. Therefore,
we can now always instantiate otTables.ClassDef() which is simpler.
In f0eb7e98ca0642f17ac82433db8c957fffd6a9d3, the various subclasses
of otTables.Coverage were merged into one single class. Therefore,
we can now always instantiate otTables.Coverage() which is simpler.
Make the output of otlLib.buildLigatureSubst() deterministic.
Before this change, otlLib ligatures were emitted in a non-deterministic
sorting order (depending on what hash value Python would give
to a string tuple).
On Windows, some Python versions format "Jan 01" while others
format "Jan 1"; this caused test failures on the build farm.
By using a date without leading zeros (2011-12-13), we can
work around this.
https://github.com/behdad/fonttools/issues/455
