Re: Printing with No Color Management (again)
Re: Printing with No Color Management (again)
- Subject: Re: Printing with No Color Management (again)
- From: MARK SEGAL <email@hidden>
- Date: Tue, 26 Apr 2011 16:36:18 -0700 (PDT)
Thanks for trying Chris, and I hope we hear more from you on this as you can
manage it, your time permitting.
How does the imaging community get through the heads of key people at Apple that
they need to correct what they've messed up?
Mark
________________________________
From: Chris Murphy <email@hidden>
To: Forum ColorSync <email@hidden>
Sent: Tue, April 26, 2011 6:43:58 PM
Subject: Re: Printing with No Color Management (again)
On Apr 16, 2011, at 4:51 PM, MARK SEGAL wrote:
> Chris, I'd appreciate if you could unpack some of this for us.
> The Mac OSX printing problem: is this the one whereby disabling colour
>management isn't possible without the Chan or Adobe workaround? Or is there
>something else too?
> "There are other problems with Windows": what are they in the context of making
>prints or processing photos in general?
> What do you mean by a "CUPS" problem - not familiar with the term.
> What is the nature of the "ideological choice"? Why should a system developer
>let "ideology" get in the way or usability? I'm curious about this one.
> You say they want "color management to behave in a certain way". What is that
>way, and how does it differ from the way you would normally want colour
>management to behave? Again curious about this.
> "System is fragile and prone to these printing problems". Fragile in what ways
>- i.e. what does it take to knock it - and by "these printing problems", what
>problems exactly are you referring to - the "no colour management issue", or are
>there others? I'd like to know so I can avoid getting myself into trouble.
> You predict "they" will continue to happen - why? Is it the opt-out method of
>colour management, if so what about it that causes other trouble of what kind?
> There's something ironic about the fact that Apple/Mac was once considered the
>"only" system for proper colour management, and now it appears people may be
>looking at Windows as a less troublesome option for managing a print workflow.
>
OK so I've thought about this for a few days, tried writing a few rough drafts,
and I'm dissatisfied with all of them. I made many assumptions in the posts
complaining about printing reliability on Mac OS, for users who depend on ICC
workflow, and that's why it was as short as it was (and they weren't that
short). So while I'm not beyond a producing a more thorough explanation, with
fewer assumptions about the reader, it then gets really long because I have to
explain things most users have no reason to understand.
"The problem(s)" are all happening at a lower level of the OS than users ever
get near. I might have no choice but to one day undertake writing such a
document. But it misses the real issues:
Printing on Mac OS for professionals/prosumers, who depend on ICC based
workflows is unreliable and inconsistent. Only Apple can make it better. I
refuse the argument this is the tort of Epson, Canon, HP, Adobe, or any other
developer who writes code on Mac OS. These same parties write code on Windows,
and users of ICC based workflows have not had these problems over the same time
period, at all, on that platform.
I think Apple can have everything they want, but merely tweak the opt-out
mechanism such that there is no longer any question that an entire PDF print
spool file's contents are color management exempt.
And for the more technical people who will understand this: Any application that
uses kPMApplicationColorMatching should cause Quartz PDF Context to write out a
uniform PDF Print spool file, and I think Apple needs to revisit the ban on
/DeviceRGB when this SPI is being used by applications that need to use it.
There is nothing gained by banning /DeviceRGB, there's no loss of functionality
to bring it back. But it is a very standard, well tested method to defined
objects immune to color management when directed to the intended output, while
still allowing soft proofing such content.
Conversely, banning /DeviceRGB means routinely even when
kPMApplicationColorMatching is called by an application, ColorSync is behind the
scenes still parsing that PDF to determine null transforms on a per object
basis. That's inherently fragile. I can think of no examples where it's a good
idea for this SPI to function on an object by object basis. The fall out of
which is we continue to have, in my opinion, an unacceptably inconsistent
printing experience on Mac OS X. For at least the past seven years.
Intermittently.
Chris Murphy _______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden