[Openicc] - CM Framework - Printer Driver - output intent
homann at colormanagement.de
Tue Jun 21 01:44:43 PDT 2011
Hello to all,
lso Till supports the idea of Hal to send the driver settings as CUPS
IPP attributes. If also Mike Sweet would agree, that this is a good idea
than we may should integrate this recommendation somehow in the CUPS
specification / documentation ?
This solution would make it obsolete, that Gutenprint should query any
CM Framework as you whished
Do you have any idea, how in the g-c-m / colord environment, printer
driver metadata of the valid ICC-profile of a print job are extracted
from the ICC-profile and integrated in the CUPS print stream as IPP
- Which tool has to this job ?
- What would be part of colord in the workflow ?
Questions about CPD and PDF with Output Intent:
Am I correct, that CPD provides an GUI for the creation of print spool
If yes, the actions in the CPD dialogues control how PDF print spool
files are generated, and if the printer profile will be embedded as
output intent into the PDF print spool file.
Thinking about possible dialogues for such cases makes sense, when
applications will be able to work with ICC-profiles on object-level and
when the toolkits for PDF print spool file creation will be able to
honour the ICC-profiles in objects from the applications and add an
Output Intent to the PDF print spool file.
Currently, both on application level and on toolkit level for PDF print
spool file creation, we are far away from such kind of ICC support.
At the current stage, I would recommend, that we concentrate on
workflows, where the print spool PDF are DeviceRGB and "..toraster" is
doing a color transformation from sRGB to printer profile specified
through CPD according qualifiers, which are embedded into the installed
printer profiles in an user environment.
Am 20.06.11 20:12, schrieb 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>
>>> What do you think about Hal愀 proposed workflow for transporting the
>>> 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
> 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.
---------- Please note the new adress --------------
homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de
More information about the openicc