font sources only allow to specify advances, the sidebearings are computed. Makes more sense for the sparse metrics to have 0 for the sidebearings as the glyph that's meant to be 'sparse' is most likely empty with no outlines
For the test, I used the Tests/varLib/data/Build.designspace as starting point, modified the 'a' glyph so that 1 on-curve point (the first one) becomes impliable for all the masters.
There is no longer a requirement that all the masters have exactly the same base color glyphs as the default masters. Similarly, it's no longer required that all masters' LayerLists have the same total count of layers. It is sufficient that, for a base color glyph in the default master, a non-default master may (or may not) contain one with the same name and same effective number of layers (which in turn can be laid out differently in the respective LayerLists).
This provides greater flexibility when working with variable font project with sparse glyph sets.
When multiple variable tables refer to the same delta-sets they can now share the same VarIndexBase so the resulting DeltaSetIndexMap is a bit smaller.
For simplicity, we only reuse VarIndexBase when variable tables fully share (ie. same, and same number of) varIdxes; potentially we could reuse subsets of varIdxes (e.g. a VarColoStop.Alpha has a +0.5 delta, and later on elsewhere a PaintVarSolid.Alpha has a similar +0.5 delta; the latter could have a VarIndexBase that reuses an existing DeltaSetIndexMap entry for the former), but for now this I think is good enough.
When building gvar, some situations cause fontmake/varLib to fail, for example if a component has a coordinate that's >32k or <-32k. This adds a debug line that prints each glyph name for which gvar is built, so it’s easier to pinpoint where the faulty glyph is.
I suggested Cosimo add that code in
https://github.com/fonttools/fonttools/pull/1528
Upon further inspection now, that code is unnecessary and even wrong in
cases where different masters have different ascent, because that would
result in encoding variations for vertical phantom points, which will
be then either be unused or double-apply on top of ascent etc.
* 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
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
