Color OTF font changing color on printer's proofs

[DKingDesigner]

I created an icon font with colors (OTF) using Fontself for Illustrator so I could easily apply colored bullets to a book I was working on. Everything looks great in InDesign, Acrobat, and printed on our color printers, but when I sent the books off for printing, the proofs came back with all the icons in different colors than they appear in my files. The printer said they are different CMYK values after running them through their prepress. I can't figure out how to fix it short of finding each and every one of them in the six books and converting them to outlines manually.

I'm open to suggestions on how to quickly fix this problem so that these books can be printed. Maybe a specific color preset when I make the PDFs? We are currently converting to US Web Coated SWOP V2 on export.  Is there a way to force InDesign to convert graphic fonts to outlines when exported to PDF?

[Roger Breton]

Rob,

I agree with your suggestion and I'd like to investigate the matter further myself, as the original poster isn't likely to be the last person to run into this situation. The InDesign engineers should already have a solution for this, in my view,  hopefully coming in a future release, but clearly the popularity of these "Color fonts" is not going to go away and they ought to be better handled, color management wise, just as the rest RGB elements in InDesign are treated.
I hope I'm missing something obvious here...

[Roger Breton]

I'm glad I started to read this thread. And I would like to thank the original poster for taking the time to share this issue up. I must say I wasn't terribly familiar in my practive with OpenType SVG aka "Color Fonts". After reading the problem that the original poster ran into, especially in view that the books in question were to be printed in China -- the formidable language barrier! -- I deemed I had to try this out myself in InDesign. I actually created an Illustrator document in which I typed in a bit of text using the EmojiOne font, an OTF SVG "Color Font". I created the document in RGB and imported the document into InDesign. I then exported the document as PDF in various ways to see how Acrobat would handle it.

  I must say I spend a bit of time trying to research the business of color separations in the Adobe OTF SVG I could find online but there wasn't anything specifically related to color management. Bummer.

  What worries me is the "absence" of specific handling of the OTF SVG fonts in Acrobat? And there was nothing I could find as to their handling at Export time, out of InDesign. 

  The only way I was able to get the glyphs to show up in some "known" space was when I converted them to outlines in Illustrator. Otherwise, neither DeviceCMYK nor DeviceRGB were able to show these objects in Acrobat. 

  It was so weird. 

Moral of the story? I don't know what to think for I don't see a clear path of how "Color Fonts" are processed at output time from InDesign. I plan to bring up the issue with my students in Fall when we get to discussing fonts. As long as the output is destined to be the web or some form of electronic document, which is probably what these font variants were created for, in the first place, the door is wide open. But the minute we have to step into the realm of printing, then, extreme cautious must be exercised. I hope I missed something really obvious but the original poster should not have to resort to using a Script to work around the problem. My two cents.

[Roger Breton]

Here's one quick workaround. No need to use any scripting, this way.

The "solution" is to use the Edit > Convert to profile command.

And then, Export without (further) conversion to Acrobat.

The results were not perfect but much closer to the expected CMYK values.

For some reason, the objects don't show up under DeviceCMYK?

But do show up as DeviceCMYK under the Object Inspector...

[rob day]

Hi Roger, what profiles are you converting to? I’m not seeing any change after a convert to profile when the PDF is actually RIP’d or output.

Here the bottom Ts have been converted to outlines in InDesign and the page was exported via default PDF/X-4. The preview in AcrobatPro looks correct, but when I imitate a RIP by opening as CMYK into Photoshop the conversion of the outlined versions is correct, but the SVG version is not even close:

[Roger Breton]

Hi Rob,

I better take the time to document evertyhing with screen grabs. Until I do...
The DocumentRGB = sRGB
The DocumentCMYK - GRACoL2006_C1

So Export with NoConversion.

And when I open the exported PDF in Photoshop, the CMYK build remains the same?

Regards / Roger

[rob day]

I’m not getting anything close to the InDesign CMYK values.

Here I’ve added some control fills that match the font color—again the bottom Ts have been converted to outline:

Export to PDF/X-4 with no conversion—the control fills match:

