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.
Using built-in types (mostly tuples) seems to cut the running time
overall by about one half. Spelling out linear interpolation in the
bezier_at functions actually cuts the running time by another 10%,
but I'm not sure if it's worth it given that this code looks a bit
nicer.
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.
I like this new order better, since max_err seems to be the more
important parameter, and it corresponds more closely with the actual
font object params (which can be lists) than max_n (which is always
a single value).
This should be more compatible between fonts with different UPM. In
fact, it should work within a single call with such fonts.
The default max error is now 0.0025 em, which is about 5 units for a
2048 UPM font.
