However, not sure how to build the otTables object graph for emitting
GPOS tables with device values; the current code thus silently strips
off any device values. Left a TODO comment for implementing this.
Before this change, feaLib would sort coverage tables by glyph name,
which is against the OpenType specification. The current unittests
happen to use only glyphs where the ordering is identical whether
sorting by name or by ID; but I am about to add unittests (for GPOS)
where the ordering is different.
The ordering cannot be enforced by otTables because otTables does
not have access to the font's glyph order; therefore, the sorting
needs to happen inside feaLib.
Add support for subsetting COLR table.
The CPAL table does not need subsetting, but unused palettes should be
pruned, this is not implemented however as it depends on COLR table,
which in turn will not be updated after pruning CPAL.
When one does `from fontTools.misc.py23 import *`, everything seems to work fine.
However, linters will complain when one uses the asterisk to import all names from a module, since they can't detect when names are left undefined -- asterisks are greedy and will eat all names.
If one avoids the asterik and attempts to import explicitly, like in `from fontTools.misc.py23 import basestring`, the problem then is that, if `py23` does not re-define the name -- e.g. under python2 `basestring` or `unicode` are built-ins -- then the import statement raises `ImportError`.
The same happens for the `unichr` function on a "wide" Python 2 build (in which `sys.maxunicode == 0x10FFFF`).
Now, to work around this, we need to re-assign those built-ins to their very same names. This may look silly, but at least it works.
in version 0.6.4 (installed on OS X 10.10 python lib/extras) it raises
KeyError, whereas in the latest version available fom PyPI (v0.7.8) it
raises IOError.
Fixes issue in https://github.com/googlei18n/nototools/issues/113
the third (2015) edition of ISO/IEC 14496-22 "Open Font Format" increased
the limit from 32767 to 65535 (and thus eliminated the reserved numbers).
`array.array` will take care of raising the right `OverflowError` exception
so we don't need any further checking.
Using BasePen breaks on quadratic splines, since there's no way to
know if a on-curve point was added by the pen or in the original
glyph. Should have considered this before....
Generated by running example 1 from the Feature File specification
section 5.f.i (Specifying a Chain Sub rule and marking sub-runs)
through AFDKO's makeotf tool, and then decompiling the resulting
GSUB table with ttx.
The actual test is commented out because the current version of feaLib
is not able to produce this output yet; marked with a TODO comment.
It is example 1 in section 5.f.i of the specification, and there
more examples in the same section. For consistency, use the same convention
as the other test cases.
