Since we now use setuptools to create platform-specific console scripts,
(including *.exe for Windows) we no longer need Win-only instructions nor
extra files.
Thanks @twardoch for his contribution.
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.
