[Openicc] Assigning ICC profiles to pinter driver settings part 2

[Hal V. Engel]

On Wednesday, January 19, 2011 02:50:48 pm Jan-Peter Homann wrote:
> Hello list,
> After reading the mails in the list, I´m currently not convinced, that
> the OS level configuration like Oyranos or colord is the best solution
> for assigning an ICC profile to printer driver settings.
> 
>  From my personal experience I rather would prefer a solution where it
> is possible to assign an ICC profile directly in the printer driver
> provide an interface to make the ICC profile for the current active
> setting available to to services / applications sending raster-data to
> the printer driver.
> 
> This would allow e.g. following use cases
> 
> 1) predefined standard settings with canned profiles
> The printer driver is delivered with canned profiles and the user don´t
> changes anything during daily work

This is supported by the current CUPS architecture although CUPS needs open 
source CM aware *toraster filters to fully support this on non-OS/X systems. 

> 
> 2) predefined standard settings modied from the user
> The canned profiles for a standard setting are used, but the user has
> changed settings like e.g. enhancing contrast brightness or saturation.

Again this is a variation on the above and the user can currently tell the 
driver to behave in a non-default way such as increased contrast or 
saturation.  Once CM aware filters are in place for CUPS this should also work 
although there are some issues that need to be resolved.  For example the 
current PPD files appear to only have OS/X centric CM settings as none of the 
file paths used in the PPD files exist on most *nix machines.

> 
> 3) individual profile from the user
> The user can print a testchart without application of a color
> transformation and assigns the resulting profile directly in the driver
> setting.

Of course printing a test chart now works but at the point where there are CM 
aware filters in CUPS this may no longer work unless the user knows what 
printing path will bypass CM.  For example, if the PDF work flow is CM aware 
but the pure raster work flow is not a test chart could be printed by using a 
pure raster work flow.  But this is at best a kludge that should be avoided.

In addition the current CUPS design does not really support user supplied 
profiles on the print server side so this implies early CM binding on the 
client side (perhaps in the CPD?) and then by passing of CUPS level CM.  This 
is a fairly ugly solution and I think we can do better. 

> 
> If a profiling service is triggered directly from the driver, it is easy
> to integrate the driver settings into the ICC-profile as metadata for
> documentation and troubleshooting.

At present there are no drivers (as this would generally be defined by most on 
this list) in the open source domain that know anything about applying ICC 
profiles.  But I remember a very early thread where there was some disagreement 
about just what constituted a printer driver and some would include things 
like the *toraster CUPS filters in their definition of a printer driver well 
most here would only include the printer specific code.

Currently I don't think that most of us are expecting to push CM down to the 
level of the actual printer driver and I think most everyone wants to have 
this functionality at a higher level in the software stack.  This will allow 
it to be implemented in one place which will make things simpler for everyone 
and also more consistent for everyone including users assuming it is done 
correctly.  

> 
> 
> 4) Where to apply the color transformtion from source colorspace of the
> rasterdat to the target device colorspace of the printer driver setting ?
> I don´t know if CUPS has mechanism for pulling a ICC from the driver. If
> yes, CUPS would be ricght place.
> If not, we have to discuss if CUPS should be enhanced with such
> functionality or if CUPS delivers only with rasterdata with an ambedded
> source profile (and may be a rendering intent) and the color
> transformation of raster-data is handled also in the printer driver.

CUPS has a lot of the needed hooks to do this but is currently missing open 
source *toraster filters that are CM aware.  With the recent release of 
GhostScript 9.0 it appears that we now have the major pieces needed to create 
a pdftoraster CUPS filter that will properly support CM.  Since these filters 
are relatively simple it shouldn't take too much effort to implement an open 
source CM aware pdftoraster CUPS filter built on top of GS 9.  I fact it should 
be possible to extend the current GS based code to support CM.

The current CUPS mechanism for "pulling a ICC from the driver" (using "driver" 
very loosely) is to use settings in the PPD file that contains mappings from 3 
driver settings to an ICC profile.  This, of course, is clearly not a solution 
that is generally acceptable to this group.  The printer parts of Oyranos and 
colord are attempts to build a more flexible and powerful system for managing 
the ICC profile to printer settings mapping on top of CUPS.

> 
> 5) Whats about PDF printing data ?
> PDF allows individual profiles for individual objects and also the
> definition of a global document colorspace (Output Intent).
> The PDF2Raster engine would render all individual objects colors
> including transparencies to a flat raster file and embeds the output
> intent into the raster file.

Again GhostScript 9.0 appears to give us what we need to implement a solid CM 
aware pdftoraster CUPS filter.   Linux and other open systems are moving away 
from a PS centric printing work flow towards a PDF centric printing work flow.  
Some recent distros are using the new PDF based printing work flow now and it 
is only a matter of time before this is used every where on *nix systems.  If 
the only CM aware *toraster CUPS filter was the pdftoraster filter we would be 
well on our way to having a working system level CM aware printing system 
although there is likely some work needed at the application level to make 
sure this is universally supported and, of course, we need to have something 
like Oyranos or colord to augment CUPS functionality.

> 
> 
> It would be nice to get some comments on the described workflow
> 
> 
> best regards
> Jan-Peter