Hello. I have a color font exported with both tables SVG and COLR/CPAL. On Sonoma’s Safari 17 color font displays randomly, time of time, the text can disappear even when I change the size of window or just scroll the page. And on Sequoia’s Safari 18 it doesn’t displays at all.
I tried to export WOFF file without SVG table, and it helps! In this case the latest Safari display font as expected. And so far I know, webfont with only COLR/CPAL should work in all modern browsers. Sounds good, but
The problem is that I can’t provide WOFF files separately from OTF to all font markets. Some of them accept only OTF, and then generate WOFF versions automatically on their side.
Should I just ignore that bug on Safari? I will appreciate any suggestions and best practices.
I think he tried to have the desktop fonts with svg so that they work in Indesign and the web fonts without svg as that works better on the web. But it seems that you can’t have different binaries for desktop and web font.
If the market places insist on generating the WOFF files from the OTF files, then you’d think it’s their responsibility to do so in an adequate way – which would include removing the SVG tables.
Perhaps it’s possible to reach out to those market places and let them know that their current policy and process yields webfonts that don’t work properly, and that they should either rectify it or allow separate uploads for WOFF files.
Thanks. Correct, I can’t provide Webfont font files additionally of Desktop ones because some markets accept only OTF/TTF but not WOFF/WOFF2. So there are at least 4 options:
Talk to markets so that they optionally accept Webfont files in addition to Desktop ones.
Report to Apple to fix a bug/behavior in recent versions of Safari.
Provide two separated (one with SVG and one with COLR/SPAL) OTF/TTF files to font markets. However it may confuse the end users about which version they need.
Sell color fonts only directly + in markets that allow me to provide the Webfont in addition to the Desktop font files.
I’ve been using option 3, with a clear folder structure in the downloadable so the end-user knows what to install.
I have found that a clean, single-colorsystem export also prevents some bugs that can appear in Office based software and the Affinity suite. (with the last one only supporting COLRv0).
Including both COLRv0 and SVG data in a webfont also increases file size, so isn’t preferred!
Thanks Arthur. Also, I think that when offering different versions of the color font (COLR and SVG), it makes sense to explain (in the text description) to the customer which version of the font he needed for a particular application.
Arthur, it is possible that I miss something, but according to this table, Affinity Designer support SVG (not COLR) color fonts. Is that information out of date?
Yeah, that info is out of date, Affinity has been supporting COLR for a long time. This is especially useful as the suite also supports variable fonts since v2.5, making it the only desktop design app to support variable color fonts.