Using 20+ year old hardware is as much a curse as it is a blessing.

Set-Up:

Imagesetter (AccuSet 1000) – RIP (PowerMac 7500) – CUPS server (Raspberry Pi) – Clients (OS X 10.5, macOS 10.12)

The OS X 10.5 client currently serves as an MDNS print server for the newer OS machine since that is the last Macintosh OS version to speak AppleTalk, which the even older RIP requires (thankfully via ethernet).

In this day and age OS X 10.5 (Intel) has nothing close to a modern web browser. Thanks to the incredible persons at floodgap.com, 10.5 on PPC does in the wonderful TenFourFox, which (as its name implies) means OS X 10.4 has a more modern web browser than 10.6. Hell, Mac OS 9 has Classilla (progenitor of TenFourFox). In a perfect world I would use the 10.5 machine as the server for a newer, betterer everyday workstation, but that money doesnt exist. So out comes the Raspberry Pi.

Originally meant to run Emulation Station from the RetroPie image, it is now running Netatalk and CUPS packages. Setting it up is fairly easy, the only tricky part being adding the shared printers to the OS X client. Using the add printer assistant, it discovers the shared printer(s) but wants to print via Bonjour (aka zeroconf, aka MDNS). While RetroPie does include MDNS it doesn’t seem to support printing.

So the trick is to use the local CUPS web interface, though this can also be done manually, to add the printer shared from the Pi. This way you can set the URI to use ipp and, the real trick is put ?waitjob=false behind the URI. Which in my case would be…

ipp://host-address:631/printers/AGFA_AccuSet_1000?waitjob=false

Without that the printer is put in ‘pause’ by either CUPS, probably client though it seems odd to be able to do so, once the job is complete and all the while the client desktop printer sits waiting and doesn’t flush the job once the server printer is paused. With that added the client printer sends the job and quits.

[Update] Apparently CUPS on the Pi will set the printer to pause after no response during a long imaging cycle. It’s actually the “pap” script I’m using as the backend for AppleTalk (Netatalk) with CUPS. There are of course several versions from several sources, this just happened to be one I clicked on. I did try the one that comes up from Ubuntu.com, which I guessed was causing a problem. May not have been.

At any rate, this particular pap script exits “1” if it’s own call to the pap binary returns anything other than “0”. I commented that check out, and figured any real print errors will be shown on the RIP. Communications errors will have to go unreported.

#unless ($rv == 0) {
#print STDERR "ERROR: Unable to open connection to printer \"", $name, "\"\n";
#exit(1);
#}


With that commented out as shown the script exits “0” whether it succeeded or not. Good enough.

[Update] Well, maybe not. While the above does work, and I may return to it, I ended up using the pap backend found at emaculation.com. This script allows for better communication with the slow AGFA RIP without dying. It does require the printer URI include the AppleTalk zone and the device type (e.g., pap://*/AccuSet_1000/LaserWriter).