[Openicc] printer, driver, CUPS, PPD, printing GUI, ICC-profiles, colord, Oyranos, taxi....

[Jan-Peter Homann]

Hello to all,
being not a developer, I will tray to describe my current knowledge of 
open source color managed printing infrastructure. After an initial 
discussion through e-mail I would ask all participants to help to move 
the results to the OpenICC wiki.

Printer:
- Device for putting ink or other colorants on paper

- Driver:
Software for rasterizing bitmaps, converting it into a printer specific 
format for output and driving the printer and its options (paper tray, 
duplex options....)
- Driver can be delivered from the printer vendor or from other sources 
e.g. the Gutenprint project

- CUPS
Open Source Printing Infrastructure between the application and the 
Driver. CUPS handles e.g.
- Converting output formats from applications (e.g. PS or PDF) through 
filters into input formats for drivers
- describing printing capabilities of a Driver / Printer through the 
ASCII based format PPD
- presenting the PPD informations in the print chooser / GUI to the enduser
- selector for printer ICC profiles based on CUPS qualifiers in in the PPD
- handling printers in an IP based network infrastructure

colord / GNOME Colormanager
- Infrastructure for Device / profile mapping
- interface between profiling application (monitor, printer) and the 
device profile mapping
- targets more standard users and semi professional users
- Relations to GNOME project and Red Hat

Oyranos
- Infrastructure for Device / profile mapping
- Infrastructure for systemwide handling of colormanagement policies
- interface between profiling application (monitor, printer) and the 
device profile mapping
- targets more high-end users but also standard and semi professional users
- Relations to KDE and OpenSuse


Taxi
- Online Database for ICC-profiles containing DevieMapping informations 
and a selection process for finding ICC-profiles based on Device 
informations.
- Currently handling only monitor profiles, but could potentially 
handles also printer profiles
- Realtions to Oyranos


**************************
Known issues in the profile / device mapping process for printing

The CUPS PPD concept is a quite static concept for describing the 
capabilities of a driver/printer combination. CUPS has e.g. not defined 
a process how a PPD could dynamicly be updated with additional entries 
for media types, correlated drivers settings and associated ICC-profiles.
There are options to use the commandline to pass informations about e.g. 
media types, correlated drivers settings and associated ICC-profiles 
through CUPS to filters or drivers. But using this way, the printing 
GUI, which presents the entries from the PPD is normally bypassed.

Both colord / GNOME colormanager and Oyranos have a basic infrastructure 
to work with CUPS and provide a link to the printing GUI / print choose. 
(correct ?)
Concerning new printer profiles, colord / Gnome Colormanageg has a focus 
on profiles which are generated inside the solution. Importing printer 
profiles with embedded metadata for profile device matching and links to 
the printing GUI is currently not implemented.

Oyranos has a basic infrastructure for printer profiles with embedded 
metadata for profile device matching and links to the printing GUI.

 From my point of view, I see follwoing point for further discussions:

1) Should the complete printing GUI for the enduser should be always 
generated from the PPD ?
(If yes, we need a process for first updating the PPD with entries for 
additional mediatypes and mapped ICC profiles)

2) Should there instead be a stripped PPD without any informations for 
mediatypes and mapped ICC profiles ?
(In this case we have to define how the printing GUI is constructed and 
how the user decision from the printing GUI are injected into CUPS

3) Should we have the possibility of embedded low level driver setttings 
into the printer profile ?
Especially in the professional area, it is a typical task, that low 
level driver settings (e.g. per channel ink limit, per channel 
linearization curves) are optimized before a testchart is printed. The 
embedding the low level driver settings e.g. as driver specific 
XML-file) delvires a "bullet proof" mapping of the driver setup and the 
printer ICC profile. If only high level metadata are embedded in the 
profile (e.g. CUPS qualifiers for mediatype and resolution) we have to 
define a process that makes secure that driver settings during profile 
generation and profile application are always identical.
If we choose the option of embedding low level driver settings into the 
ICC-profile we need a mechanism, that also the needed informations for 
the printing GUI (e.g. mediatype names and resolution) are part of the 
embedded metadata. We also need a process how the data for the printing 
GUI are used to dynamicly update the entries in the printing GUI after 
the ICC profile have been installed.


****

Hope for further discussions

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