[Openicc] colord 0.1.9 released - CM Framework - Printer Driver

[Jan-Peter Homann]

Hello Richard and all,
As I´m not a developer, I still have to learn about the communication 
between the CM Framework and CUPS, ..toraster printer driver and so 
on... (e.g. about the differences of sendind and queuing...)

I agree, that the CM Framework should not need to know the details about 
driver setup. It would be just enough, if it provides one XML-file for 
the driver (e.g. Gutenprint).

Richard:
- What would be the amount of work for the Gutenprint team to queue 
colord for the driver setup of a given printjob ?

Robert:
- Do you think it would make sense to queue colord for getting the 
driver setup in a color managed print pipeline ?
- If not, what would be you preferred alternative to synchronize printer 
profile and driver setup ?

Best regards
Jan-Peter




Am 20.06.11 14:00, schrieb Richard Hughes:
> On 20 June 2011 12:47, Jan-Peter Homann<homann at colormanagement.de>  wrote:
>> I would recommend, that we include following data as ICCdictype metadata
>> into ICC printer profiles
>> - CUPS qualifiers for
>>     - mediatype
>>     - resolution/quality
> Yup, I already added MAPPING_format and MAPPING_qualifier in the last
> release of colord:
> http://gitorious.org/colord/master/blobs/master/doc/metadata-spec.txt
>
>> The role of the CM framework (g-c-m / colord or Oyranos) would be to be
>> 1) installing of new printer profiles into the system
> Right.
>
>> 5) send information to gstoraster for the printer profile according print
>> chooser selection
> Well, it's up to gstoraster to query the color profile to use from
> colord for the given document qualifier (qualifier = RGB.Glossy.600dpi
> for example).
>
>> 6) send information to driver (e.g. Gutenprint) about the correct driver
>> setup for the printjob
> Again, what data needs to be sent to gutenprint? Can't gutenprint just
> query some metadata value itself from the colord profile? So we embed
> some kind of GUTENPRINT_gamma_curve=<xml><foo/></xml>  either into the
> ICC profile DICT tag, or onto the colord virtual profile instance, and
> then just extract that in gutenprint?
>
>> Could you please comment especially the point 3) and 6) from your
>> perspective. Doy you plan to integrate such functionalizy into your CM
>> framework, or do you would prefer another workflow for synchronizing printer
>> profile selection and driver setup ?
> I think it makes a lot of sense for the CMF to stay a device and
> profile registration framework, and let the users (gstoraster, cups,
> etc.) just add metadata where required. I don't actually think it's a
> good idea for the CMF to understand all the GUTENPRINT_gamma_curve
> type data at all. It's just profile metadata that happens to mean
> something to gutenprint.
>
> Richard.
>


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