@bedhad
Address issues raised in #1403
I do think setting the dummy CFF2 PrivateDict nominalWidthX and defaultWidthX to None, which leads to the charstring.width also being None, is a good idea. I originally set them to 0, which produces a charstring width of 0, in order to avoid problems with logic that assumes that the field is good for math. However, I now think that it is better to find errors around charstring type assumptions earlier than later.
"drop_hints()" is actually not wrong - I did look at this when making the changes. For CFF2 charstrings, self.width is always equal to self.private.defaultWidthX, so the width is never inserted. This is because in psCharstrings.py::T2WidthExtractor.popallWidth(), the test "evenOdd ^ (len(args) % 2)" is alway False. Left to myself, I would not change this code. If the CFF2 charstring is correct, there is not a problem. if the CFF2 charstring is not correct, then both in drop_hints() and in T2WidthExtractor.popallWidth(), the logic will stack dump. I did add asserts, but am not totally sure it is worth the extra calls.
Added interpolation of glyph advance width, from HVAR/hmtx, and derivation of new LSB.
Updated tests to match.
Needed to cherrypick from another branch an update for psCharstrings to allow the CFFSubr.draw() method to work.
the minimalist STAT table that varLib produces only contains one DesignAxisRecord
for each fvar axis, and has AxisValueCount=0, thus the AxisValueArray offset is None.
So we now round towards +Infinity in:
- floatToFixed (which fully examplify that quotes from OT spec)
- psCharStrings: when packing floats as fixed 16.16
- t2CharStringPen: when rounding coordinates and advance widths
- subset: when rounding advance widths to compute average
- TupleVariation: rounding gvar deltas
- _g_l_y_f: when rounding coordinates: both in GlyphComponent.{x,y}
and for GlyphCoordinates.toInt()
- _h_m_t_x: for rounding horiz/vert metrics
- varLib: rounding horiz metrics and deltas
Instead of memoizing the tuple of <lookup-idx,current-glyphs>, use a mapping of
lookup-idx->current-glyphs instead. Saves some work. Speeds up 5%ish on
NotoNastaliqUrdu-Regular.
It looks like this was (at least partially) implemented in
f01c86ca9b
Should fix https://github.com/fonttools/fonttools/issues/1237
I'm still not sure about that "File a bug." when AdvWidthMap is None,
but either LsbMap or RsbMap are not None..
And we still need to add tests for this though.
