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 15:17:42 -0600
On Apr 27, 2011, at 2:27 PM, Doyle Yoder wrote:
> This discussion has gone on long enough with some basic facts not being told.
>
> Turning off CM for printing targets can be done with.
>
> Indesign
> Illustrator
> Quarkexpress
> Adobe Color Printing Utility
> i1Profiler
> ColorMunki
> Photoshop CS4
> And I am sure there are more.
These applications do not all behave the same way with respect to the PDF print spool file produced, or the SPIs and APIs used.
No application can turn off color management. Period. The way "disabling" ColorSync works is exclusively through null transforms, meaning the PDF object source profile must be the same as the destination profile. If not, then a conversion will occur, even if in the GUI it appears you've correctly set objects to not color manage - and this in fact was a bug by default in InDesign CS3 were it used a different print path (PICT I think) and ColorSync double color managed everything. The solution was to check the Print as Bitmap option, which cased ID to rasterize the document itself, and submit it to Quartz PDF Context so it would be written out as (raster) PDF instead of PICT. Then the problem did not occur. Acrobat has had a similar problem intermittently as well.
> With the latest Epson Driver and the latest Canon Drivers, (provided PSCS4 is listed in the special casing file). I have no direct experience with HP drivers.
>
> Turning off CM is not possible with the following application.
>
> Photoshop CS5
> Lightroom
It is possible to prevent either of these applications from performing conversions, using the Adobe Color Engine, either for Export to file, or when printing. As for "turning off ColorSync" specifically, they are designed to do this, but both presently produce an extra white vector object that is not tagged with the same source space as the destination space. Therefore when using certain ICC v4 profiles, that white vector object becomes light blue - this it the "blue/gray border bug" that some people are experiencing with these apps.
>
> So for those that think Apple has a real problem please explain why only a very few applications have this problem and some old printer drivers have this problem. What do suggest Apple should do, given that most current drivers and apps allow no CM printing for printing targets?
kPMApplicationColorMatching should only accept one profile. Quartz PDF Context should only write out PDF spool files with object source spaces set to /DeviceRGB, and an OutputIntent set to the one profile supplied with the SPI by the application.
Presently Apple bans /DeviceRGB. /DeviceRGB or GenericRGB objects are instead embedded with sRGB as the source space. The SPI makes no accounting whatsoever that source=destination to ensure a null transform occurs when there entire point of using kPMApplicationColorMatching is to tell ColorSync to butt out. The SPI and the architecture itself is inherently fragile by requiring ICCBased objects instead of /DeviceRGB objects. ICCBased objects must be parsed to determine if a null transform is appropriate - that is, there is no explicit "off switch" for ColorSync. It must be determined.
The PDF/X-3 specification on which these particular PDF spool files are based, *requires* when source=destination that the source be set to /DeviceRGB not ICCBased, because that has been demonstrated to be vastly more reliable than depending on null transforms. I have suggested Apple conform to PDF/X-3 in this regard (or PDF/X-4 or X-5 would be fine now too).
>
> This probably was a much bigger issue a few years ago but it seems to me that most players in this game today have this working correctly.
OK well I'm assuming you haven't experienced, or know many who have experienced, the "blue/gray border bug" in Photoshop CS4, CS5, and Lightroom 3.x when using certain ICC v4 profiles. I've had hundreds of students and customers hit by this problem.
1. White vector objects could be argued to be superfluous in these two applications, but I don't know this for a fact. They may be necessary to achieve the specific placement of the image on the page. But even *if* they are superfluous:
2. Both apps call kPMApplicationColorMatching. That metadata is in the PDF print spool file. The intent by the application is extremly explicit: ColorSync should be off. Yet ColorSync is doing a conversion anyway. Why?
3. The objects are not tagged with the same space as the OutputIntent. Therefore Quartz PDF Context wrote out the PDF print spool file with these white vector objects tagged sRGB. Since the source is sRGB for the white vector object, and the OutputIntent is something other than sRGB, ColorSync targest that one vector white object for color management.
4. The object is white, the conversion is media-relative, it should still be white even if there is a ColorSync conversion.
Now, there are a number of questionable things happening, some of which could be argued to be bugs depending on your point of view. White vector objects are not invalid - they come up all the time in page layout applications. So they need to print correctly. 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.
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