[Openicc] Print Color Pipeline

[Kai-Uwe Behrmann]

Am 25.01.11, 08:28 +0100 schrieb edmund ronald:
> On Tue, Jan 25, 2011 at 8:13 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Am 25.01.11, 10:00 +1000 schrieb Jon Cruz:
>>> On Jan 25, 2011, at 3:39 AM, Kai-Uwe Behrmann wrote:
>>>> Am 24.01.11, 17:02 +0100 schrieb edmund ronald:
>>>>>
>>>>> You know, maybe the gimp-usability guys have some suggestions here?
>>>>> I think they're one of the most affected apps for profiled printing.
>>>>> In fact, one of the big arguments for Linux would be to have a
>>>>> seamless Gimp setup, equivalent to the seamless Photoshop setup you
>>>>> get with the Mac.
>>>>
>>>> Agreed. Peter Sikking has already prepared ideas for a UI. As it stands
>>>> now, IMO the common print dialog (CPD) would be the single best controlable
>>>> entry point for colour management settings.
>>>> Do plan Krita and Scribus to use that dialog for local printing?
>>>
>>>
>>> I do think this should be taken grain of salt. I'm not sure of the status
>>> in recent months, but when I've discussed things with Peter, he seemed to
>>> not quite grasp some of the subtle needs of professional printing. Things
>>> like artists being able to control overprint, knockout, rich black, etc.
>>
>> However, it will be much more difficult to get those features inside CUPS.
>> CPD offers more control just by its place in the achitecture.
>
> I believe these are separation issues?  Do they actually affect *local
> printing* which is what CUPS is all about? I mean, if you want a

The CUPS patch works on server side. The term local does not very well 
apply to CUPS server. So your local profile and settings are invisible to 
CUPS server. The patch does not even know anything about the user. It 
blindly assumes it is the actual one.

> special type of inkjet rendering you invoke a profile, but then you
> already need to know a lot about the printer you are using, and if you
> want to print on press you spool the file out from the application, so
> it doesn't go through CUPS anyway?

Oh, yes. From this point of view CPD makes even more sense.

> I have no experience with this - the only workflows I deal with are
> local photo workflows which are RGB from the beginning to almost the
> end (until final CMYK conversion for inkjet).
>
> Edmund
>
>>
>>> The best thing would be to consider the use cases that showcase the
>>> various issues and make sure he can get a good UI to cover all, not just the
>>> average end consumer cases.
>>
>> Agreed.
>> It would be great, if you experts could work on that.

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