On Dec 15, 2011, at 8:08 AM, Thibaut Simonart wrote:
Hello Peter,
A few days ago, you answered some of my questions very kindly ! I still
struggle with something however.
You wrote to me (and I experimented a bit so I have seen it first hand) that
if you convert to destination with "preserve number", then the original
separation stays the same.
If I understand correctly, the numbers of the coulours before exporting the
document and after are still the same ? If it is the case, what is the
difference between "no conversion" and "convert to destination (preserve
numbers)" ?
Yes the user interface and terminology is messy, and non-obvious.
Look at Color Settings, Color Management Policies. For CMYK there is one "Preserve
Numbers (Ignore Linked Profiles)". The PDF export option you're referring to is
related to this color management policy, but it takes some explanation.
The Preserve Numbers policy, only for CMYK, was designed under the notion of a "Safe
CMYK" workflow. By default, CMYK content will not be converted at print/PDF export
time. But you do get color management (conversions) to the display, as well as embedded in
the InDesign document. Even these statements require qualification, that's kinda how
silly the color management paradigm still remains...
InDesign has application default settings for color spaces referred to as Working Spaces.
They are merely default settings. Upon creating a new document, that document inherits the
Working Spaces profile settings (and the Color Management Policies) at the time the
document was created. Those inherited settings are called Document RGB and Document CMYK.
This is why once you have a document open, and you go to Color Settings and make a change
to Working Spaces, it does not affect your document. You have to use Assign Profile to
make such changes to redefine the Document RGB or CMYK space.
A document, that has inherited the Preserve Numbers (Ignore Linked Profiles) policy,
behaves in the following manner: Every CMYK object by default is Document CMYK. So
whatever the Document CMYK profile is, the object's source profile is that Document
CMYK color space. And by object, I mean native InDesign objects like lines, shapes,
background colors, etc.; and also imported files like PSD, TIFF, JPEG, AI. So if you have
a Photoshop PSD, and a "SWOP" profile is embedded in that PSD, when you place it
into this InDesign document with a CMYK Color Management Policy of Preserve Numbers,
InDesign *ignores* the embedded profile. The placed image inherits the Document CMYK
profile. And it will preview on-screen with its new source profile (if the InDesign
Document CMYK is different than what's embedded in the PSD).
If you build an InDesign document in this manner, you end up with all CMYK objects as
Document CMYK. And when you export a PDF using Preserve Numbers - there is no conversion
for anything (except RGB and possibly spot to be converted to process). Further, even if
you change the Destination profile, you don't get a conversion for CMYK. Preserve
Numbers policy makes the Destination profile act temporarily as a substitute Document CMYK
profile. Anything Lab or RGB in the document is converted using the chosen Destination
profile. But not Document CMYK objects.
Another layer of potential complexity, but totally optional, you could actually
selectively choose specific imported CMYK placed files, go to Object > Image Color
Settings, and there you will see that your image's Profile is set to Document Default,
which means Document CMYK. But if you choose the pop-up menu, you will see one profile
above this Document Default, above a line, separated from all other options. This is the
profile embedded in the placed image file, which is not presently being used by InDesign.
You could choose to use it. If you do, this image only is no longer Document CMYK. And it
is no longer exempt from a CMYK to CMYK conversion with the Preserve Numbers policy. So
now when you export to PDF, all objects, except this one, will be immune from CMYK to CMYK
conversion.
The idea of this "Safe CMYK" workflow is that it's somewhat risky to always
convert CMYK images from one CMYK color space (e.g., "SWOP") to another (e.g.,
"Newsprint") using conventional CMYK profiles. Why? The most classic example is
100% K only text. When subject to a conversion using conventional ICC output device CMYK
profiles, 100% K is always converted to four color black which depending on the output
device, can be a big problem.
So now the conversation devolves into all of these choices that are highly workflow
specific, with workflow consequences rather than being inherently right or wrong. So what
should you choose? Well it depends. The first task is simply to understand how these
features work, what the exceptions are, and so on. And then you back track and choose the
policies and features that make sense for your workflow.
You may consider that for images only, that do not contain any text at all, that such CMYK
to CMYK conversion is OK. But you still have to consider if it would be better to obtain
the original RGB and convert directly to the proper CMYK color space in the first place,
rather than an extra conversion. Ahh but can you get access to the original RGB? Maybe
it's not a cropped version, or it's higher resolution, or there were color
corrections done on the CMYK version that aren't in the original RGB. All of these
kinds of questions.
So that's why it's not a one size fits all answer. It's more difficult at
first to learn how these things work. The terminology is not great. The user interface
does not make behavior of the application discoverable. The interface does not reveal all
potential options, even though the color engine is capable of much more. In effect,
complex workflows while more flexible, require more people in that workflow to be more
knowledgeable. The workflow becomes more boolean, rather than binary.
Ok I think this is quite long enough, if I haven't totally confused you beyond
redemption at this point!
Chris Murphy