[Openicc] CUPS Color Management under Linux gets into distros
Hal V. Engel
hvengel at gmail.com
Fri Feb 11 08:28:24 PST 2011
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>
More information about the openicc
mailing list