* a charstring is not guaranteed to end in an operator, so the final bytecodes 11 and 14 can be part of an encoded numeric value; so remove 'return' or 'endchar' at the program level instead of bytescode
* move non-CFF2 test+error to elif clause of earlier isCFF2 test
Fixes the remaining issue from #1451
The parser was still trying to read the next token even when the current
token was END, but I think it should just stop reading here. When
reading from TSIV table there can be null bytes at the end when would
cause an exception in the lexer.
When checking for duplicate anchors, the component number should be
taken into account since the same anchors can be used for different
components i.e. over ligatures.
in a designspace document, the sources' filename attribute can now contain
a relative path to a .TTX file for that master, in addition to .TTF or .UFO
(the latter, resolved through a master_finder callable as before).
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
now that addMultilingualName method also adds mac names by default, we can use it in
varLib instead of addName.
The language identifiers are expected to be minimized, i.e. not contain default script/region
subtags -- until we implement the minimizeSubtags algorithm from ICU/CLDR:
https://github.com/fonttools/fonttools/issues/930
* 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.
