[Openicc] PDF srgb Workflow, PDF print spool handling

[Kai-Uwe Behrmann]

Am 16.05.11, 18:44 +0200 schrieb Jan-Peter Homann:
> Am 16.05.11 17:19, schrieb Chris Murphy:
>> On May 16, 2011, at 2:36 AM, Jan-Peter Homann wrote:

>>> As this GhostScript-option doesn´t has side effects for ICC-based content 
>>> in PDF print spool files, we can start a color managed printing path with 
>>> the print spool files produced by the vast majority aoff applications.
>> We need to make really sure that if such substitution is enabled, that it 
>> is robustly NOT enabled for PDF/X or we instantly have serious problems.
>> 
> Jan-Peter
> Firstly we would have to check, if GhostScript allows an configuration, that 
> an PDF/X Output Intent has always a higher priority than a default profile.

Thats a requirement of PDF/X anyway.

> Further more, we have to talk about, what is the role of the PDF/X-Output 
> Intent in the print workflow. So far as I know, you prefer a workflow, where 
> the Output Intent is identical with the printer profile, valid for the 
> choosed print setting.
> In this case, the PDF-file can be colormanaged by pdftoraster without any 
> further metainformation about printer profiles. (self containing PDF print 
> spool file)
>
> From my point of view, this seems first hand a very attractive workflow 
> solution, but it is very tricky to implement during print spool creation:
> 1) The toolkit for print spool creation has to pull the valid ICC-profil for 
> the choosen driver setting, to embed it into the spool file as Output Intent
> 2) The toolkit for print spool creation must be able to convert all 
> PDF-objects to ICCbased objects otherwise the Output Intent will not create 
> an color transformation from source to Output-Intent
> 3) The Toolkit for print spool creation must be able to set the rendering 
> Intent in all ICCbased PDFobjcets, because users may want to print a file 
> with differnt intent per print case.
> 4) We currently have no solution what happens, when the PDF delivered to the 
> toolkit for print spool creation has already and output for e.g. 
> offset-printing.

agreed

> I still doubt, that the nice idea of self containg PDF print spool file is 
> the right direction.
>
> I personally prefer a solution, where the PDF print spool file contains all 
> necessary information about the document colorspace (including per object 
> profiles). For doing this, the toolkit for print spool creation
> - has not to pull the valid profile for the driver setting

The cupsICCProfile is based on CUPS CM. The application is not required to 
handle a pull in this case. On the other hand, the applciations has to 
push the local ICC user configured device calibration profile for 
selfcontained PDFs. And that later makes a lot of sense for networked 
printing.

> - has not to change the status of PDF objects from DeviceXXX to ICCbasedXXX

As soon as a toolkit has CM support there will be no DeviceXXX at all.

> - has not to manipulate the rendering intent of ICCbased PDF objects

Maybe there are issues currently with this.

> Instead, the necessary informations for the printer profile and the desired 
> rendering intent for printing are transported through CUPS metadata.

While we are here clearly comitted to develop rules for open source colour 
management systems, open source software is as such not much tied to 
Linux. In fact the main user base for open source software sits on Windows 
and we have to adress this. So we need general approaches, and these 
can only be based on standards like PDF.

[That said, I have to admit to have no complete picture of the standards
  used by CUPS and how these are supported on the Windows platforms.]

> Such workflow is much more easy to implement in the toolkits for print spool 
> creation. It also deals with the cases, where PDF/X files are made e.g. for 
> offset-printing, which is pretty common for PDF/X.
> In this case, the PDF/X file is firstly rendered to the output intent and 
> than with the user specified rendering intent to the printer colorspace. 
> (Thats, how all professional proofing RIPS handle PDF/X files today)

Interessting. However proofing is at this point too early. And if the 
PDF OutputIntent represents the final inkjet printer, than those RIPs are 
plainly wrong. So it appears more clear to not customise the PDF 
OutputIntent for the purpose of proofing in our context.

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