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.
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.
