like cmap, or glyf or OTL tables, we need to respect lazy=False flag and decompile everything upfront, also we want to add an ensureDecompiled method (called by TTFont.ensureDecompiled) to allow loading everything in one go even when a font had been opened lazily.
* Replaced all from ...py23 import * with explicit name imports, or removed completely when possible.
* Replaced tounicode() with tostr()
* Changed all BytesIO ans StringIO imports to from io import ..., replaced all UnicodeIO with StringIO.
* Replaced all unichr() with chr()
* Misc minor tweaks and fixes
In the OpenType 1.8 specification, this is called TupleVariation
so let's be consistent with the spec. (The initial implementation
in fonttools pre-dates OpenType 1.8).
Where more than one run is used, it's only the first run's first point
that is absolute, all other values are relative.
Similar fix landing in FreeType soon. Fixes lizzard glyph (glyphname
"dollar") in Zycon.
In the previous table-driven implementation, client code had to
know the internals of the ‘fvar’ structure for correctly adding
variation axes to a font. In the new implementation, clients
do not have to futz around with binary offsets (which makes it
more likely that tools build correct fonts).
After this change, round-tripping through TTX shrinks the size of all
our test fonts. Specifically, Skia.ttf shrinks from 478K to 473K,
JamRegular.ttf from 113K to 107K, and BuffaloGalRegular from 67K to 61K.
This make the code easier to understand, especially since there
is a diffence between numPointsInGlyph, numPointsInRun and
numPointsInData.
Also, we now pass numPointsInGlyph to compilePoints() to later
enable an optimization where numPointsInData == numPointsInGlyph.
However, this change does not yet make that optimization.
Before this change, the compilePoints() routine would wrongly clear
the most-significant bit of the lower byte in its binary output.
An example glyph affected by this bug was “perthousand.oldstyle” in
the version of Skia.ttf that Apple ships with MacOS X Yosemite 10.10.3.
Although the broken code path was exercised in the unit tests, the
length of the test input just happened to have the affected bit clear,
which is why this bug did not get caught by the previous test cases.
