[Openicc] PDF srgb Workflow, PDF print spool handling
homann at colormanagement.de
Mon May 16 09:44:16 PDT 2011
Am 16.05.11 17:19, schrieb Chris Murphy:
> On May 16, 2011, at 2:36 AM, Jan-Peter Homann wrote:
> 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.
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
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
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.
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
---------- 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
More information about the openicc