[Openicc] colord Printing Plans, CPD and Gutenprint role of PPD

[Kai-Uwe Behrmann]

Am 01.03.11, 00:22 +0100 schrieb Jan-Peter Homann:
> Hello Edmund,
> My interest in this discussion is to establish a transparent workflow for 
> colormanagement from document ICC profile to driver setting ICC profile.
>
> I believe, that solutions like e.g. Oyranos or colord could deliver a 
> communication layer between the colorsettings of the document which is been 
> printed and the actual printer driver setting.

Agreed, a CMS like Oyranos ,and colord might go that route as well, can be 
used to extract calibration settings from a profile to configure the 
device driver. That is successfully done since years for display colour
management.

> I´m fed up with the color infrastructure of Mac OSX, which I´m using since 20 
> years. I also don´t see that the ICC itself, will define such a transparent 
> color infrastructure, because obviously important ICC members like vendors 
> for operating systems or closed source printer drivers have no interest to do 
> this.
>
> I believe, that the OpenSource community has the potential to solve this 
> puzzle and to create an ecosystem of printer drivers, applications and a 
> colormanagement framework, which could lead to similar results under LINUX, 
> Mac OS X and Windows (inside the ecosystem..)
>
> I think 3 to 5 years to reach this goal is quite optimistic but possible...
>
> On the other hand, I´m learning that taking part on OpenICC as a enduser / 
> consultant is sometimes quite time consuming and leads to 
> missunderstandings...

I found it great you to start writing down your ideas on the wiki. That 
certainly helps as a reference and might lead to general recommendations 
in the future.

> E.g from my perspective, it is 100% clear, that driver settings and assigning 
> profiles to a driver setting is best done in the driver and than communicated 
> from the driver via the "color infrastructure layer" like e.g. Oyranos or 
> colord to the place where the color transform  takes part.
>
> 1) Create a driver setting
> 2) Assign a profile to the driver setting in the driver
> 3) make the driver setting choosable in the printing GUI (e.g. CPD, GTK+ 
> Chooser or individual UI)

This is the point where Oyranos has choosen to do other. (Richard 
subjected as well.) The Oyranos CUPS module links against libcups to parse 
PPD's and do other nice stuff (or should I write cool?). It is almost the 
same as doing this inside CUPS. The same for Gutenprint settings. If the 
calibration data is exported and serialised, they can be embedded into 
profiles and other wise transported to the UI layer for device 
calibration. Gutenprint needs not to get involved.

Developers often prefere a hierarchical order of components. So, burdening 
CMS tasks to Gutenprint like colour conversion including all settings and 
profile extraction is from a architectureal point of view not useful. E.g. 
hplib would need to repeat that stuff and others as well. So its nice to 
have things collected, where many components can benefit from.

> 4) Deliver a mechanism, that the assigned profile of the choosed setting is 
> communicated via Oyranos / colord or whatever to the engine where the color 
> transformation from document ICC to printer ICC is done.

PDF and a job ticket would IMHO ideal as transportation mechanisms. It is 
clearly bound to the task at hand, neutral and preexisting. As PDF is a 
ISO standard Linux is well served to support that anyway.

> It seems, that I´m not able to explain or convince the developers here, that 
> this way makes sense...

I think we are almost in line with most goals. (Except of proofing in 
version 1.a versus non expert users first;)

> On the other hand, the developers at OpenICC , seem to prefer some ways, 
> which I don´t understand
> - the magic of CUPSicc...

Vendors deliver already PPDs for their printers. Its straight forward to 
deploy that existing mechanism. CUPS supports it already. The missing glue 
to Ghostsript and Poppler was the according pdftoraster filters. This will 
provide a improved out of the box experience once canned vendor profiles 
are shipped with the drivers. Till, Mike and others have done a great job 
around that. It is IMO pretty useless for user settings as it does not 
support much of calibration options. Hence we had criticised that in 
the past in that context. But for canned profiles its simple and good 
enough.

> - the magic of a fuzzy match through Oyranos

It is designed to automatically select the right profile. In contrast most 
systems support only to firmly assign profiles to devices. To divide into 
automatic and manual set profile there needs to come meta data into play, 
which is IMO not very clever.

The good part for experts and power users is, the fuzzy matching for 
implicite selected profiles is second grade after a manual and thus
explicite profile selection inside a GUI. So it can easily be overridden 
by users and do not interfere.

> Hopefully I learn through the mailinglist, to fix the obvious communication 
> problems between me and the developers here...
>
> Edmund,
> Did you understand now more my interest in the discussion ?
>
> Best regards
> Jan-Peter

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