Opened into Photoshop as GRACol CMYK:

[Roger Breton]

Either you re-export from InDesign to Acrobat 5 (PDF 1.5) "straight" (no standard selected) and do the rest of your experiment or I try to follow in your footsteps and redo with a similar Trajan document, and export to PDF X-4.

Question, why X-4? PDF X-4 says "Includes all the CMYK Sources profiles"?

I'm worried there is an Output Intent showing in Acrobat? 

The presence of the Output Intent has biten me in the past in a Kodak Prinergy workflow. 

The whole thing turned to "Poscript Color Management" CIE-Based spaces in the PDF?

Had to reexport the whole thing with no profile, Rob?

[Roger Breton]

Rob,

I redid the experiment by Exporting to PDF-X4 and the result was even better -- no conversion of any kind? Acrobat CMYK build and Photoshop CMYK build matched InDesign CMYK build (in Separations Preview). Wish we could get hold of a sample page from the original poster?

[rob day]

Here are my test files, which replicate @DKingDesigner ’s problem—the font is Trajan Color Concept, which should be included with ID. The problem doesn’t show in the PDF, you have to "RIP" my PDF to a CMYK bitmap to see the actual output values:

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42ahttps://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

https://shared-assets.adobe.com/link/766e4050-6133-40fb-56be-e94ad999a42a

[Roger Breton]

Here's what I'm finding this far. I opened up your document and Exported using the PDF/X4:2008 Preset. 

In Acrobat, under Output Preview, the document elements only show up under RGB ICC, which makes sense.

BUT the top red T disappears...? What can I say.

In Photoshop, I notice the discrepancy between the stem of the two Ts, as you reported. No question.

For "curiosity"... 

I pulled the Separations Preview in InDesign and, when I switch to CMYY in the Output Preview panel, I see the same thing as in Photoshop?

To me, the font Trojan RGB "color space" is most likely NOT sRGB, even though the officiel SVG specs says "sRGB".

The two sets of elements were clearly not processed the same way? Are not in the same "source" color space.

It's possible the default Flattening Color Blending Space setting, which is usually CMYK, is getting in the way?

I tried swittching to DocumentRGB space and immediately, the stem of the red T changed visually, no longer matching your solid RGB rectangle below.

I've iterated a few times and I'm surprised to find a difference in the "name" of your "red" swatch (r217g60b42) which is the correct value for the left hand side of the stem and the actual RGB values shown in the Color panel R=250, V=59, B=34.

Here's a screen capture : https://1drv.ms/u/s!AkD78CVR1NBql-Bp6rMydhiwmdwQtQ?e=ULWHfr

Sadly, I find this "example" inconclusive. I suggest we contact the original poster to obtain a one page Package with his OTF SVF aka "color fonts" for us to experiment with. Thanks for your patience and kind help.

[Roger Breton]

BTW, after further experiment, I noticed that InDesign automatically creates the RGB swatch entries as a consequence of Converting the text to Oulines...

[Roger Breton]

I feel I'm going to rest my case?

My latest experiment, based on EmojiOne "color font" selected glyphs, has gotten me the correct output in both Acrobat and Photoshop.

I invite you to take a look at my InDesign document and exported PDF/X4 here : https://1drv.ms/u/s!AkD78CVR1NBql-Bql5V3UhukEC8GPQ?e=axtsHz

/ Roger

[DKingDesigner]

Hey, all. I appreciate all the work you have done on this, but I will add that I always PDF/X4 standard on all my print PDFs. I was able to use one of Rob's fixes from the first night of my post to get a file that exported pretty darn close to the colors I wanted (and that I could pull into Photoshop with no deviation), but when I sent that file to the printer, thinking my problem was fixed, their RIP saw the whole file as RGB and screwed up the colors again. I was at the limit of what I could test in house without having access to the actual prepress software the printer was using. I gave up and redid the files excluding the SVG color OTF.  My caution to both of you is to not think you've solved the problem just by juggling the color conversions between ID, Acrobat, and Photoshop when you don't actually have access to the prepress RIP that will be used to process the file. Everything I tried that seemed to work on my end was rejected by the printer. My new files minus the troublesome font passed the prepress with flying colors (pun intended) and are now in production. 

