[Openicc] GoSoC 2011: CPD and target printing

[Kai-Uwe Behrmann]

Am 12.05.2011 12:48, schrieb Michael Sweet:
> On May 12, 2011, at 7:07 AM, Kai-Uwe Behrmann wrote:
>>> ...
>>> The workflow I would like to see is this:
>>>
>>> 1. The profiling app handles printing targets, reading targets,
>>> generating profiles, and registering profiles with their associated
>>> settings (call the combination a "preset" for lack of a better
>>> word).  The same kind of application could create new presets using
>>> existing profiles (i.e. this is where you would be able to choose an
>>> alternate profile, even if it wasn't qualified for use with the
>>> settings you want...)
>>>
>>> 2. The print dialog allows the user to select presets. When no
>>> preset is chosen, the print dialog will choose a profile based on
>>> the vendor rules.
>>>
>>> 3. The printing system and/or color management system provide API to
>>> query and store preset information. Ideally this API allows for
>>> user, system, network, and vendor presets.
>>
>> 2. and 3. reads good. For 1. I would prefer some more independence,
>> beside applications which want cover all in their own.
>
> There are very few applications that actually have everything needed
> to print a target and generate a profile. Even Adobe Photoshop doesn't
> do it. That said, I am not saying there is only one application that
> does #1, but that the application in #1 is distinct from a normal user
> application that prints (using #2).

Ah well, I distinct application #1 to be a potentially splitted and
modular one, to do calibration / native printing separated from
profiling. So inside your premise #1 I would agree. But I am afraid we
talk about different user communities each of us tries to convince.

So what is appropriate for Gnome and osX might be out of question to KDE
and CPD has to address these differences if it want to serve as a GUI
design guide.
 
kind regards
Kai-Uwe