[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!

[Michael Sweet]

On Jun 2, 2011, at 1:07 AM, Alastair M. Robinson wrote:
> Hi,
> 
> On 02/06/11 00:31, Graeme Gill wrote:
> 
>> Choose printer setup -> implies profile.
>> 
>> I suspect the latter is likely to be much more user friendly, since
>> creating profile is non-trivial, and covering every possible printer
>> setup with a profile is likely to be impossible (combinatorial explosion),
>> and unnecessary (the same profile may work OK with many similar setups).
> 
> I disagree - I'm very nervous about having any degree of confidence in a system choosing the *right* profile for any given set of printer options, since as you say, there's a combinatorial explosion and only a handful can possibly be covered.

I am very concerned that everyone seems to be focusing on Gutenprint as an example of a typical driver. It is most certainly not because it provides a HUGE number of settings that are not provided by a typical driver, and most of those settings essentially control the printer (device) configuration and calibration.

Automatic profile selection works just fine for the settings ordinary users are likely to tweak, primarily color mode, media type, and print quality/resolution (thus the defaults used for cupsICCProfile). It makes sense to embed the configuration/calibration settings used when printing a target and generating a profile. It makes less sense that a user might choose a profile they've done previously and then change the driver settings that it depends on.

> Also there's a one-to-many relationship between printer settings and profiles which can't be taken into account by a system that automatically selects a profile from a bundle of settings.  (The system can't know which particular paper I have loaded when several different brands of glossy paper need the same print settings but different profiles.)

Um, perhaps you missed this, but if you have two different kinds of "glossy" media you give then two different names. Aside from the custom option support in CUPS, a profiling application that updates the PPD file to list additional/different profiles could also inject alternate media types matching what was actually used. With two different names you never have a one-to-many relationship but you may have a many-to-one relationship since a single profile may work for multiple combinations of settings.

> ...
> Finally, ICC profiles can be embedded in PDFs using OutputIntent, which makes it (potentially) possible to use profile/settings blobs without having to install anything on the server when client and server are different machines.

You need to be careful about relying on this since PDFs (in particular) get passed around and you don't necessarily  want to use the same profile if you print the PDF a second time, even to the same printer.

Also, whenever you print existing content, that content likely does not contain an embedded profile and thus needs to be handled using some sort of auto-selection mechanism anyways.

Finally, embedding job ticket information in a document raises a bunch of issues on its own: how do you architect a printing environment that can extract embedded job tickets from arbitrary files, what job ticket has priority, and so forth.

> Using the Choose Profile -> Implies Printer Settings paradigm does solve a number of issues and I think it's pretty compelling.


I think having a named preset that selects both the driver settings and profile is a compelling solution. I don't see "pick an ICC profile" as particularly useful or easy-to-use ("what's an ICC profile?")

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair