For GPOS type 2, the OpenType Feature File format makes a semantic
difference between `glyph` and `[glyph]`, so we need to pass the
syntax tree for the kerned glyphs and glyph classes down to the builder.
Previously, we were expanding syntax tree nodes to glyphSets at
parsing time. Therefore, the builder could not distinguish a statement
for kerning two single glyphs from a statement for kerning two glyph
glasses, where each glyph class would consist of a singleton
glyph. (Debating whether or not it makes much sense to have this
distinction is outside the scope of fonttools; we want to implement
the language in its present form).
The builder does not yet use this information for building different
tables. This change is just about plumbing.
Again, this will be needed for eventually distinguishing `glyph`
from `[glyph]` or `@CLASS`, which makes a semantic difference
when building GPOS type 2 tables.
This will be needed for implementing class-based kerning. According
to the OpenType Feature File specification, a different table needs to
be built for `glyph` versus `[glyph]`.
Before this fix, the parser failed to process statements of the form
`lookupflag MarkAttachmentType @GLYPHCLASS;` when no other flag
were set after the glyph class. However, statements like
`lookupflag MarkAttachmentType @GLYPHCLASS RightToLeft;` were
getting recognized perfectly fine.
No output is generated yet, this change is just on the parser.
The OpenType Feature File specification is surprisingly vague about
the exact syntax of chaining contextual positioning rules, so I expect
that we will have to iterate on this parser. However, the test case
in parser_test.py gets recognized by `makeotf`, so the current
implementation is unlikely to be completely wrong.
While not really documented in the OpenType Feature File specification,
the AFDKO makeotf tool handles the `markClass` statement this way.
Also, some examples in the specification seem to imply this semantics.
The class names of tree nodes for substitution and positioning rules
are now consistent with `builder.py`, which in turn is consistent with
`otTables.py`.
The upcoming MarkLigPosBuilder will have some parts in common with
MarkBasePosBuilder. Move these common parts into a helper method,
so that MarkLigPosBuilder will be able to call them.
Also, clean up the structure of MarkBasePosBuilder.
However, not sure how to build the otTables object graph for emitting
GPOS tables with device values; the current code thus silently strips
off any device values. Left a TODO comment for implementing this.
Before this change, feaLib would sort coverage tables by glyph name,
which is against the OpenType specification. The current unittests
happen to use only glyphs where the ordering is identical whether
sorting by name or by ID; but I am about to add unittests (for GPOS)
where the ordering is different.
The ordering cannot be enforced by otTables because otTables does
not have access to the font's glyph order; therefore, the sorting
needs to happen inside feaLib.
Generated by running example 1 from the Feature File specification
section 5.f.i (Specifying a Chain Sub rule and marking sub-runs)
through AFDKO's makeotf tool, and then decompiling the resulting
GSUB table with ttx.
The actual test is commented out because the current version of feaLib
is not able to produce this output yet; marked with a TODO comment.
It is example 1 in section 5.f.i of the specification, and there
more examples in the same section. For consistency, use the same convention
as the other test cases.
