[Openicc] Printing Plans GhostScript

[Hal V. Engel]

On Tuesday, March 01, 2011 10:47:28 AM Michael Vrhel wrote:
> 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?

Yes we need an explicit way to tell it to pass things directly to the printer.   
It is clear that anything else will have issues.

> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110301/6885f5a8/attachment.htm>