Printing Problems in CS5 on the Mac
My Test Results
Testing primarily with two Epson wide format printers, the Stylus Pro 9900 and the SP 11880, I have run more than 150 experiments, carefully conceived to reveal which methods of printing from Photoshop CS5 on the Mac work correctly and reliably so.
This topic is one, which involves a lot of variables, so the results do vary, for example, with the printer model (and therefore with the driver, as well as with different versions of the driver for a given printer).
I have run tests in OS X 10.4.x (Tiger), 10.5.x (Leopard) and 10.6.x (Snow Leopard). My more recent testing, which is over half the total, centered on CS5 with 10.6.4. As of this writing the most recent version of OS X is 10.6.5, but I'm holding off for a while before upgrading, for various reasons.
I also tested Photoshop CS3 and CS4 some months ago. Note that in general CS3 worked like a charm, with little trouble coming from Photoshop itself. I have experienced some driver problems when working with CS3. The advent of CS4 marked the beginning of a serious set of problems for printing from Photoshop on the Mac, as you are probably well aware. This was due to Adobe writing new code so they could use OS X-based printing, which was a necessary step, which unfortunately has given us major growing pains.
In this article I want to concentrate on what I've learned about what's still broken in CS5. In an accompanying article, I've explained what the workarounds are for printing on the Mac via the Epson drivers (i.e. not with a RIP).
This writing follows a very long and extensive email conversation with Adobe's engineer for printing for Photoshop, Dave Polaschek, with a bunch of my luminary printing maven friends cc'd. I've been working very hard to help move the ball down the field, but it remains to be seen whether my weeks of effort will bear fruit. I have uncovered many of the sorts of clues, which are useful in helping someone who understands the details of a system figure out where a bug may lie.
I know of five problems, some of which appear to result from the same bug or cluster of bugs.
FIRST:
The behavior of the "Normal" path to print with Photoshop is wrong with respect to Null profile-to-profile conversions (i.e. getting no conversion while doing the printing step when you want that). The Normal path in the Print dialog is to choose "Photoshop Manages Colors" and then chose the appropriate profile for your circumstances, etc.
There are two main methods to use the Normal path:
A) You are in the RGB working space and you use the Print dialog printing process to convert to your chosen printer profile (let's call this "Convert while Printing"), and
B) You first convert from your RGB working space to your printer profile using the Convert to Profile dialog (I call this "Convert in Advance"), and then you enter the Print dialog and pick Photoshop Manages Colors, then you pick the same profile that the file was already converted to. This should result in the absence of another profile-to-profile conversion, aka a Null conversion. Sometimes it does, sometimes it doesn't. The fact that it doesn't always result in no conversion is the problem. Even worse, sometimes the errant conversion is to one's monitor profile.
Under normal circumstances, Method A works correctly. Sometimes, however, with my 11880, another bug starts happening, which causes prints made this way to turn out super dark. I call this the Super-Dark bug. Sometimes, either reinstalling the printer driver and/or restarting the Mac causes this bug to vanish. But it may return soon thereafter, triggered by an unknown series of events. This is the second problem. Now back to the first.
If you use Method B, you should also be able to assign any profile to the image, and then enter the Print dialog and choose that profile in the Printer Profile pop-up, and still get a Null conversion (no conversion). But that is not the case, at least in the four cases that I tested. Adobe's printing engineer, Dave, doesn't seem to know why this is the case, and it should not be the case. Note that doing this exact procedure is recommended in an Adobe document here (they specify Adobe RGB as the RGB working space to use to get a null conversion from PS CS5, but this most definitely does not work in my testing):
http://kb2.adobe.com/cps/834/cpsid_83497.html
Think about this for a minute: If you convert an image into printer space, the RGB values in the file are all correct for printing. If you then assign another profile to the image, the appearance of the image will change on screen, despite the values in the file still being the same. If you then print the file and ask for a Null conversion (by choosing that same assigned profile in the Printer Profiles pop-up) the print should turn out looking right (essentially the way it looked on screen before you assigned the other profile). If a conversion to some printer profile is done instead of the Null conversion, then you can be certain that a conversion was done against your wishes because the image will look wrong in the print. This is especially true if you assign an RGB working space (sRGB, Adobe RGB, Pro Photo RGB, and DCam 3, J. Holmes are the four that I tested), because they cause the appearance of the image on screen to change dramatically when assigned to a file that was previously converted to a printer space. This is because printer spaces and RGB working spaces are hugely different from one another.
If you assign another printer profile to the file, the image on screen will change, but how much depends on how different the two printers are in their raw state. For example, some printers are very dark in their raw state and some are not. In many cases, such an assignment won't change the image very much on screen, or in a print, which was made with a conversion to the incorrect printer profile. That's why assigning a working space profile to the image can provide a fail-safe check to prove that a null conversion was achieved during printing.
The interesting thing is that when I converted to either the correct Epson canned profile for either of my printers, or when I converted to my custom profile for the 11880, Photoshop behaved correctly and did a Null conversion in the printing step. And when I did the same, except I assigned any of those four RGB working spaces to the file, Photoshop did not behave correctly and instead converted the file from the embedded space to some mystery printer profile which was for a printer + paper + ink + driver settings combo with very similar properties to those of my own printing setup. This meant that the print was pretty close to the wacky appearance of the file on screen after I assigned the RGB working space.
But, when I assigned a Chromira profile (which I had built earlier for West Coast Imaging for their new Chromira printer) to the image, then went into the Print dialog and chose that same profile, instead of getting the null conversion, I again got a conversion to some mystery printer profile. This is extremely odd.
There is no possible way that Photoshop CS5 could know that the embedded Chromira profile was wrong, but that my embedded custom 11880 profile was right, by looking into the two profiles (one worked to get a null conversion, the other did not). Adobe's code would seemingly have to be looking at the editing history of the file! In other words, it looks as though perhaps they are flagging the image as having had a profile assigned to it, therefore requiring a conversion. I am only guessing, but Adobe's printing engineer was unable to shed any further light on this. If all that I just explained is clear to you, you should understand how very odd all of this behavior is.
Needless to say, this problem alone means that a very large amount of uncertainty exists within the Normal pathway for printing from Photoshop, at least when you assign a profile (most people don't need to do that for printing normal images, as opposed to printer profiling targets, but it does make an interesting way to detect for certain whether a conversion was done, which is good because if an image is subjected to a subtle conversion, you could have a subtly wrong print, which can be devastating inasmuch as you might not catch it before delivering it to the customer.
I require certainty of correct color management processing when printing. Nothing less is acceptable. We all need it.
So, maybe we can trust the Normal pathway for printing in CS5, particularly while using "Convert while Printing" or even while using "Convert in Advance", at least with some Epson drivers. But I'm still not sure that this is the case, despite running a huge number of careful tests. And the further caveat regarding the Super-Dark bug applies to this workflow too. More on that below.
And there are most definitely problems with printing from files to which we've assigned some profiles, if not any profile, and although this may be irrelevant to most workflows, it is not irrelevant if you want to try to either fool Photoshop CS5 into printing a printer profiling target correctly (best to use the Preview workaround for that -- see my other article) or if you want to use the Assign-an-RGB-working-space trick to verify that CS5 is leaving your Converted-in-Advance file alone while printing.
But that's only the first problem.
Note: CUPS is an open-source UNIX system for printing, which is built into OS X, and which is always running. It may be responsible for messing up the Null conversion situation. It may be incorrectly telling ColorSync to convert the data. Adobe's engineer suspects it, and this makes sense to a friend with a long familiarity with UNIX. Perhaps they're right. We may need Apple to help get this straightened out. All the companies need to step up.
http://en.wikipedia.org/wiki/CUPS
SECOND:
I already partially explained the second bug. I call it the Super-Dark bug. I've only seen it with my SP 11880, not with the 9900, suggesting a connection to the 11880 driver. Prints made by the Normal method turn out so dark that they're nearly black in large areas of the image. Prints made by just one of the four or five alternate ways to print from Photoshop also turn out super-dark.
This bug may be the result of having two simultaneous printer connections with two driver installs. Or it may not. Note, however, that this bug does not affect printing with either Photoshop CS3 or Apple's Preview application! Since Preview.app uses the modern printing system in OS X, this strongly suggests that CS5's code is at least involved in triggering the bug somehow if not being the primary cause of it. I can't say, however, whether the primary culprit is code from Adobe, Epson or Apple. Nor can I determine whether two or more errors in the software architecture for printing in this configuration of elements are to blame.
Just to complicate matters, this Super-Dark bug appears to be related somehow to two of the other three bugs I've found: The Ultra-Dark bug, which causes yet another workaround method in CS5 to result in prints which are even darker than those I get with the Super-Dark bug, and which bug does not come and go in lock-step with the Super-Dark bug (surprisingly), AND the Print Settings… dialog-won't-open-when-Printer Manages Colors-is-selected bug. More on that later.
The apparent connection between these bugs derives from the fact that I saw them commence simultaneously at one point.
Today, Dec. 1st, I finally figured out that this Super-Dark bug, affecting two printing methods intermittently (the "Normal" method where we take a file still in its RGB working space, go into the Print dialog, choose Photoshop Manages Colors, and choose the correct printer profile there, and the "ColorSync" workaround, where we take a file still in its RGB working space, go into the Print dialog, choose Printer Manages Colors, and choose the ColorSync option in the Color Matching tab of Print Settings) is simply the result of no conversion being applied! Since my 11880 prints quite dark in its native state, and since it prints even darker when I set the Color Density slider to +15, when a printing file is not converted from the RGB working space to the printer profile as intended when I click Print, the result is a print which, among other things, is massively dark. Most significantly, a preview of an un-converted print from the original file is a perfect match to an actual print.
If you were printing from an RGB working space to a 9900 family printer, with its beautifully linear raw state, and not applying any Color Density adjustment, an unconverted file would not print a lot darker than the original on-screen image. The colors would look very different, however. To see how un-converted images look when printed, in Photoshop, go to View > Proof Setup > Custom… and pick the relevant printer profile. Then check the Preserve RGB Numbers option!
THIRD:
The Ultra-Dark bug: It occurs only when trying to use the Convert in Advance method with Printer Manages Colors, and choosing the ColorSync option in the Color Matching tab (not choosing EPSON Color Controls), and when having chosen Relative Colorimetric in Adobe's Rendering Intent pop-up. When I choose Perceptual there, but everything else is the same, the Ultra-Dark bug does not occur, incredibly enough. This is an important clue for debugging. On one occasion this bug did go away after I did a re-install of the 11880 driver, which might have been accompanied by a restart of the Mac. But at one other point, this bug remained, after the Super-Dark bug had gone away. Also, I have only seen this with the 11880 and not the 9900, which makes it seem to be at least partially caused by a driver bug (Epson code).
Again, Today, Dec. 1st, I had an epiphany about this bug as well. In this case, it appears as though some code culprit running on the Mac, possibly Adobe's printing code, possibly the Adobe Color Engine, possibly the CUPS printing system, possibly the Epson driver for the 11880, possibly the ColorSync engine, or possibly Apple's printing services code is taking the file (when I hit Print) and instead of doing no conversion on it, is converting the file (or requesting a conversion of the file) to my display profile, then printing it!
I have also seen this happen when I have not only used the Convert in Advance method, but also assigned a printer profile to the image, prior to entering the Print dialog, as a test. That's apparently what happened in at least one experiment. This general behavior is also one, which I have seen before. It's what Apple's Preview application will do to a file when it prints it, if the file has a printer profile embedded in it and you choose Epson Color Controls. Specifically, Preview converts to my ColorSync default display profile, not to my normal display profile (not to the one I'm actually using), resulting in a ridiculously dark, massively ruined print—but not if the Preview workaround instructions are followed (feed it a pre-converted, untagged print and choose Epson Color Controls).
Again this is an intermittent bug, which is at least sometimes remedied by a Mac re-boot or an Epson driver re-install, or both. And apparently the bug is the result of a crazy conversion being done to the active display profile, in place of no conversion at all.
FOURTH:
The Print-Settings-Dialog-Won't-Open-When-You-Picked-"Printer Manages Colors" bug. This one works like this: If you want to set your Print Settings (Media Type, printing resolution, Off [No Color Management], High-Speed on or off, Color Density zero or not, etc., etc.), you can enter the Print Settings… dialog from Adobe's Print dialog just fine, if you've selected "Photoshop Manages Colors". If, however, you select the other option, "Printer Manages Colors", then sometimes you can't get into the Print Settings… dialog at all. Often, when this bug happens, you can get into it once, set your settings, and then click Save to exit Print Settings… But then if you again try to enter it, e.g. to make sure your settings stuck, then no luck.
Most interestingly, I saw this bug occur precisely at the same time that the Super-Dark bug returned on my 11880, after I had previously gotten that bug to vanish for the second time by rebooting the Mac (the first time I had re-installed the 11880 driver and may or may not have rebooted the Mac). So they seem to be interconnected, but it's hard to imagine why they would be, as they are such radically different symptoms. Nevertheless they did happen at the same time, so they are almost certainly connected, and this is another very important de-bugging clue.
But wait, there's more!
FIFTH:
The Print-Settings-Don't-Stick-When-You-Click-Save bug. When you're inside the Print Settings… dialog you can approach saving settings three different ways. In the Presets pop-up, we now have a great new choice (I'm not sure when this was added) of "Last Used Settings". This setting seems to result in the dialog always working correctly, i.e. when you make changes, then click Save to exit the dialog, the settings stick, so far every time for me at least.
The presets pop-up also lets you save a new preset after making new settings, or lets you pick an existing preset, make changes to one or more of the settings then again save it or do a Save As to save a new preset. If you do this, and then do not make any further changes to settings, then click Save to exit the Print Settings dialog, again the results seem to be reliable, based on my large number of tests with my various configurations of matter.
BUT, if instead you choose an existing preset (not Last Used Settings) and then you change one or more settings, then click Save to exit the dialogue, you would think that would work. The word Save does, after all, mean Save. But it very often does not, as one can tell by re-entering the Print Settings… dialog from the Print dialog and checking whether all the settings stuck or not.
On account of this uncertainty, I find it intolerable to not be able to go in and verify that all my settings took. If they did stick, I then click Cancel to leave the Print Settings… dialog without risking any further changes. At least choosing Cancel should always result in settings remaining unchanged and I know of no instances where this has ever not been the case in any software I've ever used.
So remember the Fourth bug above! The Fourth bug prevents me from going in and checking that the Fifth bug didn't screw me. Sometimes.
Finally, I have to say that although I've listed five things I've found which are not working right when using only CS5 with OS 10.6.4, I am left with the distinct feeling that there must surely be more bugs in the printing system that just those, simply because I've seen so very many things go wrong over the last year in testing. Hopefully I'm wrong about that and the other problems have been fixed with Adobe's advances between CS4 and CS5, plus Epson's driver updates and some bug fixes from Apple since the introduction of Snow Leopard.
So, how should we print? If you print using the Normal path, either with Convert while Printing or with Convert in Advance, how will you know that some not-requested profile-to-profile conversion was not done to your file? How can you be sure you will get the conversion to a printer profile that you requested when using a conversion during printing? How can you be sure it will print as it should? The uncertainties need to be reduced to near zero. The Null conversion behavior needs to be predictable and correct. The Print Settings dialog bugs need to be fixed. And the massively tricky Super-Dark and Ultra-Dark bugs need to be banished forever.
These two Dark bugs might well be the result of code interactions between Photoshop CS5 and an Epson driver, which seems likely given that I've only seen this issue come up with one printer, the 11880, and not the other (the 9900). A friend has also seen freak, super-dark results on his Stylus Pro 4880 however. He also has two printers connected, that one and a 3800.
Or the Super-Dark and the Ultra-Dark bugs might be two manifestations of the same underlying problem, which can nevertheless occur at different times. Or this could involve code from Apple as well. A three-way nightmare to debug? [I've subsequently figured out, as mentioned above, that in the cases where I am converting from the RGB working space to the printer profile when hitting Print, that the super-dark problem is due to that conversion simply not occurring. And that in cases where I've converted in advance, that the super-dark or ultra-dark problem is the result of an errant conversion from the printer profile to my display profile when I hit Print. So, no conversion when a conversion is requested and crazy conversion when none is requested!
Some, I don't know which, of the above issues have apparently already been fixed, but are scheduled for release to us only in the form of Photoshop CS6. I think few of you would disagree with me when I say that Adobe owes us a bug-fix version of CS5, and as soon as possible. One could argue that a bug fix for printing issues in CS4 is also in order. Customers aren't supposed to have to pay for bugs, let alone bug fixes.
Note: many months ago I did what I call the Epson Purge, where I removed all traces of old Epson software and printer drivers, and only installed the necessary newest ones. That did fix a couple of other problems with the 11880, but I don't remember just what those were. So I shouldn't be having any trouble now due to old code. I am using the latest drivers and all the latest firmware too.
Until the Super-Dark and Ultra-Dark bugs re-appeared the week before last, and they brought back a particularly bad case of the Print Settings Dialog Won't Open bug, I thought that, OK, I'll trust printing from CS5 and start doing things that way. I have previously stuck to using only the 11880 with CS3, albeit with Snow Leopard (10.6.x). (Some people have stuck with CS3 and Tiger (10.4.x), which may still be the most ironclad method.) But the CS3 and Snow Leopard combination has lately started to fail me, with the 11880 not printing the full width of many files. At least that problem is gone with CS5 and it's never been problem with Apple's Preview.
I want one standard sequence of steps for printing from both of my printers. I don't want to have to remember two different ways. It's too hard. At this point I unfortunately have concluded therefore that Photoshop CS5 is effectively unusable for me and bite the bullet and decide to always print using a safe method. Fortunately, just today, Dec. 1, 2010, Adobe released their long-awaited alternative printing application "Adobe Color Printer Utility". Get it here:
http://kb2.adobe.com/cps/834/cpsid_83497.html
I have done zero actual printing tests with it, but I believe this will very soon become my preferred way to print everything. I had planned on using Apple's Preview application until this new software arrived today.
To use the Adobe Color Printer Utility for normal printing, Convert in Advance (to your printer profile), save a flattened TIFF then open the file with the Utility and print. To print a printer profiling target, simply open the untagged target file and print it (using all the correct settings, of course!).
To use Preview for printing instead, please refer to my detailed workaround instructions in my next article in which I concentrate on the various alternative pathways in Photoshop, on using Preview to print and on using the new ACPU to print.
Printing from Preview has both advantages and disadvantages, but so far it seems to be 100% reliable, if and only if you feed it pre-converted, untagged files AND choose EPSON Color Controls! If you use it correctly, you can print profiling targets or Converted-in-Advance files perfectly — i.e. you will get reliable Null conversion. If you print a Converted-in-Advance file with Preview and there is a profile embedded in the file, you will get nothing but garbage, because Preview will convert the file (without asking you for permission or telling you what it's doing) to your default ColorSync display profile when you hit Print. This is an obscure profile provided by and anointed by the system as a fallback device in case you don't have a display profile of your own. Apple's logic in taking this approach is, I would argue, severely flawed.
Presumably if you feed Preview a file in its correct working space, Preview will also convert that file to the same crazy monitor profile, then do the requested conversion to a profile you pick in the ColorSync option profile pop-up, but I can't attest to that.
So I guess all I can suggest is to learn the workaround instructions (linked from here later). More to come soon in a following article.