This is a regression introduced with https://github.com/fonttools/fonttools/pull/3750
The test currently fails because we are now applying rounding to the
coordinates extracted from each component of a composite glyph, *before*
these are transformed; with nested components of components with non trivial transforms, the rounding errors compound leading to incorrect bounds.
the test makes sure that the bounding box of composite glyph with non trivial transform pointing to base glyphs with un-rounded floating-point coordinates, still get their bounding box computed on the rounded-off integer coordinates.
see https://github.com/googlefonts/fontc/issues/1206
- only differentiate between glyf and CFF/CFF2 implementations, not var vs non-var
- use collections.abc.Mapping to get a more consistent dict-like object with less code
- prefer HVAR metrics over gvar metrics
- move some responsibilities from the _TTGlyphSet objects to the _TTGlyph objects
- adjust some tests to the changes
* Add TTGlyphPointPen
* Format code with black
* Implement TTGlyphPen and TTGlyphPointPen with common base class
* Use PenError instead of assert
* Add note about decomposing mixed composites to the docstring
Fixes https://github.com/googlefonts/fontmake/issues/558
When drawing a composite glyph with a scaled component using the TTGlyphPen, the bounding
box coordinates may change depending on whether one computes them *before* compiling or
*after* decompiling. Before compiling, component.transform holds double precision floats,
but after compiling and decompiling, these are necessarily clamped to F2Dot14 fixed precision.
The TTGlyphPen needs to quantize transform floats to F2Dot14 so that the values don't
change after compilation.
Without this change, it may happen that round-tripping fonts through ttx (which by default
recalcBBoxes) will produce different bounding boxes for composite glyphs that have
scaled or transformed components.
