Currently, the compiler uses them to figure out which set of
languagesystems would apply for the current scope. However, this
information is not yet used for anything.
Also add ';' to some langaugesystem test cases. This makes the
snippets syntactically valid. The parser is still expected to
reject them for other reasons, just as before this change.
This simplifies the public API to the library. For clients, it does
not matter which exact component was detecting an error. And we will
soon have more components; there would be little point in declaring
CompilerError, TableBuilderError, and so forth.
Before this change, the XML output for GSUB lookups of type 3
was not deterministic; multiple runs of TTX on the same font
could therefore emit the alternates in a different order.
Since alternate glyphs are sets, this change makes no semantic
difference to the output. However, a deterministic ordering
is needed for tests that compare GSUB tables in TTX format.
The data-structure can be used in more places, but it's most beneficial in
this table since hdmx tables can have tens of ppem's, each having a dictionary
keyed by glyphnames...
Reorder to OT spec recommended order if reorederTables == True (default).
Don't reorder if reorderTables == None.
Keep the input font original table order if reorderTables == False (and
the font has a reader object from which to get the original order).
In the new version, the parse_languagesystem_() function returns
an ast.LanguageSystemStatement, which then gets appended to the
current list of statements by the caller. Before this change,
the parse_languagesystem_() function would always append the
newly parsed statement to the list of top-level statements.
In practice, it does not matter because `languagesystem` is
only valid at the top level, but there is no good reason why
the parser method would have to be different from all other
constructs.
We will soon support additional blocks beyond `feature`,
and keeping this refactoring separate from new functionality
makes it easier for code reviewers to follow the changes.
The OpenType Feature File specification does not specify hex numbers
as explicit token type, but they appear several times in the examples
given by the spec.
