Apparently the SIL Gentium fonts have wrong sorting in Coverage
tables. That's broken by the spec, but shapers still work with
such fonts. So, we warn when reading, and when writing, such
out-of-order coverage tables.
New instructions can be defined in the prep program. We don't
check that the "unknown" instruction was actually defined. Just
pass it through.
Fixes ttx with Skia.ttf on the Mac OS X.
Fixes https://github.com/behdad/fonttools/issues/21
Our footprint in the Python module namespace is all under
fontTools now. User code importing sstruct should be updated
to say "from fontTools.misc import sstruct".
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.
1. Write out using utf-8 encoding. Shouldn't matter really since
we don't generate non-ASCII data,
2. When parsing, DON'T override the file's encoding!
