This should be a bit more efficient as we don't need to create a temporary list
object before passing it to "".join() method of str; the latter accepts any
Iterable
* First round of adding fea output
No format tests but all test files give reasonable output so far.
* Get existing tests working
* Initial tests that work for fea2fea
* Get more tests working
Bug fixes and re-layout some tests to compare with fea2fea output.
Ranges and name parameters are not optimised yet.
* Handle vertical default values in fea2fea
* Hide fea2fea differences in lookupflags
* No reduce() in py3 so use a for loop
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#10
For example, @mhosken is interested in experimenting with inlining
custom syntax (such as Python snippets) into feature files. After this
change, such experiments can be done on top of feaLib because the
Abstract Syntax Tree now contains the tag and content of `anonymous`
blocks.
Although this construct is in violation of the `ignore sub` grammar
given by the current OpenType Feature File syntax specification,
the very same specification document illustrates (in example 3
of section 5.f.ii) the `ignore sub` statement with a comma-separated
list of backgrack/input/lookahead triples.
See https://github.com/adobe-type-tools/afdko/issues/105 for a request
to amend the OpenType Feature File syntax specification.
After this code change, feaLib can now parse testdata/spec5f_ii_3.fea;
the output is identical to what is generated by Adobe's makeotf tool.
https://github.com/behdad/fonttools/issues/503
https://github.com/behdad/fonttools/issues/445
Not sure whether it makes much sense to define a contextual chain
that points to a GSUB type 3, but the OpenType feature file syntax
does not explicitly forbid it. Adobe's `makeotf` tool rejects this
kind of input with "Contextual alternate rule not yet supported";
this implies that the construct is valid (albeit definitely exotic).
Resolves https://github.com/behdad/fonttools/issues/445 for single
substitutions. The compact forms for chaining to other GSUB types
are not yet supported; these will get fixed in follow-up changes.
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.
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`.
