[Openicc] Printing Plans GhostScript

Michael Vrhel michael.vrhel at artifex.com
Tue Mar 1 10:47:28 PST 2011


Hi Kai-Uwe,

You are free to have the profiles be where ever you want them.  That would 
be an implementation for how you wanted to invoke ghostscript.  If you want 
to wrap the PDF in some manner with a set of profiles that is fine.  In the 
end, ghostscript needs to have the PDF stream and the profiles through its 
interface.

So you say that it is not robust to have the profiles be the same to avoid 
conversion.  It would be possible to include a command line option to avoid 
any color conversion for Device based colors that are native to the target 
device.    For those that are not native some type of color conversion has 
to occur.  Is this what you would like to see?

We are adding in the proper required support for the output rendering intent 
right now.  It will probably be in the trunk within the next month.

Kind Regards,

Michael

-----Original Message----- 
From: Kai-Uwe Behrmann
Sent: Tuesday, March 01, 2011 2:15 AM
To: Michael Vrhel ; Open ICC Color Managment
Subject: Re: [Openicc] Printing Plans GhostScript

Hello Michael,

Am 28.02.11, 22:09 -0800 schrieb Michael Vrhel:
> Hi Jan-Peter,
>
> So yes, ghostscript does apply ICC base color transformations on 
> Postscript files and this is true even for DeviceRGB and DeviceCMYK.
> I need to add in the interface for rendering intent and black point 
> compensation.  That will be coming shortly.  In fact, I am also adding in 
> the ability to specify different output profiles for graphics, images, and 
> text as ghostscript keeps track of these objects during rendering, even 
> through transparency blending.   The specification for these options is 
> primarily through the CLI but can be made through special configurations.

Would it possible to pass those profiles along the PDF document itself?

> As far as "turning off" transformations for DeviceRGB or DeviceCMYK, that 
> will occur in cases where the source and destination profiles are the 
> same.

We came several time to the conclusion that this scheme is not realy
robust. So we would be happy you could point us to an other mechanism as
well.

> 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.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management
www.behrmann.name + www.oyranos.org


[1] http://lists.freedesktop.org/archives/openicc/2011q1/002770.html 



More information about the openicc mailing list