Right now just reflects the axes, and even that with certain limitations:
- AxisOrdering is set to the order axes are defined,
- Name-table entries are not shared with fvar.
Towards https://github.com/LettError/designSpaceDocument/issues/8
We don't need to cast to int when using the round function from py23,
as this is a backport of python3's built-in round and thus it returns
an int when called with a single argument.
Instead of raising AssertionError when users define custom axes
without explicit `<labelname xml:lang="en">ZZZZ</labelname>` element,
it's better to use the axis' name attribute, and treat it as "en"
language.
For example, if users generate the designspace from SuperPolator,
they can't edit the axis labelname attribute from the UI (or maybe
it's just me that couldn't figure out how to do it).
This is a follow-up to Jens' comment:
19c4b377b8 (commitcomment-23458151)
Now, if there's any axis that has 'interesting' segment maps (and thus
an avar table is added), we also ensure that for the rest of the axes
that aren't modified (either because no <map> elements are defined or
because an identity mapping is defined in the designspace), we always
have a non-empty segment maps array containing the three default maps:
{-1.0: -1.0, 0.0: 0.0, 1.0: 1.0}.
This is to work around CoreText and DirectWrite rendering issue with
empty avar segment maps arrays.
* Initialize the avar segment map with required default entries
* Set default values only after deciding that a segment map is needed for this axis
* Correct dict update call
Pass a maximum lookback of n to the circle-breaking DP of size 2*n.
This should theoretically speed up that DP by a factor of 4 or 8 or something...
Empirically it's far from that, but solidly measurable.
Again, gvar table size got a slight improvement, which I didn't expect... It
might be that my one test is hitting lucky cases with point encodings.. or it
might be just me wishfully thinking so.
Drives it into acceptable speed now. Note that I'm getting better
gvar size after this patch, which I didn't expect. So, either this
algorithm or the previous one was buggy. :(
