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

[Chris Murphy]

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.

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.

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

Chris Murphy