* 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
After this change, feaLib generates the exact same output as makeotf
for the test case in `bug453.fea`. Before this change, feaLib had
rejected the input as malformed.
Our new behavior is in blatant violation of the OpenType Feature File
Syntax specification, which writes: "NOTE! If a GDEF table is not
explicitly defined in the feature file, [...] all mark glyph classes
must be disjoint". However:
1. makeotf does not enforce this constraint;
2. existing feature files happily define non-disjoint markClasses;
3. existing tools such as the Glyphs font editor generate feature files
with non-disjoint markClasses;
4. it is not obvious what the intention of this constraint would be.
Therefore, fewLib now follows the makeotf implementation, intentionally
ignoring what is mandated by the specification. I've proposed a spec change
at https://github.com/adobe-type-tools/afdko/issues/106.
Resolves https://github.com/behdad/fonttools/issues/453.
There are no examples for `ignore pos` in the OpenType Feature File
Syntax specification, therefore using a made-up example for the test.
The output from feaLib is identical to what makeotf generates.
Resolves https://github.com/behdad/fonttools/issues/503.
This is another test case for the `ignore sub` statement.
After the recent changes to feaLib, the output is now identical
to the output generated by makeotf.
https://github.com/behdad/fonttools/issues/503
This makes the output of feaLib more compact, using a similar technique
as seems to be used by makeotf.
After this change, feaLib generates output that more similar to makeotf:
* For the test cases in `bug512.fea` and `bug463.fea`, feaLib now
generates the exact same output as makeotf v2.0.90.
* For the test cases in `GSUB_6.fea`, it is hard to say because makeotf
crashes on the test file; our test contains language constructs that
are valid according to the spec, but didn't yet get implemented by makeotf.
When commenting out those constructs, feaLib generates the exact same
output as makeotf v2.0.90.
* For the test cases in `feature_aalt.fea`, the output of feaLib is now
structually the same as the output of makeotf v2.0.90. However, two
lookups are in different order. feaLib's ordering reflects the order
of statements in the compiled input source; no idea why makeotf would
want to reverse the ordering. Since this ordering difference only
affects the _targets_ of chain substitutions, there is no semantic
difference.
Resolves https://github.com/behdad/fonttools/issues/512.
