Fonts typically have multiple consecutive PUSHB / PUSHW
operators. Merge them in the disassembled output.
This, for now, generates worse assmebly because all PUSHB's
grouped with PUSHW's now generate as PUSHW. Followup fix
will address that.
Previously fonttools was choosing between the optimal opcode
from PUSHB, NPUSHB, PUSHW, and NPUSHW. We now respect
whatever was requested and err if the format doesn't support
the data.
Morevoer, if the number of numbers to push is more than 255,
we add multiple push instructions to push all the numbers.
Finally, add a new pseudo-opcode "PUSH" that automatically
chooses the best format.
This, by itself, reduces roundtrip noise by not optimizing
the bytecode as it was before. In a followup commit I'll
change the bytecode disassembler to always produce PUSH
in the textual instructions instead of the four variants.
That way, we get both the optimization during assembling,
and reduced noise in XML.
Part of https://github.com/behdad/fonttools/issues/73
The format values for those are automatically handled in
postRead/preWrite to choose optimal format. As such, don't write them
in XML. Reduces noise.
Part of https://github.com/behdad/fonttools/issues/73
Lazy loading has implications on how people use objects.
So, by default, don't load lazily. This only affects
GSUB/GDEF/GPOS/etc and is closer to what fonttools used
to do traditionally.
Turn lazy loading on in subset and inspect.
This has been broken since f2c2b4d38bd7bba23db71936262db984e4b7aebb,
assigning a new object to a function argument will not change the
original one, so we need to return the modified list.
There was an inconsistency: when allowVID was False, we were allowing
gid->glyphXXX, but not the reverse. This was allowing some fonts to
be loaded, but then not to be written back. Fix that.
The latter hits the __eq__ method and can fail because we now
do not allow comparing objects of different types.
For example, was failing subsetting Andika-R.ttf.
