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.
We need to ensureDecompiled() whenever an object is modified
before we look up any member of it.
Note that normally objects remaining decompiled until we try
to write them out is fine, except for when they depend on
font.getGlyphOrder(). This however, shouldn't normally happen
since if there's an object depending on the glyph list (eg. a
Coverage table), it should already have been process to subset
it according to the requested glyphs. Or that's the idea at
least. The few cases that were not handled are handled
explicitly now.
This was showing a bug when subsetting Cabin for example.
