[Openicc] CUPS Color Management under Linux gets into distros

[Kai-Uwe Behrmann]

Am 28.02.11, 12:06 -0800 schrieb Hal V. Engel:
> On Monday, February 28, 2011 06:22:29 AM Cyrille Berger Skott wrote:
>> On Friday 11 February 2011, Hal V. Engel 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.
>>>
>>> 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.
>>>
>>> 3. Images are always 8 bits/channel or less.  QImage limitation.
>>>
>>> So the Qt PDF print work flow will need a lot of work done to it to be
>>> fully useable.  Has anyone here who works on Qt or KDE based imaging apps
>>> like krita or Scribus have any work arounds for this?
>>
>> As far as I know Scribus uses its own PDF generation code.
>
> I guess I knew this already.  In fact, if my memory is correct, the PDF code
> in Scribus is able to handle creating fully formed correctly color managed
> PDFs.  And it is one of the few open source apps that will do this.
>
>>
>> As for Krita, by default, the image is converted to sRGB 8bit for printing,
>
> I guess this is about all that can be done with the current printing software
> stack and the limitations currently imposed by Qt short of writting a printer
> interface.  Converting to sRGB is more than most apps are doing at this point.

The only other way around these limitations is to generate early printer 
code. Thats done in PhotoPrint. But I guess what PhotoPrint does is out 
of scope for most applications (except of the mentioned Scribus). I wonder 
what could be suggested to use PhotoPrint from inside Krita (beside the 
Gtk/Qt appearance). Export a tiff and call PhotoPrint for it? Will this 
match the Krita settings? Or will CPD improve Kritas printing?

> The underlaying issue is that the paint engine should allow apps to paint
> images in formats other than QImage (IE. a jpeg or tiff) and the backend should
> parse the image for things like ICC profiles and it should use those as part of
> the output stream if the actual paint device support these like a PDF device
> can.   Or QImage needs to be extended to support this meta data and higher bit
> depths. I suspect that the Qt folks would argue that you can open most image
> formats as a QImage so is unnecessary to allow painting in native file formats
> but this ignores that fact that the process of opening a tiff or jpeg image as
> a QImage discards almost all of the meta data that is part of that image
> including ICC profiles.  In addition it flattens the image to a max of 8
> bits/channel.

Qt appears here like on the same level as Google. They are make things 
less than just simple.

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