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.
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
For this construct, makeotf throws an error: "Contextual alternate
rule not yet supported". If it had been implemented, we speculate
that the ordering would likely be the same as with other contextual
substitutions (the chain comes before, not after, the dependent lookup).
https://github.com/behdad/fonttools/issues/507
Before this change, the `script` statement had inherited global
defaults. After this change, it overrides them. The new behavior
matches the behavior of makeotf v2.0.90.
Resolves https://github.com/behdad/fonttools/issues/505.
For the test case of https://github.com/behdad/fonttools/issues/501,
which was about an unrelated problem, feaLib now produces the exact
same output as makeotf v2.0.90.
Although the specification writes the exact opposite, makeotf does
accept script and language statements inside named lookup blocks.
Since Glyphs.app (and possibly other tools, too) produce feature files
that make use of this syntax, enforcing the spec would break existing
files.
Resolves https://github.com/behdad/fonttools/issues/501.
After this change, feaLib synthesizes the same lookups as makeotf v2.0.90
for `feature aalt` in the example of section 8.a of the OpenType Feature
File specification.
Before this change, feaLib had assigned a lookup index at the same
time as compiling each lookup. For chains, the implicit assumption was
that the chain's targets would always come before the contexual chain.
Normally this was indeed the case, but feaLib (and also makeotf)
sometimes merge several chain targets into one single lookup,
and then this assumption was not true anymore.
In the new version, the lookups get compiled in a separate pass,
after assigning lookup indices.
https://github.com/behdad/fonttools/issues/463
No changes in the compiled binary representation, this just affects XML.
After this change, the XML for empty ValueRecords is identical to the
output from makeotf.
https://github.com/behdad/fonttools/issues/471
On Windows, some Python versions format "Jan 01" while others
format "Jan 1"; this caused test failures on the build farm.
By using a date without leading zeros (2011-12-13), we can
work around this.
https://github.com/behdad/fonttools/issues/455
Before this change, feaLib did not handle feature files that specified
`feature aalt` whose block just was referring to other features without
defining any lookups on its own. After this change, we can handle it.
Resolves https://github.com/behdad/fonttools/issues/441
The current OpenType Feature File specification is silent about
what the proper behavior should be when a single glyph has multiple
LigatureCaretByPos or LigatureCaretByIndex statements. After
this change, we match the behavior of Adobe's `makeotf` tool.
Arguably, `makeotf` might not be optimal in its current behavior,
but it seems better to match the existing toolchain than to have
two conflicting interpretations of an ambiguous spec. Once the
specification gets clarified, we will of course follow.
See https://github.com/adobe-type-tools/afdko/issues/95 for the
spec discussion.
In earlier versions of the OpenType Feature File Format specification,
the example was mal-formed so we had invented our own test case.
Adobe has kindly fixed the format specification:
https://github.com/adobe-type-tools/afdko/issues/88
This change revealed a bug in the parser where mark classes did
not get recognized as glyph classes; this is now fixed, too.
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).
