![]() |
![]() |
|
|
|
|
|
Last night I was trying to print a document from my PowerBook to an HP PSC 2210 My first attempt was to do things the obvious way. I launched the Print & Fax prefs pane and clicked the little + button, which in turn launched the Printer Browser. The shared printer didn't show up automatically, so I clicked “More Printers…” and selected Windows Printing from the first drop-down list. Now for some reason this sheet always assumes you want the workgroup called “Workgroup”, despite the fact that there's no such workgroup on my network. So I changed that to “Network Neighborhood”, selected the actual workgroup for my wife's machine, selected her machine, authenticated without a username/password, then chose her printer. Finally, I chose the PSC 2210 driver from the “Printer Model” drop-down list. (This was a bit tricky, since instead of being listed under “HP” it was listed under “PSC”, which it took me a long time to notice listed among the various printer manufacturers.) Ok, that wasn't too bad. But when I tried to print, the print status program displayed a message about PrintJobMgr exiting unexpectedly with code 105. This is decidedly not a helpful error message. This is where the average user gives up and goes back to Windows because Macs “don't work right.” This is where Apple should work much harder to make sure error messages give some indication of what's gone wrong. After googling for the error message without success, I eventually launched Console.app and checked out the various error logs, finally striking pay dirt with /var/log/cups/error_log. There I learned that the connection was failing with error NT_STATUS_ACCESS_DENIED. Well maybe I can do something about that. I tried enabling the guest account, but no dice. The only thing that worked was to create a user with a password and print as that user. A bit confusing, but no biggie. But still no love! Print jobs still failed with error 105 despite the lack of access denial error messages. The only remaining clue was an error message: “Unable to retrieve workset from PPD: /private/etc/cups/ppd/psc2200.ppd”, but I didn't get anywhere trying to figure this out.
Enlightenment came when I finally stumbled across this post at macosx.com. The magic paragraph was:
In other words, the HP drivers won't work for network printers because HP bypassed the OS X print system! <sigh> How many times have I seen this? Some peripheral vendor decides, “hey, I know there's an existing, flexible, rationally-designed piece of driver infrastructure in place, but I'm too lazy or incompetent to understand and use it so I'll bypass it with my buggy, closed-source, inflexible driver that will crash your computer if you use it in a situation not 100% identical to the setup in our development lab.” Occasionally this is rationalized by claiming that the existing infrastructure doesn't support some gee-whiz feature of the vendor's product, so the buggy, closed-source, inflexible, machine-crashing driver “adds value” over the OS vendor's driver infrastructure. Never mind that the OS vendor could probably be persuaded to support said gee-whiz feature, or there's often a work-around for supporting said feature without bypassing the OS' entire driver infrastructure. This is particularly true in the case of CUPS, which is modular and open-source, and can thus be extended quite easily. As an existence proof that there's a sensible way to support my printer within the CUPS system, consider the solution to my original problem. The solution was to download the open-source HPIJS driver from linuxprinting.org. This driver works perfectly with any CUPS transport including network transport, supports full-quality photo printing and most other bells and whistles that can sensibly supported over the network. Ironically, the HPIJS driver is developed by HP for Linux, proving that HP can come up with a reasonable design that plays well with others. I suspect this is because the open-source community has direct access to the engineers via the driver's SourceForge project. There's nothing like having knowledgeable users holding your feet to the fire to get you to improve your design! Also, note that the HPIJS driver can coexist with the standard HP driver so that things like scanning and faxing can be supported when the printer is directly connected by USB. You just need to create two different printers: one for direct connection and one for network connection. Ugly, but not too bad IMHO.
|
|
![]() |
![]() |




[...] For some deep seated financial reason, Epson and HP do not like to make all their printers Network aware. They work great out of the box via USB printing. Unluckily a large number of their printers are not postscript compatible. The driver bypasses the CUPS printing daemon. Locally this is fine because the driver is providing the translation. But when you throw it on a network the driver either can’t communicate across TCP/IP, or if it does, the “server” doesn’t know how to process the raw data it is receiving. [...]