[DKingDesigner]

As to why we use the PDF/X4 standard . . . most of our printers have required it, so we created all our print presents based on it. 

[Roger Breton]

I'm curious, you say PDF/X4 has allways worked for you: was that pretty much a "requirement" on the part of the printers you had experience working with? And did any of these printers ever supplied you a "joboptions" file, to use in your Exports to PDF? 
The only time I ever sent anything to China for printing, I made sure I supplied CMYK documents. 

At Transcon, we had some clients who had no clue about color management -- entire magazines with placed RGB pictures. In those cases, we had the chance to work with them to tell them exactly how to supply the PDF to us, so that we could handle the required RGB -> CMYK ICC color conversion at our end. 

Personally, I always supply "Linear" PDF documents out of InDesign, everything being converted to GRACoL2006_C1 CMYK on export, from placed sRGB and CIE Lab content. I proof the PDF on an ORIS CGS ColorTunerWeb RIP at my end and, most of the time, there isn't too much difference between my output and the proofs I get from printers.

Would you care to post an excerpt of your InDesign document that uses those "Color font" natively? 

[DKingDesigner]

Our US printers were the ones that required the X standards for their online RIP apps. We just followed their guidelines and used them for everything. When we started printing in China, we added color conversion to US Web Coated SWOP V2 to the preset to prevent color variations we were experiencing on some of our products. It's interesting that you have discovered that the standard was causing the issue. After my 4 or 5 different attempts to fix the color issue, the only thing that actually worked was removing the font from the process (either by converting it to outlines in InDesign or by replacing the font with a standard black OTF). It's too late for me to try another standard for the output since I spent the necessary time to redo the files without the font and have already gotten my books into production. If you were able to get your workflow to work using other color fonts, I would assume it would have worked for my font as well, but with the language barrier dealing with China, I'm content to let this rest. I will flag your follow up experiements as correct answers for anyone else who runs into this issue. Thanks for your thorough work on this matter. Perhaps Adobe should add this to their documentation on support of SVG fonts. 

[rob day]

Hi Roger, I think it’s important to note that the the problem is only showing in RIP’d output and is not really noticable in InDesign or an exported PDF— @DKingDesigner only caught the problem in the printer’s returned PDF, which was likely run through their RIP. I also am seeing the problem with your example when I imitate a RIP by opening the exported PDF as CMYK.

I think you have to use AcrobatPro’s Object Inspector (not Separation Preview) to see the unusual color properties of the SVG fonts. It looks like the ColorSpace and Color Values in Object Inspector depends on color applied to the selection in InDesign. So here I set the fill of the selected glyph to RGB black and it gets exported as ICCBasedRGB sRGB

The native Color Values for the outlined version are not the same:

The PDF converted to a GRACol CMYK bitmap:

[Brad @ Roaring Mouse · Accepted solution]

Sooooo... I think I've got it figured out:

If you use the PDF/X-4:2008 spec, the colors will screw up.

If you use PDF/X-3:2002 or PDF/X-1a: 2001, the colors will render properly.

After doing some tests with Illustrator using the same 3 standards, which work fine, it seems there's something happening when ID exports to that standard with the SVG fonts.

I also went back to ID2020 and found PDF/X-4:2008 problematic there too, but in a different way.

Anyway, here's the result...(Exported with Color Convert to Destination)

 

[Roger Breton]

I must say, while I followed the conversation and noticed the use of PDF/X4 in the various posts, in my own practice, in the prepress department I used to work with, at Transcontinental Printing, we never used anyone of those "X" standards. I tried using some "Color Font" from here Color Fonts - Get ready for the revolution! and, exporting to "plain" Acrobat 6 (PDF 1.5) with No Color Conversion on the Output tab and got correct RGB builds everywhere. I had no idea X flavors of PDFs were so prevalent these days...

[Brad @ Roaring Mouse · Accepted solution]

