Re: Printing with No Color Management, Apple and X-Rite
Re: Printing with No Color Management, Apple and X-Rite
- Subject: Re: Printing with No Color Management, Apple and X-Rite
- From: Chris Murphy <email@hidden>
- Date: Thu, 14 Apr 2011 18:02:13 -0600
On Apr 14, 2011, at 3:59 PM, John Gnaegy wrote:
>
> Printing bypassing the printer driver is something both the application and the driver need to be written to support on 10.6 and later. As you all know you can print from Photoshop sending the data directly to the printer with the "Photoshop manages colors" option, Apple worked with Adobe to implement that. The thing is the driver has to do the right thing too. Aperture can also do this, and in Lion so can ColorSync Utility, again if the printer driver supports it
1.
ColorSync is a constant party crasher, even when explicitly uninvited to the party. That is the problem. And even when the print driver is working correctly.
2.
InDesign does not use the private SPI that both Lightroom and Photoshop depend on to enable the automatic setting of the proper ("off") mode in print drivers, when using application color matching. And guess what? InDesign has never had any of the particular problems that Lightroom and Photoshop have had with respect to color when using this SPI. We have enough problems with kPMACP causing problems with Lightroom and Photoshop PDF print spool files being malformed, I'm convinced the SPI is incompatible with more complex applications like InDesign, Illustrator, and many others that produce more than one object in a PDF print spool file.
3.
Let's pretend for a brief moment that these problems aren't Apple's, but rather are the fault of print drivers lacking some kind of support. Why would Apple persist in maintaining an architecture that requires an incompetent print vendor to do the right thing when they haven't consistently done the "right thing" for 7-8 years? It seems rational to conclude it must simply be too complicated for them. So then the question is, when does Apple admit the vendors are too dumb to do the right thing, and abandon the complex unreliable architecture and implement something simpler for dumb vendors?
My point is that no matter what, you can't really defend the current behavior. The user pain is simply too high at this point. It's an unquestionable failure. Things are worse than they were 8 years ago in this one specific area of reliably disabling ColorSync when needed.
4.
These problems don't occur on Windows. And with all of the same involved parties. Somehow they are making it work just gloriously on that platform (I save the insanity inducing aspects of Windows for another forum).
So I'm not finding the argument that this is the print driver's tort. Apple's play ground, Apple's rules. And there are consequences for the decisions that have been made. Here we are and things are objectively not better than they were 8 years ago.
5.
I can make a vastly more compelling case (compared to #3 above), that most color related printing problems on Mac OS with native manufacturer drivers for RGB printers, is the result of Apple's vendetta against /DeviceRGB in the print pipeline. If Apple had followed the PDF/X-3 spec, which *requires* /DeviceRGB whenever source=destination, we would not be having these problems at all. The fact the private SPI does not ensure source=destination, even when used on print jobs that the application has targeted for no ColorSync color management, guarantees that ColorSync can be invited to the party when explicitly unwanted by user and application and there is nothing the user or application can do about this - save for moving printing to a different platform, or using a RIP to get around the Mac OS print pipeline. In either of which case, these problems, like on Windows, do not occur.
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