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

[Michael Sweet]

On Jan 18, 2012, at 9:21 AM, Kai-Uwe Behrmann wrote:
> ...
> This is fine for selecting existing ICC profiles for well supported media. We want to create new ICC profiles for unsupported media, which likely need new driver calibration settings, as Robert and Edmund pointed out.

NOTE: IPP Everywhere DOES NOT DEFINE IMPLEMENTATION DETAILS SUCH AS "DRIVERS".  In fact, the whole goal is to eliminate drivers and have "smarter" printers.

So, if you have a new media you want the printer to advertise, you use Set-Printer-Attributes to register it with the printer, just like for profiles.

As for the media characteristics and calibration data, these are highly device/implementation-specific.  The best I can see us doing is to define a naming convention for custom media types that allows a client to say "use the media characteristics and calibration data for vendor media type foo", e.g. "custom-user-media-type-name_photographic-glossy" would tell the printer to use the same linearization curves as "photographic-glossy".  This is effectively what most users do today anyways, but would allow the profile and media selection to use a user-defined media type to prevent user error.

> Part of this is to know, which driver attributes set the changed calibration for the new profile. Otherwise clients are highly uncertain on calibration state and custom ICC profiles are more error proune.

IPP Everywhere does not address how an implementation will provide a managed color workflow, it just provides the current list of profiles and job template attributes supported directly by the printer and how they interact (i.e. which job template attribute values cause a profile to be selected).

> To nail it down I want to provide a scenario:
> * A hobby photographer wants to experiment with drivers and has bought new
>  media which he can not find a profile for.

Client uses Set-Printer-Attributes to define a new custom media type based on the characteristics of an existing media type, and to define a new ICC profile that is selected when that media type is used.

> * Here profiling software gives advice how to get to a proper
>  calibration state, like smooth colour ramps and so on by tweaking
>  colour related driver settings.
> * The profiler has no knowlege of the exact colour attribute names. * After printing the target she measures the target and the profiler
>  creates a ICC profile.
> 
> In the actual IPP standard she has no means to automatically associate the new calibration state for here alternative media and driver with the ICC profile. She wonders, why she must select all colour related options manually and hopes to have got it right.

No, her client software "uploads" the custom media type and profile to the printer along with the job ticket that was used to print the target image(s).  Later, her client software can query the printer to get the list of available profiles and media types - either she picks the profile and those job ticket attributes are chosen for her automatically (and not changeable?) or she picks the media type which causes the profile to be selected automatically.

> ...
> I hope to could make myself clearer, why I think, it would be a good thing, that printers can advertise additional meta data.


I hope I am getting the message across that such additional meta data is unnecessary - both the "pick the right profile based on the options" and "pick the right options based on the profile" are supported by the current proposed attributes in IPP JPS3.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair