[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!
Kai-Uwe Behrmann
ku.b at gmx.de
Thu Jun 2 02:12:12 PDT 2011
On 02.06.2011 10:20, Till Kamppeter wrote:
Seems I missed Alastairs post.
> On 06/02/2011 10:07 AM, Alastair M. Robinson wrote:
>> I disagree - I'm very nervous about having any degree of confidence in a
>> system choosing the *right* profile for any given set of printer
>> options, since as you say, there's a combinatorial explosion and only a
>> handful can possibly be covered.
>>
>> Also there's a one-to-many relationship between printer settings and
>> profiles which can't be taken into account by a system that
>> automatically selects a profile from a bundle of settings. (The system
>> can't know which particular paper I have loaded when several different
>> brands of glossy paper need the same print settings but different
>> profiles.)
Thats the perfect use case to have a profile selector in the UI.
>> For a long time we've wanted a way of bundling up a settings blob with a
>> colour profile for easy distribution. The profile meta tag gives us that
>> ability if we play it right.
Its IMO a great change to make colour management "just work". The
printing GSoC project aims at that with Oyranos.
>> Having the printer settings bundled up into a single object should
>> vastly reduce the number of printer options that have to be exposed to
>> the user, which should please the usability-over-usefulness folks.
At least many options should be grayed out depending on the profile.
After removing that profile from the actual job the options can be
enabled again.
>> Finally, ICC profiles can be embedded in PDFs using OutputIntent, which
>> makes it (potentially) possible to use profile/settings blobs without
>> having to install anything on the server when client and server are
>> different machines.
As Mike and Till have explained and Hal agreed, we will need to modify
the print options at print submission.
Compared to Xorg it is the same. The calibration is inside the profiles
VCGT tag, but applied separately. The CMS has to take responsibility to
apply the calibration during profile setup.
I think with sending print options, it's similiar to setup of VCGT for
monitors. Both handle calibration, both are located in the ICC profile
(VCGT/meta tags), boths calibration get applied independent from the ICC
profile. On Xorg and in print systems we do not want to get calibrations
applied several times. While the Xorg calibration is pretty persistent
during a session, a print calibration is a job by job thing through the
flexibility of PPDs. Buts thats a mere technical difference.
The logical desire is to have the calibration fixed shortly after their
user interaction and modification. That decission should condense in
architecture to make the system work as expected.
In contrary, giving the calibration setup to a automated step inside a
CUPS raster filter looses control on that. Arbitrary automatisms can
then happen. The system had then to decide about potentially conflicting
calibration settings from IPP and ICC and that likely far away from any
user control. This can render dangerous for the robustness of a print
architecture like CUPS.
In my opinion the logical place to setup the calibration is there the
options are selected. Thats the print dialog or print command. Thats
transparent to users and quite intuitive.
>> Using the Choose Profile -> Implies Printer Settings paradigm does solve
>> a number of issues and I think it's pretty compelling.
>
> To prevent the user from the situation that he has to choose color
> profiles (and know what that is) instead of printer options or that he
> has to be lucky to have chosen the right combination of options to get
> color management applied (note that we then get bug reports as "I have
> changed one little parameter and colors got totally different") we
> need to assure that for all presets (set of settings defined with
> "*APPrinterPreset" keyword in the PPDs, like "Photo", "Office
> Document", ...) are covered with a color profile (to be created by
> printer manufacturer/driver supplier). Then if
Ah. So it makes sense to embedd the "APPrinterPreset" key in the
profile. Then a user can select "Photo", "Office Document", ... instead
of a ICC profile name.
> the user uses the CPD only in level 2 (only presets, not individual
> options visible,
> http://wiki.openusability.org/wiki/printing/index.php/Dialog_Levels)
> he gets always color-managed printouts.
Interessting idea.
kind regards
Kai-Uwe
More information about the openicc
mailing list