[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Friday, February 11, 2011 05:31:25 AM Leonard Rosenthol wrote:
> On Thu, Feb 10, 2011 at 9:33 PM, Hal V. Engel <hvengel at gmail.com> wrote:
> >  I had a closer look at the PDF files produced by the Qt print dialog. I
> > 
> > see the following:
> > 
> > 
> > 1. The first line is
> > 
> > 
> > %PDF-1.4
> > 
> > 
> > So these are NOT PDF/X.
> 
> PDF/X doesn't care about the PDF version.  It can be anything from
> 1.0->1.7.
> 
> The identifying factor is in the XMP - but yes, I suspect that they are
> not.
> 
> > 2. All image objects are either DeviceRGB or DeviceGray even when using a
> > color managed app like Krita with a color managed image. Looking at the
> > code in QPdfEnginePrivate I see that that this is hard coded.
> 
> And there is no DefaultRGB or OutputIntent of any kind.  So no profiles at
> all, eh??

Yes that is correct the API does not allow for anything color space related to 
be included in the output other than hardcoded setting of DeviceRGB or 
DeviceGray for images. 

> 
> > 3. Images are always 8 bits/channel or less. QImage limitation.
> 
> That's not a big deal - most PDFs are that way.   (and 16bit images didn't
> appear till PDF 1.5).
> 

Yes most PDFs are that way but that is beside the point.  We currently have 
high bit depth open source apps at both ends of the printing work flow.  Things 
like CinePaint, Krita, UFRAW and others (Gimp will be added to this list at 
some point) which support 16 bit/channel (and higher) formats for 
creating/editing images and, at the print driver end, GutenPrint which 
supports 16 bit/channel input rasters.  If I create a 16 bit/channel image 
using UFRAW (which supports color management and yes I know that only about 12 
bits/channel are significant but 12 is > 8) and then pull it into Krita to 
tweak it and then try to print through a Qt created PDF there will be 
significant loss of precision.  We should have a way to preserve as much of 
that precision as possible on the way to the target device.    

> 
> Leonard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110211/3f7def8a/attachment.html>