So, I've narrowed it down to an issue around the Inclusion of a Destination Profile in the PDF export.

I discovered that saving to PDF/X-4:2008 (2010), does not seem include the desination profile when Output is set to Convert to Destination, despite it actually saying so in the greyed out menu. This indeed might be a bug.

Downgrading to any of the standards below that one seem to work fine, including having "None" set as a Standard, as long as the Include Destination Profile is selected.

So, you should be able to save yourself some work/time by exported a PDF using a different standard.

 

[rob day]

I discovered that saving to PDF/X-4:2008 (2010), does not seem include the desination profile when Output is set to Convert to Destination, despite it actually saying so in the greyed out menu. This indeed might be a bug.

Hi Brad @ Roaring Mouse , it looks like the problem happens in the transparency flattening and isn’t related to profile inclusion. I do see better results with PDF/X-3 and PDF/X-1a where the page is flattened on Export (Acrobat 4 Compatiblity).

PDF/X-4 as well as X-3 and X-1a export Document CMYK color as Device CMYK. With PDF/X-4 it is a feature not a bug, it reduces the chance of accidental CMYK-to-CMYK conversions (i.e. [Black] converted to 4-color), and the Output Intent Profile tells the printer what the document CMYK profile is.

It looks like the SVG fonts incude transparency (InDesign’s Flattener Preview highlights Trajan Color) If I export my Trajan example as PDF/X-4 and flatten the page using AcrobatPro’s Flattener Preview the extreme color problem becomes apparent.

Ironically one of the selling points of PDF/4 is it delays flattening of live transparency and possibly color management until output, but with SVG fonts PDF/X-1a’s flattening will produce a better result.

[Brad @ Roaring Mouse]

"With PDF/X-4 it is a feature not a bug"

Thanks, I actually found that out after I posted! Which makes sense, but seems to be throwing ID off on the SVG.

I actually delved into the PDFs with PitStop and compared one created with the PDF/X-4 preset with a few made with other standards. In all the other ones, the objects that made up an SVG object were individually tagged with the output colorspace (in my case, GRACOL), whereas the 4:2008 one was not tagged (which, as you mentioned, was probably by design), and had the incorrect cmyk values.

I also printed my test file out to Postscript (full Level 3 PS/Color Unchanged) and it rendered properly, and also Distilled perfectly, no matter what Standard I used.

[rob day]

I also printed my test file out to Postscript (full Level 3 PS/Color Unchanged) and it rendered properly, and also Distilled perfectly, no matter what Standard I used.

I think that also indicates live transparency in the PDF is the culprit—distilled Postscript files get flattened.

If I print and distill my example, the PDF has no transparency, but there are also no fonts listed in the PDF—the Type 3 Trajan font gets converted to a DeviceCMYK image. Both a distilled PDF, and an export to default PDF/X-1a give me numbers that match InDesign’s Separation Preview—but in both cases the SVG Type 3 font is no longer listed in the PDF’s Document Properties.

If I set the PDF/X-1a preset’s Standard to None, change the Compatibility to Acrobat 7 (live transparency), and include the GRACol Destination profile, the PDF numbers no longer match InDesign’s Sep Preview, but the Type4 font is included in the PDF:

[Laubender]

I followed all this without having time doing some tests.

Will do the next days. Thank you all!

Hm.

Who is doing the bug report(s)  at InDesign UserVoice or Prerlease?

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs

Oh! Mario Aspeslagh already did in January 2020:

Color font printing in muted colors in pdf/print
Mario Aspeslagh, January 29, 2020
https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/39561139-color-font-pri...

I commented there and voted for a fix.

Regards,
Uwe Laubender

( ACP )

[DKingDesigner]

Thanks for digging that up. I wasn't sure if it counted as an InDesign bug or not, so I hadn't gone that far. Obviously it is reproducible since several have reproduced it in this thread, but since color fonts are fairly new and, from what my research has shown, intended for digital use, I wasn't sure that lack of print support was actually a bug. I will go comment and vote on the linked report. 🙂