Closed Findus23 closed 1 year ago
thanks for trying out our tools! I think maximum_color is assuming that the input font already contains a "glyf" table, but in your case it only has the "SVG " table, is that correct? I believe an OT-SVG font is not required to have "glyf" (or "CFF "). We should create an empty "glyf" table if it doesn't already exist. The presence of a "CFF " or "CFF2" table in place of the "glyf" table may complicate things further.. Does your font contains "CFF " table for the black and white fallback glyphs, or just "SVG "?
the error because of spaces in the filename is a bit embarassing, will get that fixed as well 😅
Hm so, yeah, yours is a CFF-flavored opentype font (.otf) so it does not contain any "glyf" table, only "CFF ", with the outlines of the black-&-white only glyphs.
In theory we could/should support creating a CFF-flavored COLR font, and nanoemoji can make one already from a set of .svg files (with --color_format=cff_colr_1
flag). Supporting making these from an OT-SVG font using maximum_color tool is possible, just takes some care with adding the extra glyphs to the existing CFF table (need to refresh my memory on that).
In the meantime, I suggest you do this. Convert your CFF-flavored opentype font to a TrueType-flavored one (.ttf), so it will have "glyf" instead of "CFF ". You can use this otf2ttf.py script in fonttools/Snippets directory.
$ git clone https://github.com/fonttools/fonttools
$ cd fonttools/Snippets
$ python3 ./otf2ttf.py -o /tmp/Gilbert-Color_Bold_Preview5.ttf "Gilbert-Color Bold Preview5.otf"
$ maximum_color --build_dir /tmp/gilbert-max-color --output_file Gilbert-Color_Bold_Preview5_SVG+COLRv1.ttf /tmp/Gilbert-Color_Bold_Preview5.ttf
$ ttx -l /tmp/gilbert-max-color/Gilbert-Color_Bold_Preview5_SVG+COLRv1.ttf | grep -E "COLR|SVG"
COLR 0x495C5A5F 29268 84316
SVG 0x82E2DDDE 477824 118372
Many thanks for the hints!
I converted the font to a ttf as you mentioned and indeed the final output seems to work in both Firefox and Chromium.
And when stored as a woff2, the file size difference is quite small (102kb vs 96kb).
Cool! Is that FireFox Nightly?
And when stored as a woff2, the file size difference is quite small (102kb vs 96kb).
is the 102kb the one that contains both SVG and COLRv1?
No, it is Firefox 104.0.2 (and Chromium 105.0.5195.125).
is the 102kb the one that contains both SVG and COLRv1?
Yes, I'd assume so.
ah, ok - Firefox stable 104 is probably just reading the OT-SVG table, not the COLRv1. If you try the latest Nightly it should work with COLRv1 as well. You may not notice the difference because the two tables are suppose to look the same, but you can strip the SVG table and leave only COLR in it to check if FF Nightly loads the COLRv1 table (e.g. ttx -x SVG font.ttf && ttx font.ttx
)
Indeed. Without the SVG table, the file size becomes 41kb as a woff2 and doesn't work in Firefox stable anymore. So I will stay with the larger file for a while and switch to COLR-only once it is supported in all browsers.
By the way, your font doesn't use gradients, only flat colors with transparency, it could also be encoded as a COLR version 0, and that should make it work almost everywhere, so you might not even need to provide both an SVG and a COLR version 1 table.
maybe i'll add an option to maximum_color to make it create a COLRv0 from a suitable OT-SVG font like yours
I have a quick WIP patch to allow converting your OT-SVG font to COLRv0, it's not ready to merge yet
https://github.com/googlefonts/nanoemoji/compare/otsvg-to-colrv0?expand=1
with this, I was able to add a COLRv0 to your font (the .ttf variant), then after stripping the SVG table from it using ttx, I get an uncompressed .ttf file of 109KB, after woff2 compression it gets down to 33KB. Not bad!
i just noticed that that your font doesn't actually contain any transparency, if I grep for "opacity" I get nothing among the .svg files extracted from the OT-SVG table. In fact the colors in the CPAL table generated by maximum_color end all with FF
(the A for "alpha" in the BGRA color definitions is basically opaque). You simulate the blending of the opaque color layers as if they were transparent. Interesting!
Okay, I can reproduce all of this and indeed the 33KB COLRv0-only file works fine in both Firefox and Chromium. Just to clarify, I know nothing more about this font than that I found it recently and thought it would be great as a webfont in some use cases. And the CC license means that I can share the results of this thread once I have time for it so that others can use the font directly.
BTW @Theelx, you might be interested in this as you also mentioned using this font in this repository (#380)
ah thanks, that's ok, sorry I thought you were the author of the fonts :)
Okay, I think I have summarized everything at https://github.com/Findus23/RainbowRoad/tree/main/src/font
Thanks again for all the help!
Thanks so much for the ping! I made a workaround myself, but it only worked for some of the characters because of reasons I can't remember, so I didn't publish it. I'm ecstatic that you seem to have gotten it to work though!
@Findus23 FYI, I fixed the bug with spaces in filenames #442 and added a --colr_version flag to maximum_color (so one can select version 0 instead of the default version 1) in #443. I filed a separate #444 for tracking support for CFF-flavored OT-SVG, but won't work on it immediately as there's the otf2ttf.py workaround.
Hi,
I wanted to convert the Gilbert font from https://www.typewithpride.com/ to COLRv1 so that it also works in Chrome.
The default file name of
Gilbert-Color Bold Preview5.otf
seems to fail because of the spaces in the name.But even after renaming the file, I can't seem to get it to work with
maximum_color /path/to/test.otf
: