[Openicc] PDF srgb Workflow, PDF print spool handling

[Jan-Peter Homann]

Am 16.05.11 17:19, schrieb Chris Murphy:
> On May 16, 2011, at 2:36 AM, Jan-Peter Homann wrote:
>
> Chris:
> Question: Are PDF's which contain /DeviceRGB, but are not PDF/X (with OutputIntent), in some sense malformed?
>
> I ask this because either /DeviceRGB was used intentionally, or whoever wrote the app which wrote out the PDF doesn't understand the consequence of using /DeviceRGB, i.e. that it's ambiguous. It could be reassigned to anything and it's fair game. They should write out these PDF's with ICCBased objects in any case, so it can be argued that unintentional use of /DeviceRGB is a malformed PDF.
>
> Both Mike Sweet and Leonard Rosenthol have expressed reservations about assuming /DeviceRGB is sRGB when the output is also RGB. It's a given that /DeviceRGB objects being printed to a CMYK device, at some point in the print path, will need to be converted (or the reverse case /DeviceCMYK printed to an RGB output device.)
>
I think, we should expect, that the majority of PDF rint spool files 
will stay DeviceRGB for a longer time.
As more or less all printers are CMYK+X printers, there must happen a 
transform for DeviceRGB PDF print spool files. Currently, this 
transformations are hardcoded RGB-CMYK transforms either in Gutenprint 
or drivers from other suppliers.
Getting rid of hardcoded RGB-CMYK Conversions on driver level and moving 
to an sRGB->CMYK ICC based conversion in pdftoraster is a big step 
forward concerning colormanagement in the print path.



>> 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.

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.

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
- has not to change the status of PDF objects from DeviceXXX to ICCbasedXXX
- has not to manipulate the rendering intent of ICCbased PDF objects

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

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)

Jan-Peter


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de