Currently, the feature file parser always resolves included files,
parses their content and inserts it in the resulting AST. The original
`include` statement is lost.
This commit introduces an option to not follow inclusions. Instead, the
output AST will contain an `include` statement. This allows to process a
feature file on its own, and allows to round-trip it.
For example in glyphsLib, when going from a UFO to a .glyphs file, a
UFO feature file will be sliced up into Glyphs.app classes (e.g. a
GSFeaturePrefix with code `include(../family.fea);`) and when going back
from .glyphs to UFO, the feature file will be patched back together.
The syntax tree representation now reflects the syntax of feature files.
Before this change, FeatureNames did not have their own `ast.Block`,
which had made the code quite messy.
* [feaLib.ast] fix checking multiple markClass definitions don't redefine same glyphs
As pointed out by @mhosken, we are looking in the wrong list for glyphs
that have already been defined in a previous markClass definition.
With this patch, the current markClass.fea test case fails becuase it defines 'acute'
twice for the same @TOP_MARKS class:
fontTools.feaLib.error.FeatureLibError: Lib/fontTools/feaLib/testdata/markClass.fea:6:5: Glyph acute already defined at Lib/fontTools/feaLib/testdata/markClass.fea:3:1
Also see conversation at:
3b79d51755 (r94622074)
* feaLib/testdat/markClass.fea: remove duplicate 'acute' in @TOP_MARKS
Now the test pass, after 45c77b7
* [feaLib.builder_test] test case for redefined glyph in multiple markClass definitions
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.
* feaLib: limit language statements to 1 feature block
language exclude_dflt statements should only apply to lookups
defined in their feature block and not to lookups defined
in previous blocks sharing the same feature tag
* feaLib: add BuilderTest::test_FeatureFile_multiple_feature_blocks
Before this change, we had only emitted a SinglePos (GPOS type 1) lookup
for a statement like `pos A' B' 20`; after this change, we always emit a
chain rule even if there is no context. There is a semantic difference if
the rule is preceded by a `ignore pos` statement. Omitting context-free
contextual chains was actually not a (premature) optimization, but an
artifact that came from the representation of glyph patterns.
https://github.com/behdad/fonttools/issues/516
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).
Before this change, the compiler had (essentially) implemented lookup
references by inlining the statements of the invoked lookup into the
current feature block. After this change, the lookup gets compiled
separately, and any call sites make explicit calls.
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.
