Also, the TTFont.getGlyphOrder() automatically makes up a dummy
glyph order from the maxp.numGlyphs, we simply need to ensure
'maxp' is decompiled before 'glyf'.
When transforming glyf, the glyf.glyphOrder is guaranteed to
be present (as the glyf table has been already decompiled), so
we don't need to deal with it being missing or incorrect
(hence removed spurious tests).
Unlike simple glyphs, which always have 'program' attribute (even when empty, with no instructions)
in composite glyphs, it's the presence of 'program' attribute that determines whether
the optional WE_HAVE_INSTRUCTIONS component flag is set or not.
Thus, the trim method (with remove_hinting=True) should delete the attribute for
composite glyphs.
Fixes https://github.com/fonttools/fonttools/issues/1550
otherwise one gets AttributeError: 'module' object has no attribute 'block'
I noticed this by change. The whole SIL lz4-compressed Glif/Silf tables is still untested...
so that's comparable/hashable/immutable and can be used as key in a dict or set.
The fromXML instance method was dropped since it relied on the object being mutable.
A fromHex classmethod replaces it.
when no horizontal/vertical header table is present, we assume numberOfHMetrics == maxp.numGlyphs.
This allows to compile/decompile incomplete fonts, only containing head, maxp, hmtx, loca and glyf (or CFF),
that is the bare minimum to temporarily store glyph outline and metrics data for use with sparse/intermediate
master TTFs in varLib.
See https://github.com/googlei18n/ufo2ft/issues/308
* cleanup cmap format 14 TTX format by removing redundant attributes
* don't output the name attr for a default mapping, instead of a glyph named 'None'
* still accept 'None' as an indicator glyph name, for bw compatibility
* swap order of TTX attrs uv and uvs
* make sure (unicode, glyphName) pairs are always tuples in uvsDict.
on py27, calling deepcopy on a file object doesn't raise TypeError, but leaves
the duplicated file object in an inconsistent state:
https://travis-ci.org/fonttools/fonttools/jobs/474811063#L714
any operations on it will fail with 'ValueError: I/O operation on uninitialized object'.
Thus, for semplicity for now we always do a manual copy the file contents into an
in-memory BytesIO stream, rather than attempting to call deepcopy first.
