[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 2, 2011, at 5:35 PM, Alastair M. Robinson wrote:

> Hi :)
> 
> On 02/03/11 23:37, Chris Murphy wrote:
> 
>> It could be in either pdftopdf or pdftoraster. It depends on how much abstraction you want for pdftoraster for such things.
>> If someone inserts their own pdftoraster then what?
> 
> So pdftopdf would do what?  Extract the job ticket and then hand it downstream as a CUPS option?

Rewrite the PDF based on job ticket info to produce a PDF that gets the desired results from Ghostscript, so Ghostscript gets the right options.

i.e. if the job ticket does not contain the "color management off" token, then rewrite the PDF such that /DeviceRGB is sRGB, and insert the OutputIntent based on the profile chosen in the CPD.  If there is a "no CM" token, then STRIP any ICCBased object and turn it into /DeviceRGB with no OutputIntent.

> Either way pdftoraster's the component that communicates with Ghostscript (or poppler, or whatever), so whether it arrives as a job ticket or a CUPS option, the option would need to be honoured by pdftoraster.  If someone's swapped out pdftoraster then it's up to them, surely, to make sure it does the right thing!

I think it's better to have the PDF itself call the shots. There are other pdftoxxxx filters that are possible. Do you want to replicate all of these behaviors into every pdftoxxxx filter? Or end up with inconsistent results with, e.g. pdftopcl? pdftotiff? pdftops? I think you can do this once with pdftopdf and have a properly formed PDF that describes the intentions.


>> We already have second guessing of PDF intent, if it's not PDF/A or X or E. What does /DeviceRGB mean when
>> the output is RGB and there is no OutputIntent?
> 
> Well that's precisely what the option I posited would select - "Make my colours pretty" mode would cause DeviceRGB to be interpreted as sRGB (or whatever), "Leave my colours alone" mode would cause it be passed through unmolested.
> 
> Can you think of any situation where you'd simultaneously need both the output profile to be honoured *and* DeviceRGB to be passed through?

Sure, page layout programs can write out PDF/X-4 where some objects are already converted for output, and others are not. The ones converted for output are /Device based and the rest are ICCBased and the OutputIntent describes the destination space to which ICCBased objects are converted, and is the source and destination (null) for /Device color.

The questions are: how will such applications be expected to submit their print jobs to this pipeline? And is it possible to submit any PDF to the pipeline as-is?


Chris