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. :(
Previously, it was always encoding first and last point. Now it only always
encodes last point. Soon resolving that too. Shows another 0.5% savings in
gvar table size with Noto Sans Arabic.
This reverts commit 3e35441c805b03d6d6eea5b24ce44f555c5fad56.
The DP is cleaner to work out front-to-back.
Will achieve the same effect by flipping the lists in a later commit.
Not optimal right now, since first and last point are always included.
Also rather slow. Takes about 12s for NotoSansArabic, and saves just
one percent in gvar size with a tolerance of 0.5 font units.
When varLib was updated for avar table, this was not. Share code such
that they don't get out of sync again. All of this to be made into
proper API some time...
