[Openicc] colord Printing Plans, CPD and Gutenprint

[Jan-Peter Homann]

Am 28.02.11 10:42, schrieb Richard Hughes:
>> Furthermore, the experienced user should be able to have "Color expert
>> Options" in the printing GUI (e.g. CPD) to deactivate colormanagement
>> through printing a testchart for profiling.
> No, I don't think options are a good idea in this case. You really
> just want the profiling software to do this automatically, or at very
> most, a single checkbox that controls the Inhibit interface:
> http://gitorious.org/colord/master/blobs/master/src/org.freedesktop.ColorManager.Device.xml#line312
Very often, profiling solution are offering only TIFF files as 
testcharts, and printing will be done with other applications through 
the standard printing path. For this case, we a an option for the 
"expert user" to disable usage of profiles in p*toraster.


>> If the testchart is printing and measured, the user will assign his
>> individual profile to the Gutenprint setting through the Gutenprint UI. In
>> this case, we need to be shure, that colord gets an update, that for an
>> actual driver setting a new profile has been assigned.
> What's the Gutenprint UI?
I learned, that Gutenprint itself has no UI...
But I still think a future version of Gutenprint should be bale to 
serialize settings with the possibility to assign a profile to a 
serilized setting and to export and import setting including assigned 
profiles.
As such functionalities are quite helpful for the enduser, we will 
probably need somekind of UI to handle such things

>> Richard,
>> if I look at yout workflow. I get an impression, that colord setups
>> p*toraster or foomatic RIP. But I don´t see:
>> - the layer, where the driver tells colord, which profils is assigned to
>> actual driver setting
> CUPS tells colord a "soft" mapping between the linked  icc profile in
> the PPD and the device. The user can specify a "hard" mapping between
> a custom profile and the driver, which is saved in a database by
> colord. If the profile appears on the system, and the device appears
> on the system at the same time, the mapping is applied automatically
> by colord.
>
OK, now I understand, that the PPD is the main source for building the 
UI in CPD or GTK+ Chooser and for telling colord wich profile is valid 
for a setting.

Is it correct, that in such scenario, we need somekind of dynamic PPD 
update, if e.g. the user
- imports new settings in the printer driver with assigned profiles, or
- creates his own profile for a given setting.
- or installes a profile provided from a profiling service for a given 
setting

 From my point of view, PPDs should be used to describe static printer 
parameters like e.g. papertrays, duplex options, maximum printable areas...

Handling of color relevant driver settings and assigned profiles should 
be better handled outside the PPD.


Best regards
Jan-Peter




-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de