Can you export this file?

[Magnus]

Hi guys and girls,

This is just an experiment to see how people handles Indesign-files and make PDF:s for print. If you got a spare minute, please download this test file and follow this instructions:

1. Make a print ready PDF-file (Fogra39 / ISOCoated_V2)
2. Post a link below or mail it to magnus.sandstrom[at]tmgsthlm.se

I will not give you any further instructions, this just an experiment so no prestige involved, just do as you usually do it.

Thanks!

Best regards,

 

[Magnus]

6 files right now. Please contribute with your PDF. Many files = better data for a conclusion and discussion.

Best regards.

 

[Stephen Marsh]

I don’t like the export results!

I think I know where the problem is. No, I have not posted a sample back as requested yet. I know how I would work around the issue in production to obtain a correct result.

I think that your “torture test” file has found a nasty bug in ICC colour inclusion handling with InDesign PDF export.


Stephen Marsh

 

[Magnus]

Thanks for all you files!

Here is the result (Just one of the files was "correctly" color managed, by my opinion).

Here is a video of how I work, to get the best result when handling a InDesign document from a customer or colleague.

This is how I set up the color settings in Adobe CC.

In this case I'm exporting as PDF/X-1a but this works perfect with PDF/X-4 as well (just change the export settings in InDesign).

I know that this document was messed up, but in my experience most of the designers doesn't have a clue about color management. So I assume that they are doing it wrong and correct their misstakes by assign the correct profiles of placed content and document. I've been working this way the last 4 years and have never had any problems with it.

Please post your comments and thoughts below!

 

[Stephen Marsh]

Magnus, this topic thread is going to be fun, I forsee lots of debate!

Firstly, let’s look at the file so that we are in agreement on the build (this should be easy). It is probably going to be harder to come to agreement on what is the correct interpretation of the intent, however I will save that for another post.

FIRST ROW: Two different RGB images, two different CMYK images - all with embedded ICC profiles.

SECOND ROW: RGB image, left hand image is presumed as the “original/source” tagged with sRGB, all other images have had a different ICC profiles assigned/overridden to change the visual appearance without altering the files RGB numbers.

THIRD ROW: Native vector elements in CMYK mode, document CMYK

FOURTH ROW: “Greyscale” patches, K only patch next to equivalent CMY values, one image tagged as F29 the other as F39. (This row is the one that I feel exposes a bug in the PDF export, I just can’t make sense of the results vs. the input settings in the PDF, more on this later!)

DOCUMENT PROFILES: RGB = ProPhoto, CMYK = U.S. Web Uncoated v2


Thanks for posting this topic thread Magnus, it will make for a very good discussion!



Stephen Marsh

 

[toronar]

Small printshop here.

I would contact the author of the document and ask what his intentions were, and/or get a signed off proof before production.

As for your observation that designers/customers do not "get" colormanagement, I agree with you.
In 99% of cases ignoring CMYK-profiles and converting elements with RGB-profiles is the right way to handle files that are sent here.

Of course there are exceptions, and don't get me started on FOGRA27 vs FOGRA39 ...
Or the fact that PDF/X output intents of jobs on uncoated stock (like letterheads) are nearly always FOGRA39.

I tried to educate customers, give tips - not much worked or would stick. Ah well, "work" for me I guess

 

[Magnus]

I would not contact the author of the document just because the document has a wrong document CMYK-profile or placed content aren´t assigned with it's own ICC, since I know that the authors answer would result in: me doing the above actions. And I would have to call almost every time someone send us a new file. And we always send customer a RIP-softproof or RIP-hardproof before production when we receive open documents like InDesign.

I agree with you about how to handle PDF-files, but we do convert tagged CMYK, and replacing Intent Output.

 

[Jason]

Magnus,

This is a great exercise and I appreciate your efforts in setting this up.

After doing some testing and reviewing the results, I believe that Example #3 is the only correct sample. It all has to do with how we handle row #2. The Designer placed the images into InDesign with "Show Import Options" enabled, then went to the Color tab and purposely assigned a new profile to each image which obviously changes their appearance. The Designer can see this result on their monitor.

My job in Prepress is to manage color of the images the Designer provides. My goal is to produce the Designers intended color even though the Designer mistakenly did not handle color management correctly.

Color managing row #2 will involve converting each image from it's assigned ICC profile (with it's current appearance) to the destination profile of ISO Coated v2. This will result in a different appearance of each image, just like the Designer saw on their screen.

In order to get all the images in row #2 to have the same appearance, you must override the ICC profile that was assigned using "Show Import Options." In your video, in the Profile or Policy Mismatch window, you changed how Placed Content would be managed from Keep Existing Assignments to Enable All Profiles. I believe Keep Existing Assignments is the correct option. (Since I don't read any foreign languages, I am assuming that the options in Placed Content are listed in the same order in English)

If a Designer went through all the steps of overriding the embedded ICC profile of an image with InDesign, then I believe that was their intent, for whatever reason, and I will honor it through my color workflow.

This is a great discussion.

Thanks for your time.

Jason

 

[gordo]

I know that this document was messed up, but in my experience most of the designers doesn't have a clue about color management. So I assume that they are doing it wrong and correct their misstakes by assign the correct profiles of placed content and document. I've been working this way the last 4 years and have never had any problems with it.

IMHO, What the designer basically saw on their screen is what they intended color-wise. They are not doing it right or wrong - they are trying to get an appearance that meets their desired end result. So, altering the file to bring all the different images to a common appearance would be wrong. Your green outlined result (the "good" one) would therefore in fact not be the good one. It may have been your intent but I don't think it was the designer's.

 

[toronar]

Just for laughs, a colleague once said:

