Hi Andrew, this works fine, keeps it all together. About your questions: I think they may be related in some ways.
The Indesign print bug is weird. Does it print in color when you convert the text to outlines? And does anything strange happens when the are converted? (missing colors/elements, so on).
Which version of Word/Office are you using? I have never had issues printing/previewing, so this might have to do something with the color font type? You are sure it’s the COLR version which is loaded? I believe all Office versions from '16 and upwards should also support both SVG and COLR.
• I forgot to say yes when the text is outlined in InDesign it prints in color, and there are no issues / nothing strange happens when it’s converted. The issue came from a client and I was able to confirm the same issue on my end, and with other COLR fonts made with the same technique in this thread.
Also, if the indd doc is exported to PDF the PDF prints in color.
Just a thought, it’s printing solid black and not grey versions of the colors - would that mean it’s something to do with the fallback glyph?
• I can’t replicate the Word issue (I don’t have it) but they only have the COLR version of the font to load. I assume they have the latest version of Word but I will check.
About Indesign: That seems to be case, there is a way to check: make the fallback slightly different than the “flattened” color layers. I never had this issue happen though. But if the font is a COLR font, it should appear as black/white anyway in InDesign, as it only supports SVG. Perhaps there is some kind of color table mixup happening.
For Word: I believe something similar is happening, but it’s hard to check without specifics. Word supports both SVG and COLR, both in print and display. Perhaps a similar conflict in the color tables?
What happens in testers? Does it print from the web? Can you swap the palette of the COLR files using a tool like DJR’s Color Font Customiser ?
• So I changed the fallback and in InDesign it is printing the fallback in black, but displaying the color font fine on screen
• The font displays and prints beautifully in color from the web
• Yes I can swap the palette successfully in the DJR customizer (what an amazing tool!)
These are the Custom Parameters in the font, hopefully it’s a simple table conflict?
Yep, think so. Although COLR/SVG into one font works, there are probably weak links, such as printing or the preview in word, when it supports both specs.
I suggest creating a pure SVG version with the settings below for InDesign:
Thanks!
So with these settings the issue is reversed:
• In InDesign it displays and prints perfectly, but on web browsers it displays the fallback black glyph because it doesn’t have the COLR Table
Is it impossible to have it work everywhere all at once?
If so the solution would be to export .otf files without the COLR Table, and .woff with the COLR Table… have one set of Custom Parameters for print and another set for web…
Which would be to uncheck the COLR Table for print (as above) and check it for web?
Brilliant thanks guys. So I exported the font with the Export COLR able unchecked as per the screengrab Arthur attached, and you’re right it’s a Chrome issue showing the black fallback glyph. Firefox and Safari both display the colors fine.
What also throws me off a bit is the DJR Color Customizer gives the message “This tool requires a color font with a CPAL table.” for the font exported without the COLR Table.
So in conclusion for anyone joining this very helpful thread at a later date, what’s the best / most versatile set of Custom Parameters to use for a color font to work in most scenarios possible? Is Chrome the only stumbling block with this method?
Yeah, this is true, so used to COLRv0/1 that SVG for web is mostly forgotten ;).
I advise a split between COLR/SVG as well for Web/Desktop use: Embedding both color systems into a single font will give you quite a size hike, which I doubt you want.
Thanks Arthur, will try the split export parameters for WebDesktop to be safe. Shame about Chrome!
And yes embedding both color systems makes a huge file! Totally unexpected size for a font.
Thanks again for your help
Separating production for Desktop/Web make a sense in this case if you can control all the chain Developer → Buyer. However, if you cooperate with distributors, it is worth paying attention that not all of them may allow providing (by developer) separate Desktop and Web versions of font files. Some distributors may accept only otf/ttf, so Webfonts are generated automatically in this case.
