[Openicc] - CM Framework - Printer Driver - output intent

[Till Kamppeter]

On 06/20/2011 07:46 PM, Richard Hughes wrote:
> On 20 June 2011 17:56, Jan-Peter Homann<homann at colormanagement.de>  wrote:
>> Richard,
>> What do you think about Hal愀 proposed workflow for transporting the driver
>> settings as part of the CUPS printing stream ?
>
> I think if a PDF has an embedded output profile, then we should use
> that instead of querying colord.
>
> Richard.
>

Why not letting the CPD doing the following:

The preset menu shows the following presets:

1. All defined by APPrinterPreset keywords in the PPD file
2. One for each locally available ICC profile which has driver settings
    embedded
3. An additional "Embedded profile" entry if the PDF input has a color
    profile with driver settings embedded. This is always set to be the
    default if present

If the user chooses the "Embedded profile" entry (3), the profile stays 
in the PDF, if he chooses one of the local profiles (2), this profile 
gets embedded and if needed, the currently embedded profile removed. If 
he chooses a preset from the PPD (1), no profile gets embedded. If the 
user selects individual settings, a profile gets only embedded, if the 
settings match the driver settings of one of the profiles.

If CUPS receives a job with embedded color profile, the embedded profile 
is used. Otherwise it is checked whether a color profile linked in the 
PPD file matches with the driver settings as defined in the PPD and then 
that profile gets used.

The option settings are set to the settings embedded in the profile when 
(2) or (3) is used. These settings are then sent to CUPS as IPP 
attributes, like settings which the user selects manually in the dialog. 
So all filters including the printer driver (rasterto...) get the 
correct driver settings. So there is no need to embed a color profile in 
CUPS Raster data.

    Till