"Our customers send us native files so that they get what they want, not what they delivered."

But I'd agree with gordo and Jason: what the customer saw on their screen is likely what they intended. And as before: that is why we ask them in such cases.

BTW if you can read german, there is an excellent guide to color management that explains the whys, hows and wheres about it:
Downloads – Freeloads › Cleverprinting (press the big green button that says "Cleverprinting-Handbuch GRATIS herunterladen" to start the download)
It is too bad that there is no international version in english, though.

We usually refer our customers to that guide, and, if it is a big customer, even provide the printed (and bought) version of it to them for free.

 

[gordo]

Well now that throws a wrench into the monkeyworks.

 

[tobiv]

hi there

number 10 was my 2nd attempt because i was suspecting Magnus was after this...
i would probably not change a client file this way without reaching out to the original designer to check what his intent was. after all he changed the image specific color settings.

it's easier to to say to a client (who in many cases is not delivering the artworks himself) that he should deliver print ready pdf (we are using the guidelines at PDFX-ready, die Organisation fuer standardisierten Datenaustausch von digitalen Druckunterlagen) and to change it (if necessary ) with pitstop or to check our result.

 

[Stephen Marsh]

Nobody else has yet discovered the elephant in the room when exporting (rows 3 & 4), no conversion and include profiles vs. no conversion and do not include profiles?


Stephen Marsh

 

[Magnus]

So if the customer have turned off color management in InDesign and no profiles are assigned to the document or the images you would do what? There have to be some kind of color management since you need to convert from RGB to CMYK. I guess you would pick up the phone and call the designer and ask if he/she want to print in CMYK? Gordo and Toronar seems to work with very skilled designers with calibrated displays..

 

[Magnus]

My point is:

If a photo or graphic element has an assiged profile (in the original file) you should color manage that object correct no mather what the designers colors settings are. Since most designers does not care or use default settings in InDesign.

 

[gordo]

Gordo and Toronar seems to work with very skilled designers with calibrated displays..

This is an interesting issue. I have never had a calibrated display and have prepared digital scans and files for sheetfed offset, heatset and coldset presses for 30 years and never had a problem. Much of the work I did was very demanding (e.g. about I did the prepress work for about 80% of Creo's marketing materials). I've only worked of MACs for that kind of work.
That being said, I have not worked with customer supplied files other than in the context of helping with the installation of ink optimization software for heatset and coldset presses. Those are the folks who get a mix of inputs (sRGB, Adobe 1998, CMYK etc.). The ink optimization software clobbers everything in reseparation.

 

[Stephen Marsh]

Magnus, for me it is all about managing client expectations. As “insurance”, a print service provider should have a written stated policy on colour handling so that customers know what to expect.

1) Does the shop fully colour manage both RGB and CMYK ICC tagged elements/documents, honouring the original profiles and converting to the appropriate target profile for the print condition? Even if this causes elements that were say 100K only in the original to convert to rich black values with the K value possibly being less than 100%? For untagged RGB and CMYK data, what are the assumed profiles used by the shop?

2) Does the shop colour manage/honour tagged RGB elements/documents, while using a “safe CMYK workflow” – ignoring profiles in CMYK elements/documents and honouring the CMYK values over the profiles? So even if a CMYK object is tagged with say F29 when the output is F39, the files CMYK values are presumed to be more critical than the colour appearance of the tagged profile. For untagged RGB and CMYK data, what are the assumed profiles used by the shop?

3) Does the shop ignore both RGB and CMYK ICC profiles? If so, what RGB and CMYK profiles will be assumed by the shop?


The above is an old discussion that has been/should have been going on for a couple of decades now.

EDIT: Of course, the above is in relation to ICC device profile workflows, however there are also ICC devicelink workflows and PDF workflows where it is possible to bypass the pitfalls associated with ICC conversions and retaining the K channel etc. So the above three workflow points could have a fourth one added if devicelink profiles are used.

What I am more interested in is that despite exporting with no colour conversion and safe CMYK or CMYK colour management off, I am seeing CMYK values converted or not converted depending on whether one elects to include or exclude the profile from the PDF export.


Stephen Marsh

 

[Magnus]

I agree with you both about the above. Of course you shoud have a well documented color management policy both for customers and staff, and we do. I know about all the issues with converting CMYK to CMYK (we use device links for this with inkreduction/gcr, in a PDF/X-4 workflow). But thats not the issue here.

The question should be:

Should you color manage objects by it's embedded profile? My answer is yes, no mather what color setting the designer has been using in InDesign. What do you think?

And if you disagree, please give me an real life example when this is a bad option.

 

[Stephen Marsh]

Does anybody here know how to script InDesign using JavaScript, or AppleScript?

After pondering this thread, I think that it would be great to have a script that does the following:

1) Edit menu/Assign Profiles/RGB = Assign Current Working Space, CMYK = Assign Current Working Space

2) Searches the document for and selects *only* CMYK images (not RGB/Lab), then applies the Object menu/Image Colour Settings/Use Document Default overriding any CMYK profile present (as previously set in step 1 when assigning CMYK, referring back to Colour Settings for CMYK)

The first point is easy enough to do manually, however if it could be scripted then that is great. The second point should not matter in theory if one is using the “CMYK safe workflow” of preserve numbers/ignore linked profiles – however again if this could be scripted it is a further level of enforcement.


If InDesign had actions, this would be easy to create, however as users are stuck with only scripting, it is easier said than done for those that can’t script.


Stephen Marsh

 

[Magnus]

I think Adobe should provide this kind of color management features as a native function. It would be great to have a setting to not convert CMYK line art. But I don't understand why you doesn't want to convert any CMYK-photos?

Best regards,