While printing up handouts for my talk at Cabin Fever, I finally tracked down why Adobe Reader was producing such crappy colors.
The left is before and the right is after the fix, scanned at the same time with the same image adjustments:

All of the print settings appeared correct (plain paper, 720 dpi, normal contrast, etc, etc), but Adobe Reader (and only Adobe Reader) looked like it was trying to print on vastly higher quality paper than I was using. Too much ink, too much contrast, generally useless results.
The solution was, as always, trivial, after far too much fiddling around.
In Reader’s Print dialog, there’s a button in the lower-left corner labeled Advanced. Clicky, then put a checkmark in the box that says Let printer determine colors.
And then It Just Works.
Equally puzzling: ask for 25 copies of a two-page document, check the Collate box, and you get 25 page 1, 25 page 2, then more page 1 starts coming out. I bet I’d get 25 x 25 sheets of paper by the time it gave up.
I have no idea what’s going on, either.
Memo to Self: verify that the box stays checked after updates.
The default in Adobe Reader 9 and later is to do our own color management, so that proper and correct (according to the industry standards) color management is performed on printed material. This ensures correct color on all printers and settings for your PDF documents.
However, for printers that have their own “special sauce” for color management (things which violate the standard but may make that particular printer have a more “pleasing” look), this can cause results that don’t match other printouts from other applications. Thus the checkbox to let the printer do its thing – which will remember the setting.
Leonard Rosenthol
PDF Architect
Adobe Systems
Sounds good to me…
Fairly obviously, the type of paper has a dramatic effect on the printed results, but there’s evidently no way to tell Reader which paper it’ll be using… other than through the printer options, which it totally ignores while doing its own thing. I spent far too long discovering that simple fact; I couldn’t believe what I wasn’t seeing!
I don’t profess to understand the multiple transformations between PDF and the final printed dots on the page, particularly in a networked Linux system that passes print files through two CUPS servers, but it does seem odd that only Adobe Reader has a problem… while giving no control over what it does other than to shut down whatever it does.
Anyway, it’s heartening to know that the checkbox won’t shut itself off…
Thanks for the explanation!
I don’t know about Adobe Reader, but note that the “special sauce” Leonard Rosenthol speaks of is something you almost certainly want to disable. Of course that won’t change the major waste of ink that you blogged about yourself.
For the record, avoid HP while you’re at it.
The file server that actually handles the printing is running Turboprint, so AFAICT there’s not much Epson DNA in the print chain. The driver doesn’t seem to have an automagic enhancement mode and, for all other programs, produces gorgeous results on the proper paper (modulo my use of non-Epson bulk ink).
The symptom of Adobe Reader’s automagic meddling matches what happens when I tell the printer to print with photo-paper settings on cheap copy paper. You’d expect having the printer driver settings in Reader set to “cheap paper” would turn down the meddling, but … it doesn’t.
And, at this point, I won’t buy a printer if I can’t affix a bulk ink system to it. That’s getting harder and harder to pull off, alas.
Turboprint is likely much better than what Epson created for Windows, but I felt I had to at least point it out to other readers of this blog post.
Regarding the bulk system, that definitely sounds like what they should make printers like by default. ;)
If you are using one (or more) print servers, than you’re pretty much made it IMPOSSIBLE for us to be able to “do the right thing” out of the box – which is what we are able to do when printing directly to a printer (or at least to a printer that can report back it’s capabilities).
Reader queries the driver (and PPD, if present) for as much information as it can about the final output device, it’s capabilities & settings. We use that information to then make decisions about color, paper sizes, tray selection, etc.
BUT if your printer is removed from that process by a server that doesn’t report the accurate information – than we can only guess.
The reason it’s only Reader that is effected, is that only professional printing applications (such as those from Adobe) offer rich color management options. You’d see the same thing if you ran Photoshop or InDesign, for example.
There is a group, of which I am part, working on color management in the Linux printing path – so that someday this will all work correctly.
I suppose I’m not bright enough to understand why it is that Reader (and, it seem, other Adobe apps, none of which run on Linux so I really don’t care) ignores the parameters I select in the Printer Options panels and insists on doing the wrong thing because it can’t automagically get information from wherever it’s looking. AFAICT, the server does burp up the correct PPD; other apps can find it and use it.
Now, if Reader suppressed all the settings it wasn’t going to pay attention to, leaving me with no options at all, then I’d be able to understand why it was always producing ugly output. But displaying all the printer settings, letting me twiddle them, and then doing the wrong thing seems, well, a misguided design decision.
It’s worth noting that all other applications take the printer settings into account, so this is not exactly magic…
I finally got a couple of IT8 calibration targets and made a first-pass whack at coercing decent colors from my HP scanner, so I’m not entirely ignorant of what you’re talking about. I’d really like to get a color-managed image chain that doesn’t require major hackage.
Glad to hear you’re working on it; perhaps I might live to see the day!
Oh, if only it were that simple ;).
The problem is that we want to do the right thing for all possible PDF documents by default – which means we read the information about the printer and properly color managed the content based on what we receive. We then send that information to the “printer”.
HOWEVER, in your case, the correctly color managed data does NOT go direct to the “printer” – instead it goes through one (or more) CUPS servers which (again, by default) are setup to assume that the incoming data is NOT color managed (since that’s what most/all other applications do). So it takes our already color managed content and mucks with it in an attempt to “fix it” – not knowing that we’ve already done the work for it. This lack of a “don’t muck with it” command is one of the things that OpenPrinting () and OpenICC () are trying to address.
In the meantime, you have to turn off (as you have) our color management options. For most PDFs, it won’t matter – but if you print out any PDFs with rich transparency or other graphic effects the “late-stage CM” will produce the wrong results….
For most PDFs, it won’t matter
I’m certain that there’s knob somewhere in the CUPS stack that I could twist to shut off / enable whatever they’re doing / not doing specifically for PDF files, but … getting that to work for print jobs from all the household printers seems daunting.
Maybe I won’t live to see the day… sigh
Seriously: thanks for all the information. It makes a certain peculiar sense!
So that’s why I’ve heard of people having problems printing photos from Photoshop in Mac OS. That was most enlightening, thanks!
Ed, next time buy a printer that prints on both sides automatically. Mine has a thingy that flips the paper over at the back of the printer!
Long ago, I had an IBM (pre Lexmark) laser printer with dual paper feeds and duplexing. Wonderful gadget, gorgeous print quality, except for the occasional paper jam… which inevitably rammed a wad of paper deep inside the most inaccessible reaches of the machinery, requiring a complete disassembly of the whole stack. Soured me on duplexing for years.
I keep thinking a duplexing color laser printer, but … the duty cycle would be painfully low.
On the other paw, I could produce colored toner transfer sheets for my PCBs, which might make up for everything.
I use a HP deskjet 970. It does a good job of flipping the paper. A paper jam is easy to purge. I notice the rubber rollers harden up and cause problems. Some method of keeping them supple would be a blessing!
I have a dwindling stash of Xerox Platen Cleaner Paks: “Platen restorer and cleaner”. Each one is a small glass vial inside a plastic + fabric applicator. Crack the vial, rub the juice on the platen, and shazam it’s once again soft and gummy.
The vials contain a hellish mixture of:
I’d guess the first two ingredients perform most of the magic… but TCTFE sounds like something you can’t get anywhere these days!
Thanks for that info Ed, Here is something on the first chemical
http://en.wikipedia.org/wiki/1,1,2-Trichloro-1,2,2-trifluoroethane
Xylol is the solvent. I have some and will give it a go!
From Wiki:
“Xylene is used as a solvent in the printing, rubber, and leather industries. Xylene is also abused as an inhalant drug for its intoxicating properties.”
Ethyl acetate + a drop of silicon oil + a speck of perfume = nail polish remover for the shop assistant!
Xylene is also abused as an inhalant drug for its intoxicating properties.
I read somewhere that xylene smells like iron and apples… and it does!