You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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?
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
The text was updated successfully, but these errors were encountered:
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.
@Lorp said today, responding to @Yure-witch regarding reducing the file size of large design space VFs by iup:
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
The text was updated successfully, but these errors were encountered: