[Openicc] Ghostscript PDF/X-3

[Chris Murphy]

On Mar 22, 2012, at 10:53 AM, Kai-Uwe Behrmann wrote:

> Hello Michael,
> 
> Am 21.03.12, 11:23 -0700 schrieb Michael Vrhel:
>> If a device ICC profile is explicitly given using the command ption -sOutputICCProfile="my_device_profile.icc" then the assumption is that this is truly the ICC profile that describes the device I am printing to.   If in addition, I include the option -dUsePDFX3Profile, then the OutputIntent ICC profile will be used as a proofing profile, so that when I print (or display) to my actual device I should see what was intended to be see as if it had been displayed with the device described by the OutputIntent.
>> 
>> This proofing will also occur if the process color model does not match the process color model of the OutputIntent.   For example, if I am rendering out to an RGB device and I specify -dUsePDFX3Profile and my OutputIntent is a CMYK ICC profile.   Again, I would like to see on the screen an approximation of how it would appear if printed on the CMYK device.
>> 
>> If I do not specify an ICC profile for my device with  something like -sOutputICCProfile="my_device_profile.icc" and the process color model for my device matches the color space of the OutputIntent and I include -dUsePDFX3Profile on the command line, then the output will be rendered into the color space defined by the OutputIntent ICC profile, assuming that the OutputIntent included an ICC profile and was not simply a registry and a standard profile name.
>> 
>> Does this all make sense?
> 
> -dUsePDFX3Profile + -sOutputICCProfile cover all possible combinations you intent to support. Your description above is more clear to me compared to the Use.htm page. From reading Use.htm I concluded the -sOutputICCProfile had priority. Now it is clear to me, the -sOutputICCProfile will override any possibly existing -dUsePDFX3Profile as colour space and degrade the later to a proofing profile. It is logical but maybe not so obvious given the PDF/X-3 spec evokes an other expectation.

I'm a little confused. Possibly for different reasons.

There are two kinds of PDF/X-3 (I'll include variants 4 and 5 as well), those with an OutputIntent embedded ICC profile, and those without - merely the output condition identifier is present (a printing condition not in the ICC registry).

If the embedded profile is included, my expectation is that no flags are required for the OutputIntent to be used as the destination space. Any /ICCBased or Lab object, is converted to this destination using the embedded Output Intent profile. So does -dUsePDFX3Profile cause OutputIntent to be used? What if it's not present, what happens to this PDF/X-3 document?

An additional flag for proofing condition is appropriate, where the intermediate destination is the OutputIntent, and the final destination space is the proofing space (display or proofing system). And possibly a flag for rendering intent, as some may prefer RelCol, other may prefer AbsCol.

-sOutputICCProfile= sounds to me like an OutputIntent override. I think everyone can predict in advance what I think of this, if it is what I think it is.

Please feel free to refuse all of my premises and conclusions if that is easier.

Chris Murphy