See https://github.com/fonttools/fonttools/pull/2214#issuecomment-790742479
Good news: this reverted the one CFF test that needed its expectation to
change when I started this patchset. Bad news: it introduced a couple other
diffs to the same glyph of the same test, which is consistent with changing
the rounding from otRound to round3.
Reduces error.
The main varfont-builder now asks the model to do rounding, and asks
VariationStore to do no rounding, so we don't spend extra times rounding
multiple times (specially with the heavy otRound).
I *think* I got it all and right...
Fixes https://github.com/fonttools/fonttools/issues/2213
* Add designspace lib key to specify a custom feature tag for feature variations, as discussed in #2079
* Added comment for the lib key
* if the lib key is present, the 'processing' flag should be ignored completely
* when reading from binary, name.string may be an encoded bytes sequence: we should call toUnicode() before we compare to the requested string
* fix expected output
* Allow feature variations to be active across the entire space
* Add test with empty condition set
* Skip initial box instead of removing it
* Correct comment
Nothing clever, if the source font has a CFF2 table use it as if it were
a CFF table (i.e. non-variable, not sure what would happen in the source
CFF2 was variable already).
The SingleMaster.designspace contains only one source master, so there is no real
variation data.
Still, and empty HVAR table is added (with RegionAxisCount == fvar.AxisCount).
The gvar and cvar table are not added in this case, since they are empty and
not required.
* varLib.cff: Apply conv_to_int() to all the values
* varLib: Don't hardcode file extension to 'ttf'
Also remove unused imports
* varLib.cff: Fix merging of sparse PrivateDict items
Fixes#1651
When building a variable font, varLib.build must make sure that
the OS/2.usWeightClass is equal to the wght axis default location,
that the OS/2.usWidthClass is set to the equivalent value (1-9) of
the wdth axis default location, and finally that post.italicAngle
is set to the same default value as slnt axis.
Sometimes the base master doesn't have these values correctly
set leading to discrepancies between OS/2 and post, on the one
hand, and the fvar axes' default values.
