[Openicc] Google Summer of Code 2009: Oyranos CUPS backend

[Hal V. Engel]

On Monday 17 May 2010 02:12:10 pm Chris Murphy wrote:
> On May 17, 2010, at 11:24 AM, Hal V. Engel wrote:
> > It is clear that the printer vendors (at least some of them) are aware of
> > the need for more than a single profile for each printer.  In addition,
> > it is common for third party media vendors to supply semi-custom profiles
> > for various media/printer combinations.  So there is a need to
> > accommodate these vendors profiles as well as custom user created
> > profiles.  Clearly this is not a simple problem and it is not amenable to
> > simple solutions.
> 
> I like the model Apple has used on Mac OS X, I just wish it was more
>  thoroughly documented in a transparent manner so developers knew what they
>  needed to do. It appears to be too complicated for the amount of
>  documentation they're willing or able to provide.
> 
> The gist is that the driver has a list of media types, which primarily
>  control ink limits,  and black generation. The OS is made aware of these
>  media type settings (print conditions if you will) and allows a profile to
>  be registered for each of those media type settings. This allows that
>  profile to be automatically chosen whenever the user simply specifies the
>  proper media type, without then also having to go find and choose an
>  appropriate ICC profile for the print condition.

This is handled mostly by CUPS using the cupsICCProfile settings in the PPD 
file.

> 
> If there's an advantage to cupsICCProfile, it's that it is already used by
>  most manufacturers producing print drivers for OS X. So the less work they
>  need to do to get their drivers working on Linux, the greater the native
>  support we'll see.

This is clearly the path of least resistance.  But it may not yield optimal 
results.

> 
> > As a result either we use the PPD to configure custom profiles which
> > currently has many issues or we come up with another system to handle
> > profile management for printers and integrate this with CUPS (IE. by pass
> > the PPD totally for color management).  I actually favor the second
> > approach since the PPD system is so inflexible and has so many issues
> > with regard to color management.
> >
> > I also have concerns about directly embedding profiles into the PPD.  PPD
> > files are currently fairly small.  The ones on my system are between 46K
> > (guten print HP500) and 600K (guten print Epson R2400) in size.  Once we
> > start embedding profiles into these their size will explode.   After all
> > in some cases the vendors have 5, 10 or more profiles for each printer
> > model.  Looking a Chris's example embedding these profiles would increase
> > the size of the PPD by over an order of magnitude.  Since many
> > installations use remote print servers this means that this will result
> > in a significant increase in network traffic since apps using the printer
> > will need to get the PPD in order to function correctly.   Even those
> > apps that do not care about color management will cause this traffic
> > increase when the user opens the print dialog.
> 
> These two might be solved with URI based cupsICCProfile which can point by
>  default to some installed local location for the profile (which is what's
>  done on OS X). 

This can be done currently on Linux (or other Unix) CUPS servers and work 
stations if the server admin adds a sym link to the correct location on the 
server.  Then workstation apps can use the CUPS API to retrieve the profile(s) 
as needed.  The current Oyranos CUPS code supports this but the only place 
where the sym link is documented is in the OpenICC GSoC email list since at 
the time this work was done this was thought to be temporary.  There is also 
an open enhancement request in the CUPS tracker to make it so that server 
admins do not have to create the sym link for this to work.  I don't know the 
status of this tracker item.
 
>  And then for remote printing, the PPD is modify on-the-fly
>  when sent to the remote machine, substituting the proper URI for the
>  profiles on the host machine. 

Again the CUPS API supports this already without the need to modify the PPD on 
the fly if the print server has the correct sym link.
 
>  Then hopefully the way CUPS and the APIs
>  responsible for drawing the UI, don't actually need to download all
>  available ICC profiles referenced by URI, except when a transformation is
>  requested (i.e. for remote printing, presumably the only time the profile
>  is needed is when soft proofing in advance of printing).  This would give
>  the user access to all 12 (or 24 or whatever) profiles for the printer,
>  but they wouldn't all have to be downloaded all at once, and VERY likely
>  not a single one would ever be used because most users don't soft proof.

For the vast majority of users this would be the case.  In addition, by 
inspecting the cupsICCProfile items in the PPD file the user land app should be 
able to figure out exactly what profile to use if the user requests a soft 
proof.   In fact this should be part of the Oyranos API I think since that 
would make it simple for apps to request a proofing profile since they could 
pass Oyranos the media type resolution  and color model and it could pass back 
a handle to the correct profile.  Of course, it has been pointed out that the 
cupsICCProfile setting only allows for three conditions for the selection of 
the profile one of which is always the media type.  But as you point out this 
is all derived directly from what OS/X does.

The other CUPS issue related to this is that currently there are no open 
source *toraster filters that support color management.  The only platform that 
has color management aware *toraster filters is OS/X.  There is work underway 
on this at least for the PDF based printing work flow and hopefully this will 
be fixed sometime soon.

Hal