There now is a Python implementation of variation axes, because this
makes it (much) easier to build variable fonts from code. Therefore,
the definitions in otTables.py are not needed anymore.
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).
Useful for generating XML comments when tables refer to name IDs.
For example, XML for a named instance in an ‘fvar’ table is easier
to read when it says <!-- Bold --> in addition to nameID="258".
Previously, if a subtable's data was shared amongst two different encodings,
the second one being loaded was getting a cmap member assigned while retaining
its data item. If we subset the cmap and then save that subtable, the original
unsubset data will be written out. Fix, but removing data when assigning cmap.
Explains and obviates mystery hack in subsetter.
This reverts commit 72f72d3c3fff3eea38ae41b86a10a78d8460e09d.
This broken subsetting of cmap, as privately reported by Adam to me.
Investigating some more. I think I actually know what's going on.
Followup fix from 13d48da3a91e7ac005f31b0f4dbca01cae7adbd7
When avoiding redoing the same lookup, we should only do that within
each run over all lookups.
Fixes issue where closing glyphs over NotoNastaliq was unreliable and
returning different results (which was caused by items in our frozenset's
being walked over in different orders).
Slows down closing over NotoNastaliq from 5s to 16s. Speedup fixes coming
soon.
I had broken this in e06166b83aa82582dab2e011520b1a77f72aa9f9.
Fix that, and other issues. Since I made that last commit, it has
become clear that SingleSubst works by adding delta and then doing
module 65536.
HarfBuzz was updated for this in 2011:
commit 52ebdff49d13f239efc886de935d47be9860f6e5
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 27 12:38:16 2011 -0400
Fix GSUB lookuptype 1 subtype 1 delta wrapping
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.
