On Apr 27, 2011, at 6:18 PM, Graeme Gill wrote:
> I would speculate that the issue is that to one or more influential people
> in Apple, the idea of the null transform is "golden/neat/cool" etc., and
> the idea of an anything else is seen as "an ugly hack",
Yes, I agree. But I also think they don't really understand that what an ugly hack is, or they'd realize the multitude of ugly hacks they have already rolled into Mac OS X to make this function the way it does. It is, in effect, a Rube Goldberg contraption that does goes to extremely unnecessary and complicate lengths to do a straightforward thing, and then regularly fails to reliably print profile targets or prematched content.
Telling people the present architecture "works as designed" is pretty hilarious because in effect it's a statement that Apple thinks that having the most unreliable printing architecture on the planet for professionals who depend on ICC workflows, is either something Apple intended to provide us in advance, or the fact that's how it has turned out is something they don't have a problem with.
Either way, I am supremely impressed. Just not in a good way.
> I personally have always thought that the idea of using the null transform
> as a way of conveying the intention needed for profiling is technically
> flawed. It's flawed because there _is_ a difference between saying
> "this colorspace is XYZ", which happens to be the same as
> that of the device it is being sent to at some instant in
> time or configuration or workflow, and saying "this colorspace is always
> the same as the device it is being rendered on", something that
> remains true irrespective of time or configuration or workflow. The
> latter truly conveys the required intention, rather than it being
> a side effect, and is therefore robust.
> I like robust. It causes fewer problems.
You and I are totally on the same page. I have made these arguments before. We know /DeviceCMYK instead of null transform dependency works because we never have problems with ColorSync involving itself when we don't want it to with CMYK devices, only with RGB output devices, and I propose it's due in large part because /DeviceRGB was banished (along with an SPI that's immature and poorly documented).
> [Apples reluctance to even publish the current "correct" way to
> turn off color management is remarkable. It certainly isn't
> helping the situation at all. I guess I'll just have to
> figure it out the hard way...]
Don't take it personally. Of all the companies you'd think Apple would have been pro-active in informing what SPI (or API) to use, it would be the companies that produce apps that print profile targets. From my testing thus far, NONE of them are using kPMApplicationColorMatching and I would not be surprised if none of them has ever heard of it because it's not a public API. You have to know about it, to ask about it. And I think that's fakaked.
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