[Openicc] colord 0.1.9 released - CM Framework - Printer Driver
homann at colormanagement.de
Mon Jun 20 05:14:27 PDT 2011
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).
- What would be the amount of work for the Gutenprint team to queue
colord for the driver setup of a given printjob ?
- 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 ?
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:
>> 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
>> 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.
---------- 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
More information about the openicc