[Openicc] Ghostscript PDF/X-3

[Kai-Uwe Behrmann]

Am 22.03.12, 17:53 +0100 schrieb Kai-Uwe Behrmann:
> 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

Oh, that sentence slipped through. It should read: