The items() of self.markFilterSets_ dictionary are not guaranteed to be always
ordered the same (may vary across python implementations or on subsequent runs).
To ensure deterministic order of Coverage subtables in MarkGlyphSetsDef tables,
we sort the mark sets by the order in which 'UseMarkFilteringSet' statements appear
in the feature file.
Glyph classes from feaLib parser are tuples of strings, with an order and possibly containing duplicates.
However when building MarkGlyphSetsDef or MarkAttachClassDef we are only interested in the *set* of glyphs they contain, i.e. the unordered collection of unique glyph names.
Also, note how in the tests for otlLib.builder.buildMarkGlyphSetsDef, the input is given as set literals, not tuples:
https://github.com/fonttools/fonttools/blob/78ad48e/Tests/otlLib/builder_test.py#L633
If a zero value appears in a SinglePos statement, feaLib continues to
produce ValueRecords of format 0. But if a zero value appears in a
PairPos statement inside a horizontal compilation context, feaLib now
produces ValueRecords of format 4. Likewise, if a zero value appears
in a PairPos statement inside a vertical compilation context, feaLib
now produces ValueRecords of format 8.
The OpenType Feature Syntax specification is completely silent about this,
but the new behavior matches that of makeotf.
https://github.com/fonttools/fonttools/issues/633
Also fixes a bug where glyph alternates in MTI feature files were
wrongly sorted by glyph name. After this change, the output is using
the same ordering as in the input MTI feature file.
Fixes https://github.com/fonttools/fonttools/issues/833.
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.
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.
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.
