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.
when ttx fails to decompile a buggy glyf table, the DefaultTable implementation is used,
but TTFont._tableToXML passes 'splitGlyphs' keyword argument to table.toXML when
the tag is 'glyf'.
Let's simply ignore it here.
* Implement glyf outline flags bit 6 when decompiling/compiling
* Add test data for outline flag bit 6
* Rename flags, use bitwise OR for setting flag bit
* Remove unneeded code
If offset overflow happens other than between Lookup and SubTable, or
within SubTable, then we don't know how to fix it currently. Now we
try to put that lookup in an Extension lookup anyway, since that will
isolate it and sharing with other lookups won't happen, hopefully
avoiding the overflow.
This is really a bandaid... What we want is the 99proof branch to
be finished and replace our current packing algorithm.
Fixes https://github.com/fonttools/fonttools/issues/1296
So we now round towards +Infinity in:
- floatToFixed (which fully examplify that quotes from OT spec)
- psCharStrings: when packing floats as fixed 16.16
- t2CharStringPen: when rounding coordinates and advance widths
- subset: when rounding advance widths to compute average
- TupleVariation: rounding gvar deltas
- _g_l_y_f: when rounding coordinates: both in GlyphComponent.{x,y}
and for GlyphCoordinates.toInt()
- _h_m_t_x: for rounding horiz/vert metrics
- varLib: rounding horiz metrics and deltas
in _checkFloat (used whenever we're about to update the inner array) we check whether the value exceeds a short integer, and if so we convert the array to floats.
Also, we make sure we call __setitem__ (which in turn calls _checkFloat) instead of updating the inner array directly in the rest of the math methods.
When an offset refers to a table, we keep the size of the offset to
the referred-to table. When sharing tables, we were ignoring this,
which could result in a long offset being written out as a short, or
vice versa. Fix it by not sharing such tables. This is not optimal
but fixes the bug.
Bug has been there forever.
