[Openicc] PDF srgb Workflow

[Chris Murphy]

On May 16, 2011, at 2:36 AM, Jan-Peter Homann wrote:

> Hello all,
> In past discussions some people stated, that a colormanagement print pipeline can´t work with DeviceRGB PDF files and needs instead ICCbased RGB.
> 
> From may point of view, the question depends on the possibilities of the pdftoraster engine. So far as I understand, poppler can´t transform DeviceRGB objects from sRGB to a printer profile.
> 
> But with GhostScript, this can easily eached by activating ICC-colormanagement for DeviceRGB objects and use the GhostScript default sRGB profile for this usecase.

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

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

> As an addition, handling the rendering intent from sRGB to printer profile is much more easy, if its specified per printing session, than if it has to be hardcoded into every single ICCbased PDF objects, considering also that ICCbased PDF rendering intents can´t transport the information for blackpoint compensation.


I wonder if the system could implement this portion of PDF 2.0, which I think will implement a BPC tag in PDF per object, just so that there isn't some non-standard interim implementation? It would be PDF 1.5 or 1.7 based, plus this bit from 2.0?

It seems to me what is most often the case is you want BPC to happen whenever RelCol is used. The proofing case is less common, and more specialized, so I see the necessary metadata from the application writing out such PDFs (or any other file format) is an "antiBPC" tag that inhibits the default application of it. Otherwise we have a bunch of apps that default to a proofing like behavior without BPC, which is not what we want, especially for legacy apps.

Chris Murphy