[Openicc] Printing Plans GhostScript / sRGB / ICC

[Kai-Uwe Behrmann]

Am 02.03.11, 18:45 -0700 schrieb Chris Murphy:
> On Mar 2, 2011, at 5:35 PM, Alastair M. Robinson wrote:
>> 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?

If the print client can set the OutputIntent and object conversion itself,
then we do not need redundant and potential ambiguous job ticket options.

> 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 would assume that lpr and CPD do the rewrite internally without any job 
ticket involved. The job ticket is created when the PDF should already be
properly rewritten.

[I assume here that job ticket is meant as something that gets passed only 
to CUPS and not from a user to lpr/CPD.]

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

You meant probably "turn it into /DeviceRGB with OutputIntent"?

>> Either way pdftoraster's the component that communicates with 
>> Ghostscript (or poppler, or whatever), so whether it arrives as a job

What is granted is th PDF spec and that users pass things to the client 
side CUPS interface. Where the actual PDF arrives and which filters will 
be present there is out of scope for the client/user. Is can go from a 
local Linux machine or a osX server to a print cloud.

On the server side,
a Linux print server can accept a PDF through CUPS and print through 
Ghostscript/Poppler with honouring the PDF spec. That should work from 
Linux, Samba and osX clients the same way as long as they manage to send 
PDF standard conformant spool files. Linux should of course support that.

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

Agreed. CUPS has a client and a server side. The most relyable thing 
with all this is the PDF itself.

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

I tent to see such options more and more as a hack. Such might be
desireable to configure inside CPD to some degree. But it is not nice. 
The prefered thing is sending a PDF to CPD/lpr and done. A print target 
can be prepared to conform to PDF/X. (Of course that works only, if 
Argyll's targen and other tools create such.) Then a naive user can call 
CPD/lpr and print without any further options involved. Thats great 
usability. The same for prematched print data. Everything else needs more 
work to teach, to test, to implement and to maintain.

Leonard and me talked around a year ago about a missed pass through mode 
in PDF. I am so happy that he recently pointed out the DeviceXXX + 
OutputIntent mechanism in PDF/X (A/E). It would be a pitty if we miss 
this great chance. The PDF specification has it already done. We just need 
to learn.

Creating instead again a custom incompatible hack appears to me like 
creating special ICC profiles, which only a specially patched lcms can 
understand. And that in a open and general purpose workflow.
In the long run it is IMO much easier to concentrate on (ISO) standards. 
And that appears to me much smarter than hack something together in less 
than a week and fiddle with a hasty made decission for years after.

[Children are often enough quickly made. Getting them grown well is a 
dependent but completely different story. ;-) ]


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