[Openicc] Printing Plans GhostScript / sRGB / ICC

[Kai-Uwe Behrmann]

Am 03.03.11, 01:06 -0000 schrieb Alastair M. Robinson:
> On 03/03/11 00:47, Hal V. Engel wrote:
>
>> That is a possibiliy but why not just tag the objects in the PDF file
>> correctly so that it is passed through? After all if the app is smart
>> enough to produce color managed spool files it should be smart enough to
>> figure out what the printing pipeline will pass through directly to the
>> printer.
>
> The problem isn't just with apps that want to print ready-targetted images, 
> it's with apps that aren't colour-smart, and printing legacy PDFs.  That's 
> going to be pretty much everything for some considerable time.

And thats why it was suggested to consider DeviceRGB without OutputIntent 
as sRGB. Michael stated that Ghostscript will behave this way and as 
stated by Chris its in line with Mac OS and Windows. So non smart apps are 
colour managed by the opt-out policy. Honestly I hope, similiar to Hal, 
that CM aware apps will soon embedd the OutputIntent and we are 
almost done.

>> The only time pass through or not is ambiguous is when there is no
>> OutputIntent and the objects are tagged as DeviceXXX and there is only
>> one DeviceXXX type used and it matches the printer color mode.
>
> Unfortunately, that's going to be a very common situation!  Almost all 
> consumer printer drivers currently in use expect RGB input, and most apps 
> will print via a toolkit - none of the toolkits is colour-smart with regard 
> to PDF output as yet, and realistically it will be very long time before they 
> are.

Yes, and that should be handled like sRGB as mentioned above.

>> aware app wanting it's already CMed spool file to pass through should
>> set the profiles of the embedded objects == the OutputIntent and it will
>> get pass through since this is completely unambiguous. The main thing is
>> to make sure that pdftoraster honors OutputIntent.
>
> You make that sound easy, but as far as I know it's not even close to being 
> possible with either Cairo or Qt.

Cairo and Qt are currently not colour management aware. So they fall into 
the dumb category and will be handled as sRGB for their DeviceRGB without 
OutputIntent. Thats fine and user will be satisfied to see their sRGB 
images printed as sRGB. I do not know of any applications for calibration 
or early colour management, which can rely on Cairo's or Qt's PDF output.
In the Oyranos image2pdf example code, which uses stock Cairo, all is 
converted to sRGB for print output. There is no easy way around that.

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