-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More efficient cmap compilation #1228
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good but I found some of the code hard to follow. I sent suggestions for simplifications. I'm not tied ot the specific simplifications I proposed but I would like to look again once it's been altered to be a bit easier to follow so marking as Request changes.
[write] Redo cmap f4 segment computation The earlier version didn't account for wanting to be able to recombine segments later, if it's more efficient.
This generates a more efficient cmap 4 subtable by more efficiently choosing segment divisions, and using the glyph_id_array for segments with non-uniform id deltas.
Fixed a couple logic errors uncovered by trying this out on a few real-world fonts.
...hopefully. This also addresses one small case where we would not correctly merge segments.
@rsheeter cleaned and reorganized this a bunch, hopefully the logic is much clearer now? ptal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM subject to remaining comments being addressed
There was one case where fonttools was saving several bytes on us, which felt bad. We are now equal or better, for every font I've examined.
This produces significantly smaller cmap tables by combining segments where possible, and taking advantage of of the
offset_range_id
array to store glyphids directly where this is beneficial.This fixes the issue where our cmap tables were often significantly larger than the ones produced by the python toolchain.
I believe there may be one further optimization possible here, which i am curious to explore but am holding back because I think the size savings are negligible: but I believe it is theoretically possible to reuse glyph ids in the
glyphIDArray
, if two segments have glyphs identical spacing patterns, due to the fact that the idDelta is still applied even if the glyphidarray is used.