[Openicc] Printing Plans GhostScript

[Kai-Uwe Behrmann]

Am 01.03.11, 09:47 -0800 schrieb Hal V. Engel:
> On Tuesday, March 01, 2011 02:15:32 AM Kai-Uwe Behrmann wrote:
>> Am 28.02.11, 22:09 -0800 schrieb Michael Vrhel:
>>> The obvious example occurs if I have a document that has an RGB image and
>>> a CMYK image and I am printing to a CMYK device.  In this case, the RGB
>>> image will have to be transformed in some manner.  That transformation
>>> is under your control by specifying the desired default RGB source
>>> profile to use. For the CMYK image,  if you did not want the data
>>> touched, you should make sure that your default CMYK source profile is
>>> the same as your destination profile.  The CMYK data will then pass
>>> through unmolested.
>>
>> Will adding a OutputIntent to a PDF/X (A/E) be honoured for DeviceXXX
>> objects by Ghostscript? Leonard pointed this requirement out [1].
>> It could then be used to pass through unmolested Cmyk or DeviceN to a
>> according configured printer.
>
> Why not unmolested RGB and Gray as well?  Any app that is smart enough to

Oh, it was meant to be exclusive. Please read DeviceXXX.

> create PDF spool files with the OutputIntent set should be assumed to be smart
> enough to know what it is doing and the PDF spec should be fully honered.  The
> issue with assuming a color space for DeviceXXX objects should, if possible,
> be limited to apps that don't know better.  At this point there do not appear
> to be any CM dumb apps that can create PDF spool files with the OutputIntent
> set.  This is definitiely true for Qt apps that are using the standard Qt PDF
> printing chain.

> The issue here is retargeting.  If the print system receives a spool file with
> an OutputIntent that is different from what the system would use normally that
> device and settings what should it do.  One of the reasons for using DeviceXXX
> for objects along with an OutputIntent is to allow for retargeting.  Under
> those conditions it is assumed that the DeviceXXX objects are in the
> OutputIntent color space.  This is to allow for the output to be retargeted to
> a different device if needed using an OutputIntent --> new device color space
> transform for all DeviceXXX objects.  This means that setting the OutputIntent
> is also not a robust solution unless there is some way for the app creating
> the spool file to query the system for the devices profile so that it can use
> that for the OutputIntent.   This could be done using Oyranos or colord but

Retargeting is a special feature. It makes sense to retarget automatical 
if the DeviceXXX color space does not match. For instance a DeviceCMYK PDF 
sent to a DeviceRGB device should be converted using the OutputIntent. The 
same for displaying DeviceCMYK on the screen. This was mentioned 
previously here on list. That seems easy to agree about.

A DeviceRGB sent to a RGB device should not be changed automatical IMO. 
The same for any other matching combination. If a user requests 
retargeting explicitely, than that is out of scope of the default 
behaviour. Retargeting of say FOGRA27 to a local inkjet is already 
proofing. It would be a nice high level feature, but is as well dangerous 
for automatic applying. This feature would be more appropriate to manual 
userintervention.

Back to the 
On Mon Feb 7 16:51:42 PST 2011 Leonard Rosenthol <leonardr at pdfsages.com> 
wrote:
> OutputIntent doesn't convert anything.  It serves two purposes in PDF/X,
> PDF/A and PDF/E - and NO PURPOSE  in a standard PDF (since the spec says 
> it should be ignored).   The two uses are:
> - Destination Profile for the target device (should you need to retarget)
> - Source Profile for any DeviceXXX colored object(s)

I read from this in the DeviceXXX + OutputIntent combination:
* source colour space is specified
* destination colour space is specified
* => no colour conversion