When the VarStore.optimize() algorithm was improved with the addition of a priority queue where pairs of encodings are sorted by decreasing gain (from merging one into the other), specifically with this commit https://github.com/fonttools/fonttools/commit/47ec18f788, the pre-sorting step of the todo list (before the queue itself was populated) was kept to make sure the algorithm produces stable results no matter the order of the inputs.
The optimizer's output was itself sorted, again for stability, but using a different key function with_sort_key() from the one used on the input todo list gain_sort_key().
The rationale for a distinct gain_sort_key, where encodings get sorted by maximum theoretical gain (decreasing, initally, when reverse=True was set, then incrasing as reverse was somehow dropped), is no longer needed now that a priority queue is used (which sorts by actual gains from merging specific pairs of encodings) and is a remnant of the previous algorithm.
I propose we keep some pre-sorting to ensure stability (in case the priority queue initially contains multiple pairs with the same gain), but we use the same width_sort_key that is used at the end.
Note this doesn't change the overall level of compression achieved by the optimizer, but makes the algorithm a bit less complicated, and easier to match in our alternative Rust implementation.
The "" marker is used when a custom converter expects a list.
For DeltaValues, we expect a list as a single value, not a list
to be enumerated in XML. So, None is appropriate here. Cryptic,
I know...
Fixes https://github.com/fonttools/fonttools/pull/3757
The method that was being used to read the header from the input was
inadvertently dropping the first non-header line on the floor; although
this happens to be okay in some cases (where there is an empty line
after the header) in the case of newer versions of the
ScriptExtensions.txt file, this was causing the generated code to be
missing the first entry, for U+00B7 (MIDDLE DOT)
Fixes#3754
Previously we were appending the entire NEWS.rst to the README.rst to make up the PyPI package description. Now we trim the changelog up to some arbitrary `.. package description limit` and insert a link that points to the full NEWS.rst on Github. I set it to just before 4.0 release which is 5 years ago, about half the total number of lines of the full NEWS.rst, so we should be good for a few years at least.
when getCoordinates is asked to round, e.g. from recalcBounds, only round the simple glyphs' coordinates; don't do any rounding for the coordinates of component glyphs otherwise rounding errors would accummulate if a composite glyph contains transformed/nested components
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
