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 17:05:02 -0600
On Apr 27, 2011, at 4:46 PM, Chris Murphy wrote:
> 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.
Small clarification that this is how things presently work.
However, my preference would be one of two behaviors, preferably both:
1. That Apple's kPMApplicationColorMatching SPI compel Quartz PDF Context to write out a PDF print spool file with uniform color space for all objects in the PDF. There is *ZERO* reason why there should be different profiles per object in the context of "Application Color Matching".
2. That Apple reinstitute /DeviceRGB for these objects, when this SPI is used. This is the proper space for these objects. Making them ICCBased I will continue to argue is improper - from the perspective of the PDF/X-3 spec, as well as rationality. Could it still work with objects being ICCBased? Well maybe so but so far it's been highly problematic in practice.
Therefore at a minimum Quartz PDF Context should write out PDF print spools with all objects and OutputIntent set to the same profile, instead of presently requiring the application to individually specify each object's ICCBased space.
But preferably, object's should be in device space not ICCBased, while using the required application specified (prematched) profile as OutputIntent. The OutputIntent can be used by any aware PDF reader familiar with PDF/X-x as the "implied source profile" for /DeviceRGB so that soft proofing can be enabled, however when the PDF is processed for the intended output device, those objects are considered already converted, and further color management can simply be bypassed entirely. This same behavior can apply to CMYK output devices as well, so they can once again have parity in behavior, rather than RGB somehow being treated as unique in all of this, when it really isn't.
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