[Openicc] colord Printing Plans, CPD and Gutenprint role of PPD

[Chris Murphy]

This is why I think press proofing needs to be off the table for now. From my experience with this (which is somewhat limited, I think Leonard knows more about this), I'd say the following are doable in a v1.0


•	Flat color PDFs
•	RGB only, mixed color space (i.e. sRGB and Adobe RGB), with live transparency, with an RGB blend space.
•	CMYK only, single color space, live transparency, with CMYK blend space.
•	Single output intent.


If you include, in the core system, the ability to do two transforms it gets much more complicated. And to effectively proof you'd have to deal with mixed mode content, along with transparency anyway. That's is in the realm of commercial products for now, IMO.

And as for the CPD soft proof for the single *local* destination (again I'm not considering printing presses to be local printers), e.g. to my local laser printer. I'm generally opposed to simulating paper white on-screen in a print dialog. You have all sorts of surround color issues that obliterate any ability for the simulated paper white to be even remotely helpful. If anything it's harmful. The intent to display for such a "soft proof" should be RelCol no BPC. Not AbsCol.

Cloud printing is another area of exploration of the issues, and might go in a v1.0 or maybe v1.5. How must it differ from local printing? Or maybe how doesn't it differ at all? And what do the cloud printing services need to provide to integrate? Do they even give a crap? Is it all proprietary anyway?

Chris Murphy





On Mar 1, 2011, at 6:02 AM, edmund ronald wrote:

> Please understand that anyone seeing endless theological discussion of
> multi-layer PDF files with various embedded profiles and rendering
> intents will get frustrated. I think Chris is right, and people
> wanting RIP abilities would do well to be advised to move to a RIP
> today.
> 
> Edmund
> 
> On Tue, Mar 1, 2011 at 1:59 PM, edmund ronald <edmundronald at gmail.com> wrote:
>> Kai Uwe,
>> 
>>  At this point with all this discussion of complexities, I am giving
>> up hope that you people will ever be able to design a system which is
>> actually capable of printing even an sRGB file decently. Can't you get
>> it? 99% of files out there are simple Jpeg photographs in sRGB and
>> THEY NEED TO BE PRINTED.
>> 
>>  What might really advance our discussion here is a flow chart of CUPS
>> - anyone got one? Showing how files are dispatched and filters
>> invoked?
>> 
>>  And a decision to declare some basic file types which the print
>> system may wish to special case, eg. the various profiling targets and
>> "special" sRGB for when the system is just a skeleton.
>> 
>> Edmund
>> 
>> On Tue, Mar 1, 2011 at 10:58 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>> Am 28.02.11, 17:09 +0100 schrieb edmund ronald:
>>>> 
>>>> Jan Peter,
>>>> 
>>>> With all due politeness, exactly what is your interest in this
>>>> discussion? Which part of this are you going to  implement?
>>>> 
>>>> Regarding Gutenprint, either you people come to some agreement by the
>>>> time Robert has implemented settings, and you can apply a profile, or
>>>> I will *myself* write a module that assumes that everything sent to
>>>> its is sRGB, apart from when it is clearly DeviceRGB or DeviceCMYK.
>>>> This module will ensure that sRGB files are printed decently and solve
>>>> the consumer printing issues.
>>> 
>>> Btw. the pdftoraster filters will do a colour conversion. So I do not
>>> understand your point in a additional module.
>>> 
>>> kind regards
>>> Kai-Uwe Behrmann
>>> --
>>> developing for colour management www.behrmann.name + www.oyranos.org
>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>> 
>> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc