Support was added in db49f20d6b2629e1ba25c4afd3fb60817387f3d6, but there
was only a parser test and no builder test, fix the build and add a
builder test based on the existing parser one.
Fixes https://github.com/fonttools/fonttools/issues/1901
Setting script that is the same as current language system should make
no effect. This is not documented in the spec, but it is what makeotf
does. This as the effect of preserving lookupflag when set before such a
script statement.
Fixes https://github.com/fonttools/fonttools/issues/1824
If Coverage is None then the subtable is a noop that does nothing and
there is no point in building it. As a bonus, it makes OTS happy since
it will reject subtables where coverageOffset is NULL (0) and the spec
does not say whether this is allowed or not.
Specifically, contextual positioning statements with in-line single
positioning rules, in horizontal and in vertical contexts. For these
test cases, feaLib and makeotf produce the exact same output.
https://github.com/fonttools/fonttools/issues/633
If a zero value appears in a SinglePos statement, feaLib continues to
produce ValueRecords of format 0. But if a zero value appears in a
PairPos statement inside a horizontal compilation context, feaLib now
produces ValueRecords of format 4. Likewise, if a zero value appears
in a PairPos statement inside a vertical compilation context, feaLib
now produces ValueRecords of format 8.
The OpenType Feature Syntax specification is completely silent about this,
but the new behavior matches that of makeotf.
https://github.com/fonttools/fonttools/issues/633
In context of SinglePos, makeotf compiles zero values to value records
of format 0. feaLib already does the same, but it's good to have tests
to make sure that this doesn't accidentally change.
https://github.com/fonttools/fonttools/issues/633
We now correctly handle nameid statements with surrogate pairs and
old-style macOS-encoded names (provided that fonttools supports the
specified encoding).
Resolves https://github.com/fonttools/fonttools/issues/842.