The code that is being removed is untested and does not seem to make
fixing an overflow any easier. The fixer code just needs to know
which subtable caused the overflow and does not care about the item
within. As such, no point in trying to find a "right" item.
In fact, leaving item as is, is more useful in debugging overflows
as it reflects which item's offset actually overflowed.
Part of fixing https://github.com/behdad/fonttools/issues/537
According to the spec:
> The lookupflag attribute defaults to 0 at the start of a feature
> block.
>
> The lookupflag attribute stays the same until explicitly changed, until
> a lookup reference statement is encountered that changes it, until the
> script is changed, or until the end of the feature.
This is an attempt to fix this by resetting the lookupflag at the start
and end of feature/lookup blacks. I’m not sure if resetting it in lookup
blocks is correct (my reading of the spec suggests it is not), but one
needs to test this against makeotf and see how it behaves here.
otherwise `not NotImplemented` (always False) is returned from __ne__ when `type(self) != type(other)`, leading to illogic results like:
>>> from fontTools.ttLib.tables.DefaultTable import DefaultTable
>>> t = DefaultTable('test')
>>> t == 0
False
>>> t != 0
False
The latter of course should return True.
previously assertEqual would fail, despite the `program` attributes where both empty, as the object have different id(). The Program.__eq__ method now compares self.__dict__ == other.__dict__, hence the test pass.
Unlike simple glyphs (with contours) which must always have `instructionLength`, the field is optional in composite glyphs and depends on whether `WE_HAVE_INSTR` flag is set:
https://www.microsoft.com/typography/otspec/glyf.htm
In the previous code, the TTGlyphPen was adding an empty `program` attribute to any new glyph, including composite glyphs. It should only do it for simple glyphs.
For example, if you take Roboto-Regular.ttf from here:
https://github.com/google/roboto/releases/tag/v2.129
The font (unhinted) was compiled using the ttGlyphPen. It has 1434 composite glyphs. For each of them, a USHORT value for the number of instructions (0) is written, so the binary ttf is 2.868 KB greater than
what it should be.
Apparently string slices are not as smart as I was hoping for.
Slicing a looong (say, 1MB) string and holding onto it is not a
good idea if done thousands of times. So, do fewer slicings and
decompile subtables immediately instead of holding onto data.
This makes me want to rethink the kind of data structures we use
for lazy processing.
Fixes https://github.com/behdad/fonttools/issues/317
In the long term, we might want to make a different low-level API
for building ChainContextPos lookups; for now, this should fix the
current bug with SequenceIndex.
Resolves https://github.com/behdad/fonttools/issues/517.
