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.
After this change, MacOS Yosemite 10.3.3 renders the Oslash glyph
of Skia.ttf with the exact same outline before and after round-tripping
the font through TTX. Before this change, the outlines were slightly
different after round-tripping through TTX.
In my initial reading of the “gvar” specification, I had assumed
that (0,0) entries had no significance. However, that is not
how the current MacOS implementation interprets it.
Before this change, a rounding issue in fixedToFloat() would sometimes
change 'gvar' coordinate values when round-tripping Skia.ttf through TTX.
This change works around https://github.com/behdad/fonttools/issues/286.
When compiling the set of shared coordinates, walk over glyphs in
self.variations instead of retrieving them in glyph order.
This addresses a code review comment:
0f86c1c0d3 (commitcomment-11375190)
In Pyton 3, range() is implemented like xrange() in Python 2,
and there is no xrange() anymore. The savings from xrange() are
too small for us to really bother, so we choose to live inefficiently
on Python 2.
With this work-around, all of {Skia, BuffaloGalRegular, JamRegular}.ttf
can be round-tripped through TTX, and the resulting TrueType font
can be displayed by MacOS X 10.9.5 including glyph variations.
In the Apple Skia font, about 5% of all tuples are redundant
because all their delta offsets are (0, 0); these tuples can
be omitted without any visual loss. But in the BuffaloGalRegular
and JamRegular fonts, there are no such redundant tuples.
