-
Notifications
You must be signed in to change notification settings - Fork 8
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
[COLRv2] Proposal: Reusing layers with the "self GID" #370
Comments
Do you think you could support this within fontpainter's own implementation, such that you can demo a pair of TTFs that show the file size goes down, and the "after" TTF only works in fontpainter? |
It‘s a great reduction. However using an identical glyph shape repeatedly for each glyph is not a common case. I’d like to see an estimate based on 3 different-shaped layers, which still feels like "doing basically the same thing with all glyphs". |
I'm not convinced this is worth pursuing. The sharing happens only if the same paint is also used... |
Okay maybe it is useful, for font-wide effects... |
Maybe a demonstration with three layers was confusing the issue. Consider the very simple use case of a font which just applies a gradient to each glyph. I can imagine that becoming a very common practice. Currently that requires one paint per glyph; with this it would require one paint. |
Using GlyphID16 65535 for this works, since that glyph is inaccessible in current font technology. (max glyphid is 65534, because maxp.numGlyphs can at most be 65535). |
since a change in the semantics of GlyphID would require a COLRv2 anyway, we might as well bundle that up with 32-bit GlyphIDs which are "in the air"... |
Yes, GlyphID24 paints are needed when we get beyond64k... Maybe you're right. |
Alternatively it can be a separate PaintSelf with no data. |
Implements extended version of: googlefonts/colr-gradients-spec#370
Implements extended version of: googlefonts/colr-gradients-spec#370
I implemented this in FontTools. See fonttools/fonttools#3244 (comment) |
Implements extended version of: googlefonts/colr-gradients-spec#370
Implements extended version of: googlefonts/colr-gradients-spec#370
Implements extended version of: googlefonts/colr-gradients-spec#370
Implements extended version of: googlefonts/colr-gradients-spec#370
Where can I get this? |
in the fonttools PR you added something called |
is it somehow to increase the chances of reusing a paint subtree? not sure how exactly but. |
Generally a colour font is made up of "layers" in the font editor which get composed to separate glyphs in the binary. Suppose you have the construction |
There is a common misconception that these source "layers" remain intact in the binary font, as if color IDs in a palette are layer IDs. If this were true, "layers" could reliably be separated later, which is not the case. Templates would allow layers actually to survive, grouped by the glyphs that share a layer structure. |
The font I was experimenting with is a shadow font and has this glyph order:
Ie. every glyph has two layers, and the glyph ids are predictable. It did indeed cause a lot of reusing. Just check number of layers:
|
I tried my tool but it failed to do what you expected, because all layers have different
How did you build this font? The VarStore looks unoptimized and not even built with |
To paint glyph 0 with the first palette color, you currently do this:
But doing basically the same thing with all glyphs in a font is quite a common use case. In COLRv1, to further paint glyphs 1, 2, 3...n with the first palette color, you need to do:
(Modify for more complicated paint trees as appropriate.)
Effectively the same paint, differing only in the GID of the glyph that gets painted, and more to the point, this GID is known in parent the BaseGlyphPaintRecord.
fontpainter is a COLR editor which, internally, uses an abstraction called
SELF_GID
. The paints above would be represented internally as:which of course allows you to reuse layers:
When the font is written to binary, any
SELF_GID
in a paint tree is replaced by thegid
of the current BaseGlyphPaintRecord. On the OpenType side, this currently requires instantiatingn
individual paint trees to do effectively the same thing.If the font format itself supported a magic number as a parameter to
glyphID
with the semantics of "gid
of the current BaseGlyphPaintRecord", this could dramatically reduce the size of COLR tables in fonts where each glyph is painted in a substantially similar way.The text was updated successfully, but these errors were encountered: