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
This isn't a real PR. I wound up needing to convert a CFF-based SVG font to COLRv1 and these were the various hacks I used to build it with nanoemoji. I'm just sharing this in case it may come in handy. Some of the changes would work as-is but some just overwrite the glyf path (especially in glue_together) because I was just trying to get something done.
I don't know what's going on with the ascender_override stuff. The extractor was writing in 750 where what was needed was -250. I don't know if that's a CFF-specific thing, something to do with the encoding of the SVGs in the font, or something else.
I also had to deal with some out of bounds gradients. Could be a problem with the source data, not sure.
The underlying problem here, and most likely the reason CFF wasn't supported all the way through in the first place, is the brittleness and decentralization of the fontTools cffLib structures. This is in stark contrast to how the same structures are represented in ttx XML. It would be nice if there were an edit-oriented model one could switch between, possibly based on the XML hierarchy.
most likely the reason CFF wasn't supported all the way through in the first place
IIRC this is because maximum_color was pretty much written specifically for Noto Color Emoji and that doesn't ship in cff form. nanoemoji cff output should work fine afaik?
This may well just be my ignorance about the stack, but it wasn't obvious to me how to use nanoemoji directly when starting from a finished font. I didn't see an equivalent of the code in glue_together, for example.
My goal was to convert an SVG font to COLRv1, which is something I can imagine a number of other people wanting to do, and this seems to be the repo that gets you closest. But if what you're saying is that that workflow isn't really a goal, and maximum_color was just thrown in for incidental reasons, then that's fine.
that's exactly what maximum_color is for! Thanks for the PR, I'll take a look soon
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This isn't a real PR. I wound up needing to convert a CFF-based SVG font to COLRv1 and these were the various hacks I used to build it with nanoemoji. I'm just sharing this in case it may come in handy. Some of the changes would work as-is but some just overwrite the glyf path (especially in glue_together) because I was just trying to get something done.
I don't know what's going on with the ascender_override stuff. The extractor was writing in 750 where what was needed was -250. I don't know if that's a CFF-specific thing, something to do with the encoding of the SVGs in the font, or something else.
I also had to deal with some out of bounds gradients. Could be a problem with the source data, not sure.
The underlying problem here, and most likely the reason CFF wasn't supported all the way through in the first place, is the brittleness and decentralization of the fontTools cffLib structures. This is in stark contrast to how the same structures are represented in
ttxXML. It would be nice if there were an edit-oriented model one could switch between, possibly based on the XML hierarchy.