[Openicc] Printing Plans GhostScript / sRGB / ICC

[Kai-Uwe Behrmann]

Am 02.03.11, 23:00 +0100 schrieb Jan-Peter Homann:
> Hello Kai Uwe and all,
> If we want to use PDF as print spool format containing all necessary 
> informations containing the colormanagement for the PDFtoRaster incl. the "No 
> Colormanagement Option", it should be done from my perspective as follows:
>
> If we want the "No Colormanagement Option" we need simply a DeviceXXX PDF 
> matching the general Space (RGB or CMYK) of the printer.

Yes, they should match or the system shall give a sensible fail message.

> If we want to tell PDFtoRaster an "sRGB to printerSettingABC transformation, 
> we have to use a PDFtoPDF filter first, in the case that the printing 
> application can only create DeviceRGB sprintspool PDF files.
>
> The PDFtoPDF filter will change all DeviceRGB to ICCbasedRGB for every PDF 
> object, embedd sRGB-profile in every object, set the rendering intent for 
> every PDF object to perceptual and integrate the profile 
> PrinterSettingABC.icc as Output intent.
>
> Now we are 100% conform to the ISO standard.

agreed

> The question is, if this workflow is smart, if we can reach the same goal by

[Its smart, clever, cool, 95%; choose as you like ;-)]

> e.g. scripting GhostScript to use the default input profile sRGB and the as 
> target profile PrinterSettingABC.
>
> If we are able to script GhostScript to configuire a target profile, we are 
> also able to script GhostScript not to use any profile.

I doubt that we will be able, or only in a subset of cases. My feeling is,
that the local print flow will soon be a corner case. And we should 
prepare to a heterougenous environment already now. Look at all those 
smartphones, tablets and so on. They are expectedly soon the majority of 
print clients. If we miss to adress them we are exots. We should offer 
those platforms a well integrating and scalable path. This would put Linux 
in a strong position as a leading implementation for colour managed 
printing. ICC should become and remain mainstream IMO. A falling 
back to sRGB for all and everything has no consent here. General PDF 
is the way to go for us. Ghostscript/Poppler and our xxxtoraster filters 
are in this context just some of many bricks, even though they are 
essential for Linux.

> The direct setup of GhostScript has also the advantage that it could be used 
> both for PostScript and DeviceXXX PDF files.

It reminds me on hacking a PPD together, which needs a certain xxxtoraster 
filter and a dedicated rasteriser on a local machine. Its nice and can 
work. But it is not far enough reaching. It feels like a network 
connection to the local host - not the real thing for our system 
architecture. Again CUPS is networked and we are well served to deploy 
these capabilities as a great gift.

> Best regards
> Jan-Peter
>>
>>>  I don´t see any need to integrate a "color management of flag" directly 
>>> into DeviceXXX PDF files.
>> 
>> It is not to be integrated. The standard is already existing. We have few 
>> choice to ignore that if the print system shall conform to.

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