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

[Kai-Uwe Behrmann]

Hello,

my comments are below ...

Am 13.01.12, 12:05 +0100 schrieb 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

Till, please correct me,
CUPS plans to move from primary PPD to IPP Everywhere deployment with the 
release 1.6 .

> 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

There are no pitfalls for single groups. :-)

> - Relations to KDE and OpenSuse

Let me point out that Oyranos is as well available in several other 
distributions and receive patches from these projects. Oyranos CMS and 
its tools are useable inside all Desktop Environments including Gnome. 
However the most advanced GUI is indeed integrated inside KDE.

> Taxi
> - Online Database for ICC-profiles containing DevieMapping informations and a 
> selection process for finding ICC-profiles based on Device informations.

The selection process happens on client side. Taxi provides the meta data 
in its DB for this to happen.

> - Currently handling only monitor profiles, but could potentially handles 
> also printer profiles

Taxi itself does not do any matching or selection:

- Currently containing only monitor profiles, but could potentially
   contain also printer profiles

> - Realtions to Oyranos

... and Taxi is naturally open for all CMSs and OSs :-)

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

Thats a potential place for confusion. IMO the GUI should handle print 
settings and profile selection in a combined manner. That's how many 
vendor GUIs do this already, even if very restricted.

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

For parts of the printing UI thats fine. Other parts will surely be 
customised.

> (If yes, we need a process for first updating the PPD with entries for 
> additional mediatypes and mapped ICC profiles)

Can you name to us some examples where PPDs are changed on the fly?

> 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

There are cases, where PPD options need to be changed by profile meta 
data, in order to reach the calibration state as used during profiling.

> 3) Should we have the possibility of embedded low level driver setttings into 
> the printer profile ?

Yes, XCPD goes this route:
http://jsimon3.wordpress.com/2011/08/23/gsoc%E2%80%9911-update-%E2%80%93-final/

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

Not sure how to reach that goal. The usual way in vendor GUIs is to look 
allow only a reduced set of changeable options if at all and associate a 
ICC profile with it.

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

The option names and choices come currently from PPD files. In case of 
settings coming from the profile meta data, the according PPD options 
should not be fixed. Others are not needed to be displayed at all in 
standard GUIs. Of course ICC profile selection should affect options. If 
options are preselected then the available ICC profile list should be 
sorted according to best matches. The need to change options after profile 
selection could be marked inside the profile selection list.

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