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, if someone tried to set the language before setting the script
a None/language language system would be created (with actual tag
"None" stored in the feature table). This defaults to tag DFLT and
fails when a non-dflt language is set for DFLT, since that's illegal.
This is to fix what I think was a misunderstanding of the exclude_dflt
keyword (and the implicit include_dflt option active by default).
Rather than including the following lookups in the default language
systems, I think it is used to include the lookups specific to default
language systems in the system defined by the current language
statement. Thus instead of registering a lookup in all default
systems when include_dflt is true, we should exclude the lookups
registered with default systems from the current system when
include_dflt is false.
Since py23 modifies some essential builtins, it's safe to import
everything all the time. At least, that's how it was designed.
It's a bug if importing * breaks some code.
'featurefile' can be either a path (string) or a file object, like in TTFont or XMLReader and XMLWriter constructors.
If a file object does not have a 'name' attribute, a default "<features>" name is
used and the current working directory is assumed as the root for relative includes.
According to the spec:
> The lookupflag attribute defaults to 0 at the start of a feature
> block.
>
> The lookupflag attribute stays the same until explicitly changed, until
> a lookup reference statement is encountered that changes it, until the
> script is changed, or until the end of the feature.
This is an attempt to fix this by resetting the lookupflag at the start
and end of feature/lookup blacks. I’m not sure if resetting it in lookup
blocks is correct (my reading of the spec suggests it is not), but one
needs to test this against makeotf and see how it behaves here.
In the long term, we might want to make a different low-level API
for building ChainContextPos lookups; for now, this should fix the
current bug with SequenceIndex.
Resolves https://github.com/behdad/fonttools/issues/517.
There should be no semantic difference from this change,
since dependent lookups (the chain targets) are never directly
invoked by a feature. But the output of feaLib becomes more
similar to the output of makeotf, which helps debugging.
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
