[Openicc] - CM Framework - Printer Driver - output intent
till.kamppeter at gmail.com
Mon Jun 20 11:12:04 PDT 2011
On 06/20/2011 07:46 PM, Richard Hughes wrote:
> On 20 June 2011 17:56, Jan-Peter Homann<homann at colormanagement.de> wrote:
>> 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.
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
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.
More information about the openicc