Skip to content
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

IUP ui #1624

Open
davelab6 opened this issue Aug 29, 2024 · 2 comments
Open

IUP ui #1624

davelab6 opened this issue Aug 29, 2024 · 2 comments

Comments

@davelab6
Copy link
Member

@Lorp said today, responding to @Yure-witch regarding reducing the file size of large design space VFs by iup:

tweaking tolerance values for IUP/gvar optimisation? We're experimenting with changing this on a gf project and seeing incredibly good file size savings (given the font is 90% gvar, shrinking it makes a massive difference). What sort of error are we introducing by adjusting it: is it just tolerance ~= max font unit diffs, or could it have outsized impacts thanks to off-curve points?

Citing source code, you can see the value being used here: https://github.com/fonttools/fonttools/blob/770917d89e9151023cce011c7f7223f4ce84169e/Lib/fontTools/varLib/__init__.py#L355-L357 It defaults to 0.5 and there's no user API to change it currently, which we'd maybe look into adding if this was a good solution

IMO the only reliable way would be to get font designers to design with gvar-IUP in mind. After creating a Regular, they would move only key points (as in hinting) to create additional masters, and the source would have knowledge of IUP vs manual points. Very often, IUP-interpolated curve point locations will be fine. I’d love to see designers rewarded for low byte counts, for example by displaying compiled byte count of the current glyph+gvar. Going back to your question, theoretically one could tag points in the source with "don’t IUP me", but that won’t help IUP-optimize binary fonts, and would probably be clunkier as a workflow than getting designers to redesign the glyph+gvar.

This suggests that the byte count of the current glyph could be known and shown in fontra, and the results of the iup'izer also showing which points are being subject to deltas vs iup'd

@Yure-witch
Copy link

Let me know if I should pass this information along to the rest of the emoji team! I'm grateful to be in the pipeline about this but I don't directly deal with drawing the emoji font, though I imagine this is pretty critical information for Noto Emoji and potentially Noto Color as well. Noto Emoji is a variable font, so it may be worth it to surface this information.

@justvanrossum
Copy link
Collaborator

This would be a good idea for a plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@davelab6 @justvanrossum @Yure-witch and others