Convert a PDF/X-4 to CMYK

In this example, we are going to create a list of actions in PitStop that converts a PDF/X-4 with different colour spaces (RGB, Lab, CMYK with various colour profiles, spot colours etc.) to CMYK as defined by the colour profile of its output intent.

What this list does is, in this order:

• It overwrites the PitStop colour management settings.
• It convert all greyscale objects to CMYK black (passing all ink to the black plate).
• Finnally, it applies the action "Remap color" to convert the colour modes to DeviceCMYK (The reason for this is explained below).

Override colour management settings

First we add the action "Override colour management settings". This is very convenient when changing colour values in a list of actions, as it allows us to make sure that the CMYK (or RGB) that is going to be applied by default is the colour profile we want and not another one that slips in without us realising it. By including this action we clean the existing management values to impose our own to run the list.

In this example, we assume a PDF/X-4 document whose output intent is the CMYK colour profile "Coated FOGRA 39 (ISO 12647-2:2004)", according to the standardised FOGRA 39 printing conditions and which is installed with the Adobe suite (although very similar ones are available elsewhere).

We choose "Yes" in the option "Enable color management" to be sure colour management is active (if not, this list may have unintended results).

Next, we define the default colour values for the main "Source" colour modes, that is: The colour profiles that are supposed to define each colour mode present in that document; for example: If objects in RGB mode were created with "Adobe RGB (1998)" or another profile. This will affect elements not tagged with a colour profile:

• Grey: Here we will leave the profile proposed by PitStop ("FujiFilm Generic Gray3"). It is actually not very relevant as the possibility of having elements with this kind of profile is low.
• RGB: We will assume that any RGB without a profile would be "sRGB" (the reason is more sociological than technical and we will not elaborate on it, as it is not very relevant).

• CMYK: Here we choose, the colour profile of the output intent ("Coated FOGRA 39 (ISO 12647-2:2004)").

  Warning: If we activate the option "The output intent overrides the selected ICC profiles" then the colour profile of the output intent will be the one used in the corresponding section (usually CMYK). If it is the correct profile, that's perfect, but if it is wrong and we want to set another one (extending the list of actions to correct that), we should unmark this option.

• Lab: Here we will leave the profile proposed by PitStop ("FFEI Input Lab Profile"). It is worth remembering, by the way, that the default Lab mode in Adobe software is CIELAB with illuminant D50.

In the "Target" section, we  deselect the option "Use other ICC profile than the source". Thus, the destination profiles will be the same as the "Source" ones.

In the tab "Images" we check the option "Apply general color settings". Sol, the pcitures (pixel objects) will receive the same treatment as the other objects.

Select all

We start the changes by adding the action "Select all" to make sure that nothing is left unprocessed with this list of actions.

Change gray to CMYK black

We add the action "Change gray to CMYK black" to redefine any object in greyscale without a profile (DeviceGray) as the corresponding black ink values (no "CMY") in DeviceCMYK. It has no options and that's all it does.

Remap colour

Now we include the action "Remap color" to convert everything to CMYK values without an associated profile; that is: Device CMYK (DeviceCMYK).

We do this because, if we want the whole document to be CMYK and to match the values of the output intent profile, the PDF/X-4 standard forbids the tagging of CMYK elements with the same profile of the output intent (this is done to simplify colour management and to avoid possible double conversion errors). So, they must be DeviceCMYK.

We will define the following conversions (in this order, which is important for the proper execution of the action):

• "Device RGB" → "To Device CMYK".
• "Calibrated RGB" → "To Device CMYK".
• "Separation, DeviceN and NChannel" → "To Device CMYK". In the options of this section, we will only leave checked the option "Include process color separations" checked, in case there is a colour definition of this type that uses one of the CMYK colours.
• "ICC tagged" → "To Device CMYK". This command converts anything with an ICC colour profile, whatever its colour mode (if it has not been converted with any preceding command, of course); for example: An image with an Adobe RGB profile (1998) will be converted. So will a CMYK object with an ICC profile.
• "All other" → "Keep". Any other colour is left untouched. This must be the last order.

In all cases we will leave the overprint untouched.

Issues and benefits

This is a reasonably easy and reliable list of actions. It has a problem that could be important in some cases: There may be areas with a total ink coverage (TAC) higher than desired. This is because we have chossen that PitStop will not change anything that is already in DeviceCMYK. So if the TAC somewhere in DeviceCMYK exceeds that desired limit, it will remain so.

The reason for this decision is the price to pay to preserve pure CMYK ink compositions, e.g. CMYK: "0/0/0/100" or "0/100/100/0", which is highly desirable in printing.

A practical example: Let's assume a PDF/X-4 with an output intent for newsprint paper, with a very low ink maximum (220% in the case of the "WAN-IFRAnewspaper26v5" profile, for instance). If there were elements originally defined with a colour profile that supports a much higher TAC (let's say the 330% of "ISOcoated v2") and they are already in DeviceCMYK, the conversion will leave that excessive TAC untouched.

Moreover, this excess of TAC can occur because, as PDF/X-4 allows transparencies, two overlapping objects may not exceed the TAC individually but yes as a transparency group. And this cannot be corrected without transparency flattening.

All this hinders a general strategy in this list to solve that without harming elements that should not be changed.