So at work I was informed that CUPS+Netatalk didn’t work as seamlessly as I’d hoped. I wish I had know about it sooner, I would’ve hacked on that instead of getting /etc/hosts through LDAP—which also would’ve let us disable the EtherTalk stuff on our printers and make our old MacOS 9 boxen use the CUPS print queue instead of sticking the printer forever as they slowly spool their multi-megabyte Quark files (I timed one box sending data to an NT4 MacFile-based spool at around 10KB/s, over our 100Mb/s network).
It appears that either CUPS simply doesn’t play well with Netatalk, or visa-versa. However, after a short playing-with period I got pipes to the cupsys-bsd package’s /usr/bin/lpr going, and almost all was well. Unfortunately, it prints the pages backwards, which sucks. Fortunately, it looks like that can be fixed either by adding “-o outputorder=reverse” to the lpr pipe, or by copying the PPD and adding ‘*DefaultOutputOrder: "reverse"‘ to it. Tomorrow I test if it actually works with Quark and the tabloid paper—but IE/US Letter seemed to work OK.
I was really hoping I didn’t have to manually configure papd—and disappointed that the CUPS stuff didn’t actually work with our setup. The problem, for the interested, was that Netatalk was sending printer status info from CUPS (e.g. “status; LaserJet-8000 is ready…”) back to the Macs and the Macs didn’t like that, so they just sat there waiting for Netatalk to start making sense.
I’m having the same problem with Cups 1.x and Netatalk 2.x on Fedora Core 3.
If you could document how you “piped” print jobs to LPR, or however it was that you got OS9 machines to print with CUPS, please let me know!
Also, if i try to send a job from the command line on the Linux machine, instead of an OS 9 machine, using “pap -p printername testfile.txt”, it says “status: idle; info: “printer” is ready; Connected to printer:LaserWriter@Zone.
atp_rresp: Connection timed out
this leads me to believe your earlier statement is not completely correct. i think the pap part, not netatalk part, may be the problem.
>>
This worked the first time I tried it, but not after that, unfortunately. For now we’ve gone back to having the Macs spool their jobs directly to the printers.