- 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
The pen is designed to determine the bitmap size when omitted, which
helps users to see an image somehow even when they have no idea how the
arguments should be passed. And I realised that I didn't give enough
thought to rotate/skew transforms in former PRs. This commit fixes the
calculation of the bbox after transformation. Also tries to clear up how
the autosizing options work in the docstring.
Some minor fixes will follow.
Surprisingly I found Preview.app can still display PGM images. While
somewhat legacy, it's a super straightforward format to (de)serialize.
The images are scaled to 50x50 px and only consume 5KB in total. Makes
more sense to human being than the previous base64-encoded zlib
compressed data, plus we don't have to add pillow as a dependency.
Eliminates the assumption of any specific metrics from the pen. It still
gives some image without giving any parameters, thus it should be a good
starting point for new users.
There are possibilities that the rendering results may change among
FreeType versions. I've already used the PSNR comparison for cubic
vs quadratic testing, so I applied the same technique and threshold to
all rendering tests to relax assertions. Also handles the case that
MSE becomes zero. Optional dependencies are not needed for the tests.
After experimenting with uharfbuzz for a while, I found out it was hard
to handle top-to-bottom texts, so I gave up an idea to put an ascender
or a descender value in the arguments. Instead, I simply expose 'offset',
'width' and 'height', which is way more straightforward than the
previous design.
In addition, 'contain' option is added to easily compensate and render
glyphs such as combining accents or excessively tall letters.
* 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
* 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
* Add HashPointPen from psautohint (with changes)
* Decompose components
* Use format string and disambiguate critical changes
* Remove "getHash()" in favour of "hash" property
* Add transformation for composites
* Omit base glyph name from component hash
* Use untransformed coords for components
* Add tests
* Add example code
Co-authored-by: Cosimo Lupo <cosimo@anthrotype.com>
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.
The PointToSegmentPen translates between PointPen and (Segment)Pen
protocol.
In the SegmentPen protocol, closed contours always imply a final 'lineTo'
segment from the last oncurve point to the starting point.
So the PointToSegmentPen omits the final 'lineTo' segment for closed
contours -- unless the option 'outputImpliedClosingLine' is True
(it is False by default, and defcon.Glyph.draw method initializes the
converter pen without this option).
However, if the last oncurve point is on a "line" segment and has same
coordinates as the starting point of a closed contour, the converter pen must
always output the closing 'lineTo' explicitly (regardless of the value of the
'outputImpliedClosingLine' option) in order to disambiguate this case from
the implied closing 'lineTo'.
If it doesn't do that, a duplicate 'line' point at the end of a closed
contour gets lost in the conversion.
See https://github.com/googlefonts/fontmake/issues/572.
