Re: Printing with No Color Management (again)
Re: Printing with No Color Management (again)
- Subject: Re: Printing with No Color Management (again)
- From: Chris Murphy <email@hidden>
- Date: Wed, 27 Apr 2011 16:46:37 -0600
On Apr 27, 2011, at 4:25 PM, Steve Upton wrote:
> At 3:17 PM -0600 4/27/11, Chris Murphy wrote:
>> <big snip>
>> .... My argument is that Apple has utterly failed to provide an explicit off switch for ColorSync. The present mechanism departs from the PDF/X-3 spec, which I think is a good model to follow for this very reason, even though Apple is under no obligation to exactly follow the PDF/X-3 spec. It would eliminate the ambiguity introduced by reality.
>> </snip>
>
> In reading this I wonder about the mechanism that might best provide an "off" switch for printing.
>
> While I don't understand all the complexities of the printing mechanisms in OS X, one thing comes to mind. A mechanism to "turn it all off" might have to be "out of band" of the existing print stream. As a result it becomes a much more complicated feature to implement and could explain the reluctance of Apple to make such a change. Add to that the relatively small user base served by such a change and I can see why it might never get implemented. (from their possible perspective)
*shrug* I would think that Quartz 2D is sufficiently familiar with /DeviceRGB that it would be easy to re-enable a passthrough feature for it, so that such objects aren't at all subject to analysis and transform (even null). It's a basic part of the PDF spec, as well as PDF/X-3 upon which these particular PDF spool files are based. Quartz 2D has a passthrough and allows /DeviceCMYK. In the past (circa pre-10.3.9) /DeviceRGB was also possible.
The banning of /DeviceRGB, the null transform method are both explicit design, required explicit coding. I can understand the thinking that "wow, eventually we will simply encounter all possible bugs as a result of this architecture and stamp them out, we think we see a light at the end of the tunnel." But I think that's assumption. Null transform should work. But in fact we've seen it not work when it should. So that's one area. We have dependencies on print drivers need to do the right thing, in particular with a print driver developer who persistently and notoriously has problems with their drivers (Epson is seemingly the most common because more photographer use Epson printers but actually Canon has had worse problems up until recently and now it's Epson that still manages to have intermittent issues with the drivers). And we have dependencies in applications needing to do the right thing, in some instances they arguably won't be entirely aware of what they're doing which is why I think this is primarily Apple's problem to resolve.
In order for null transforms to occur, every single object must be tagged with a profile that matches the OutputIntent. That's logistically problematic from the outset because the application itself doesn't directly write out the PDF print spool file.
Chris _______________________________________________
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