This checks that glyph names that appear in a feature file are actually
in the glyph set provided in glyphNames. If the set is empty, no check
is done. This preempts a KeyError later during saving of a TTFont object
and makes this case much more easily catchable.
Closes#1723.
Allow for making more lookups support subtabe breaks. Although AFDKO’s
makeotf supports subtable breaks only in pair pos lookups, I believe
that is an implementation limit that we don’t have to follow; all
OpenType lookups has subtables and it should be possible to code that in
the feature files.
ufo2ft feature writer calls feaLib builder with tables=[GSUB] first, to run closure
over glyph substitutions; if the GSUB features contains 'featureNames' blocks, then
an AssertionError will be raised; in this case, we can simply skip building the
FeatureParams tables as we haven't build the name records they point to.
This would make it easier to construct feaLib AST from code,
where the location is not defined and thus should be None.
Also, we can make other arguments as kwargs with a default
value, now that the first parameter is no longer 'location'.
`tables=None` by default will build all supported tables;
To build only some of these and ignore the others, one can pass a
subset of supported tables tags: .e.g. `tables={'GSUB'}` will only
build the GSUB, even if the feature file may contain e.g. GPOS
related features.
... instead of a glyphMap dict.
The parser does not actually need a reverse glyph order mapping as
it is not interested in knowing the glyphID from the glyph name,
but only whether a glyph is in the font or not.
This makes it easier for client code (e.g. ufo2ft feature compiler)
to use the feaLib Parser, without having to first construct and pass
it a glyphMap argument.
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
