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.
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.
This reverts commit e4a670cc7da93d3a12ba23d8cfefdeb0ec7be01f.
As Read Roberts wrote to me:
"you changed the definition of the GlyphOrder class to take a ttFont as
the argument for the __init__ function, rather than just the
tag, as before, I think so that the glyph order is defined when the
table is instantiated, rather than only when to/fromXML() is called
The problem with this is that the ttx.py compile function passes in a tag,
so compiling a font from an ttx file fails here, and in
xmlImport.startElementHandler(). I discovered this because a number of my
scripts use the same logic. What is the reason for this change? I have no
problem with changing the several FDK scripts that build a new TTF font
from scratch, to pass in the ttFont rather than a tag, but wanted to be
sure that this was necessary. The main issues are that when reading in an
entire TTX file, the table has to be instantiated before the data can be
provided, and the GylphOrder initialization is then different than for
all the other tables"""
As such revert. This means that GlyphOrder is again non-iterable. Will
have to fix in some other way later.
For example trying to run fontTools on Jython or PyPy fails
because they don't have a numpy module. However, the error
is caught by the getTableModule() and instead DefaultTable
used for tables that use numpy in their implementation. Fix
that.
