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 21:08:20 -0600
On Apr 27, 2011, at 8:31 PM, Graeme Gill wrote:
> Chris Murphy wrote:
>> 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.
>
> I think I understand how you can end up in such a position. Printing test charts
> is a "special case", that doesn't fit into normal color workflow.
It's not just printing test charts. Prematched print jobs are in the same category. Those are clearly still a minority of all Mac OS print pipeline print jobs, but it overwhelms the volume of test chart print jobs.
> That's awkward.
> In a flash the idea comes to mind - the null transform! Neat. This is a way
> of making the special case go away, of making sure that every device color
> space is labelled, so that everything is guaranteed to be color managed.
> Once that idea has lodged in place, and a whole system has grown up
> around it, it's difficult to reconsider it. It's hard to say
> "I was wrong, I stuffed up".
Does not happen on Windows.
Does not happen with PDF/X-3 workflows if you actually follow the spec, unless encountering a lifeform that has not been found on numerous recorded worlds, one that has acid for blood, etc.
> A guess would be that the following trade-off was made:
>
> Using this scheme makes color work more reliably for ordinary users,
> particularly in the face of applications that aren't color aware. The
> trade-off is that it makes things less reliable for color professionals.
> Color professionals are a small group compared to ordinary users, and
> they are more technically sophisticated. Hmm.
>
> The real answer is not to be in a position to trade one group
> of users experience for another's.
Apple might actually believe this, but it fails to withstand scrutiny. kPMApplicationColorMatching does not apply to the ~90% workflows where the app is not color aware, or for ordinary users. It's used in a very express situation, exactly and only the express use cases: targets and prematched content. Therefore the two cases are not concomitant, and any notion of trade-off is a false impression.
There is absolutely zero reason I have found why Apple cannot leave everything exactly the way they want for that 90% of ordinary users and apps (the vast majority of which don't knowingly use ColorSync, using printer manufacturer proprietary defaults instead), and also provide a reliable off switch using a special SPI or API for doing so, and readily making documentation available to the handful of companies you and I could count on two hands, that really need it. Not just would want it. But necessary for their business models and software to function.
>
>> 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.
>
> Hmm. Adobe use it in ACPU - I can see the string in the executable.
Sorry yes, I'm not thinking of Adobe as being in the print profile application business. I think of those as companies like X-Rite, ICS, you, and a few others. But yes it does use it.
> Of course one has to guess how to use it.....
> There are no references on http://developer.apple.com/,
> (But then Apples development doco has always been a bit hit or miss in my
> experience.)
>
> I guess the other approach would be to see about writing ones own PDF
> into the print queue, bypassing the whole mess.
There are a bunch of APIs that capture driver dialog settings that get baked into the PDF print spool file and also there's 2nd "sidecar" like file that contains other metadata for theprinting system. So directly inserting a PDF minus all of this other stuff I don't think would be straightforward.
More straightforward would be to yank cgpdftoraster which calls Quartz2D which is responsible for rasterizing and calling ColorSync, for something that just rasterizes and never calls ColorSync. CUPS is designed for swapping out raster filters so someone could do it, but would it survive OS updates? What else would break? What other things are you stepping on since Epson, HP, Canon drivers all currently depend on it. I'm not sure. But I have thought about it.
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