[Openicc] Color Management for Ubuntu

[edmund ronald]

On Tue, May 3, 2011 at 11:00 PM, Ann McCarthy <almccart at lexmark.com> wrote:
> Thanks for the good example Edmund.
>
> So the scenario you are describing is 'printer profile already applied -
> don't do it again'.
> In your experience, have you found sufficient workflow hooks are in place to
> handle avoiding applying the printer profile in the box when printing to a
> printer that has an in-box RIP/CMM?  Or perhaps you have not tried it with
> that kind of system?
>
> Anyway -- this scenario should be handled under the basic rule of CM which
> is: "if the source profile of the content matches the profile of the
> destination THEN do not re-apply the destination profile." In my view an
> intelligent CMM should always apply that rule. So that is why I did not list
> it as a case of 'turn color management off'.

Ann,

Not so. At the time of assembling a composite of profile tests, I am
working in devicespace, and do not have a profile in place on the
system for the device being tested.

I am saddened by the fact that you are falling in the Apple trap of
"We know best". If I want to bypass the whole profiling mess, I want
to bypass it, and I probably know why, and once I say so I would like
to decisively bypass any second-guessing by the CMS or CMM, however
smart or brilliant the intergalactic CMM spaceship may be feeling on
that particular day :).

And no, I am not a user of RIPs. But I used to be vendor-qualified by
a RIP manufacturer, and during training it was explained to me that
distributors for large-format production RIPS consider profiling to be
a tool for paper-vendor lockin, and therefore the distributors
explicitly want profiling and profile changing and indeed paper
configuration to be made as difficult as possible for the RIP end-user
(in the contract printing context.)

Edmund