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.
Using a RoundingPen as a filter doesn't work for TrueType quadratic splines (qCurveTo), because the rounding would occur too early, before these get split into atomic quadratic Bezier segments (by the superclass BasePen.qCurveTo method), thus leaving unwanted floating-point coordinates in the SVG output.
So here we add a 'ntos' parameter (by default simpli calls str()) that takes a Callable[[float], str] and can be used to customize the formatting of the numbers in SVG path coordinates.
* Add default auto doc options
* Ensure all references are unique
* Use anonymous links to avoid duplicate references
* Remove default options, fix wrong module name
* Don’t index repeated class
* Remove repeated classes included through automodule
* Fix warnings
* We don’t use our own static directory
* Correctly format XML in docs
* Fix indentation
* Fix overline
* Bring TOC to top
* Fix definition list
* Offset definition lists and examples
* Fix erroneous markup
* Fix markup
* Already included in automodule
* Fix args markup
* Correct markup for example
* Don’t reindex repeated module
* Correct XML code block markup
* Fix markup errors, change example to doctest
* Correct list markup
* Make ttx docstring both valid RST and valid help output
* Various other boring markup fixes
* Fix example indenting
* Make docstring valid RST and valid help output
* Mock import for reportlab
* It’s ok if manual links don’t appear in toctrees
* Oops typo, I guess doctests are useful
Imported 9b7ecb4 from fontPens, which is the version modified to accept
a parameterized tolerance. Recent changes in fontTools such as 2831096,
186e461 and 7d5530e were considered so that the diff will be minimal.
It is an optional dictionary. Even the ttGlypgPen_test.py or the fontBuilder.py calls TTGlyphPen(None) often.
We caught this because internally we run a type-checker. Originally the glyphSet parameter was not explicitly typed.
Now that it is, make the type hints match the way code is intended to be used.
* 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.
