Make the output of otlLib.buildLigatureSubst() deterministic.
Before this change, otlLib ligatures were emitted in a non-deterministic
sorting order (depending on what hash value Python would give
to a string tuple).
After b4919b6c0a5ea0ca6747fe7699554e8a14d1f77f, the tests were
named correctly but they always used the exact same feature file,
irrespective of what file they were supposed to test.
Resolves https://github.com/behdad/fonttools/issues/465
Contains the sketch and start of a stateless GSUB/GPOS/GDEF builder.
Will be used by mtiLib, feaLib, and the future voltLib. Can also
be used by clients to build these tables with much less pain.
Before, equivalent types, eg. otTables.BacktrackCoverage, etc,
where a subclass of their equivalent parent type, eg. otTables.Coverage
With this change, they are the same type.
The otBase and otConverters changes were needed to make the above
happen and still generate correct XML for SubTable type.
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
Python's stdlib
The 'xml.parsers.expat' module has been a part of Python's Standard Library since version 2.0. Link: https://docs.python.org/2/library/pyexpat.html#module-xml.parsers.expat . FontTools requires Python 2.7, or Python 3.3 or later. Checking for the existence of this module is not necessary anymore.
The code for building GDEF tables had grown quite a bit, so it was
hard to understand what was going on. After this change, each GDEF
subtable gets built by a separate method. This increases legibility.
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).
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.
