By Paul Murphy, author of The Unix Guide to Defenestration
Printers suck. I'm sorry, but that's the way it is. When they work you get no credit, and when they fail - which happens way too often - the user's emergency isn't just your problem, it's your fault.
Real problems are usually easy to find and fix ("Lets try it with the power on...") and your ability to manipulate the interface file and queue system to create user specific psuedoprinters usually makes light work of even difficult printing requirements. But what do you do when the user perceives some horrific problem, and you don't?
In many cases that perception will be the result of some obvious error you can discuss with the user and then walk away from. For example, the guy who complains bitterly that "Your printer is only printing the first few words on each of my lines," can usually be shown that printing a 228 character wide report on letterhead using a 16 point typeface isn't all that practical.
In too many cases, however, the underlying problem is that some user expectation or assumption doesn't quite line up with the capabilities of the device. It's the subtle stuff that's hard to deal with; I'm not talking about the guy who complains that the colors don't come out right on powerpoint slides sent to a black and white printer, but about the person who tries to print a fully kerned PDF on an HP laserjet set for PCL5.
Once you grok the nature of the complaint you may be tempted to just tell the user the truth: "Sorry, this printer can't do that;" but I've not found this approach to be very satisfactory because my stumblings in trying to understand the issue undermines the credibility needed to pull that off without leaving an unhappy user.
To solve this problem I collect print files produced by vendor provided printer capability demoware for each of the printer types I'm responsible for. For my QMS/Minolta color printers, for example, I have the output of a "print to file" for a set of expensively rendered color images that they used to show off those printers at trade shows and a similar set of Lexmark prepress files developed to show off their fonts.
Now when a user has one of these subtle problems, I suggest that I don't know what exactly the printer can do with respect to whatever the problem is - but I do have a test file we can try. Printing one of those, using cat, lp, or ftp depending on the device, then gives me some "best possible" output to discuss with the user - who leaves convinced he's discovered a hardware inadeqacy we should report to the supplier.