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.
Hi everyone who makes color fonts. If you provide a separated versions like an SVG and COLR font files, then how you explain the customer which one he needs for a specific application, in the case you sell color fonts on an external font market (not your own website) – in a text description or in a font file name? Do you provide a list of application support, like Adobe → SVG, web browsers → COLR, Affinity → COLR, and so on? So, for example, if the customer purchases Webfont license, he will know that he need the COLR version of the color font.
Both. My splits go into Dekstop/Web and then SVG/COLR in the folder name, together with the apps which support them. So for instance: /SVG (Adobe apps) /COLR (Microsoft & Affinity apps). Yes, it could be more precise or include more tools, but the people who use them hardly tread beyond these apps. Haven’t run into anyone using Quark in years.
I also still include SVG webfonts, just incase, but have a tag behind the COLR folder with “all browsers”, people seem to be able to find out what works.
Then I also include the color font type in the file and font name, so it’s easier for the client to find and use each version (as sometimes people have both installed).
Thanks Arthur, such an explanatory folder structure makes sense when you sell directly. I suppose, working with markets, I need an additional promo image that explain the difference between color font versions, I suppose it will be my option for now.
Why? Is it because of file size only or something else? Curious as I am down this route at the moment, having both COLR and SVG tables in the font file.
A good point regarding the font file (and style) name. I also decided to provide subpackage that contains both color font versions for the price of one font, so if the customer not sure which version needed, he gets both. I think it’s fair.
It’s a reason why I started this topic. Because color font with both tables doesn’t display correctly (just in black color, or display nothing at all) in some applications and web browsers. I’m not happy to separate color font into two versions but looks like this is the only way, because of Adobe applications that required SVG version.
I detected it in Safari 17 and 18 on macOS (Sonoma and Sequoia respectively) – 17 display the color font with both tables with random luck, and 18 display nothing making the text invisible.
Arthur says about possible issues in Office (I suppose on Windows) and Affinity Designer, however I didn’t tested it yet. Also I wonder if Rainer might know more about other applications.