HELP - CMYK Swatches Changed Unknowingly Before Print

[shutch23]

Looking for some feed back from this community on an isolated issue I experienced with all CMYK swatches in a document I was working on. At somepoint during packaging and prepping for print all the CMYK swatches in the document changed to a  slightly different value with decimal points - almost as if they were converted to RGB and then back again. Example: 0/74/100/0 changed to 0/72.157/87.059/0

I've worked on and printed large files for 15 years and have never experienced this issue before and am at a loss to what happened. I verified that the document intent is Print and that this wasn't accidently changed to Web at any point during design or packaging. I checked any settings in Export that may be responsible but all are settings I would norally select.

Has anyone else experience this issue? 

Thanks for any guidance you can provide.

[rob day]

Hi @shutch23 , Do you mean the values you view in InDesign’s Swatch Options changed, or the CMYK values don’t match in the Exported PDF?

If the InDesign Swatches changed that could be caused by a CMYK Color Management Policy that was set to Convert to Working Space when the document was created—keep in mind that the Color Management Policies used for an existing document are saved with the document on creation. The document Swatch values could also be changed via Edit>Convert to Profile...

If the document swatch values are correct in InDesign, but are getting converted on an Export or showing as different values in AcrobatPro, there are a number of ways that could happen. Choosing a Destination profile that conflicts with the Document CMYK profile would do it. Also, if you included a CMYK profile in the Export>Output tab and view the document in Acrobat’s Output Preview with the Simulation Profile set to something other than the embedded profile you would get different numbers. The solution for both of those problems is to Export using a PDF/X Standard preset with the Destination Profile set to Document CMYK.

[shutch23]

Thanks @rob day - I mean the ID swatch options changed in the working file. 

[Robert at ID-Tasker]

Not sure if it helps or resolve the problem - but worth trying, just in case - what if you try IDMLing? Export your INDD file as IDML, then open it and save with a new name. Maybe file got corrupted? How often are you doing Save As with a new name - "housekeeping"? 

[shutch23]

Our IT Team is questioning if it's a corrupted file as well. It's been well revisioned.

[rob day]

Did you create the file? The floating point values you are getting would be typical of a CMYK-to-CMYK conversion, which can also be done manually via Convert to Profile...

[shutch23]

I did creat it but others have also opened and updated it out side of me. It's been a well loved living document.

[rob day]

Have other built CMYK Swatches changed or just the one?

[shutch23]

All swatches are off in the document (if that's what you mean) - it was across the board on uploaded ASE swatches and swatches that were already pre-built or created directly in the document.

[rob day]

but others have also opened and updated it out side of me

The other way it could happen is if one of your co-workers changed the Document Setup Intent from Print to Web and then back to Print, but your numbers seem more like a CMYK1-to-CMYK2 conversion—a CMYK-to-RGB-back-to-the-original-CMYK conversion wouldn’t change the numbers that much.

[rob day]

It can happen if the document was created with this Color Setting—the CMYK Color Management Policy is set to Convert to Working Space:

If I close the document and sometime in the future set the CMYK Working Space to a conflicting profile like Coated GRACoL, and reopen—the Policy is going to convert the SWOP  0|70|100|0 swatch to the Color Settings’ current Working Space, which could be anything:

On a reopen, the color conversion would be from the document’s assigned CMYK space (US Web Coated SWOP in this case) to the conflicting Color Settings CMYK Working Space—Coated  GRACoL 2006 here:

Again, it’s important to note that the CM Policies are saved with the document—it’s the document’s CM Policy, not the Color Settings’ Policy that manages the existing document. So it’s possible the CM Policy was inadvertently set to Convert to Working Space when the doc was created, or it was created by someone else.

[shutch23]

@rob day - do you notice anything in this Color Setting that would suggest an issue that would throw off the CMYK: 

[rob day]

Color Settings wouldn’t necessarily show you what an existing document’s CM Policy is set to—the CM policies are saved with the document. All I can say is the numbers you are getting are typical of a CMYK-to-CMYK conversion, but you could try an IDML save and see if that changes anything.

You can also get a document‘s CMYK policy via scripting. This would display the active document’s CMYK policy (which could be different than the Color Settings policy):

alert(app.activeDocument.cmykPolicy)

[shutch23]

@rob day, @Robert at ID-Tasker - thanks to both of you for your support yesterday. I think from all responses we know how to move forward.