extract the code from fixedToStr into its own function (defined in roundTools), to be used for serializing fractional F2Dot14 angles for COLRv1 PaintRotate 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
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
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.
Apparently Python 2 and Python 3 have different default
print precisions for floats. Or at least with my build it
is the case. As such, for example with amiri-regular.ttf
I see these annoying differences in the ttx output of the
two versions:
77203c77203
< <component ... scale="0.5999755859375" flags="0x1004"/>
---
> <component ... scale="0.599975585938" flags="0x1004"/>
That's just gross. Specially when these numbers are show to
humans, while we know that's just 0.6. The fixedToFloat()
routine in this module is smart enough to do that.
Not used yet.