[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!
rlk at alum.mit.edu
Wed Jun 1 17:50:17 PDT 2011
On Wed, 01 Jun 2011 22:56:46 +0200, Till Kamppeter wrote:
> On 06/01/2011 10:22 PM, Michael Sweet wrote:
>> On Jun 1, 2011, at 1:03 PM, Jan-Peter Homann wrote:
>>> Hello Mike an all,
>>> There is definetely a very import use case for "embedding arbitrary
>>> ICC device profiles into a CUPS raster stream":
>>> We need a mechanism, that the colormanagement in "..toraster" is
>>> synchronized with the driver setup.
>>> Such workflow must include the use case, that the user can download a
>>> printer profile and can easily configure it in his printing environment.
>>> For this use case, the printer profile must have metadata included to
>>> allow a synchronization with driver settings after download. The most
>>> secure mechanism in my eyes is to embed the driver settings directly
>>> into the profile and define a mechanism for handing over the settings
>>> to the driver, when the profile is used.
>> First, if you really are going to use job ticket data from an ICC
>> profile, they need to be exposed as such (as IPP attributes in the job
>> submission). Relying on the document data as the source of the job
>> ticket is a recipe for disaster - you will never get all formats to
>> support it and the data may not be valid for the printer you are using,
>> That is the main reason why we (Apple, and the PWG) push so hard for
>> external job tickets.
>> Second, your use case requires the driver settings, not the profile, and
>> those settings do not need to be embedded in the document data for this
>> to work.
> Now I understand it, the driver only uses the driver option settings
> in the embedded profile, not the color correction LUT. So we can do
> the following:
> The CPD will read the driver option settings out of the embedded
> profile (embedded either by the calling application or by the CPD)
> and set all options appropriately, graying out the options in the
> dialog. If the user clicks print, the settings required by the
> profile are passed along with the job as IPP attribute and so on the
> server they get into the 5th command line argument of all the
> filters. So the CUPS Raster format does not need to carry the color
> profile. The CUPS Raster file is simply the color-corrected bitmap
> with the option settings being supplied to rastertogutenprint by the
> 5th argument.
I think we're talking about a few different things here.
More information about the openicc