The Fugue

Adobe Acrobat Reader 7.0 and CUPS windows postscript drivers spooled over Samba to a CUPS server is the recipe for not getting all pages printed. I'm not sure who was at fault, although I am prone to blame Adobe. A workaround is to use Adobe's postscript driver instead of the CUPS one. I'll try the CUPS driver again when version 6 is released.

Along the road, I picked up a decent understanding of how Windows network printing works, how Samba works with it, and all the idiosyncrasies of the black art that is setting up network printing with Samba. At first, my already-strained relationship with cupsaddsmb was in a nose dive. Here I was tooling around in rpcclient seeing very long lists of drivers that were all the same files. If every printer was using the same CUPS (or Adobe) postscript driver, why have 100+ drivers? At this point I was ready to write my own slightly intelligent cupsaddsmb.

Then out of the blue I found something in Google Groups that indicated that each driver should have its own PPD, and that CUPS stores the PPD for each file. The reason for this is that many options of the sort set with lpoptions are just stored right there in that PPD. One of the things cupsaddsmb does is to grab that PPD from CUPS and upload it along with the rest of the CUPS driver. Well, ok, now I can see a good reason to do all of what cupsaddsmb does with each printer even though you have almost 50 HP 4000 Series printers that all use the same PPD, to say nothing of the other printers that use different PPDs. So cupsaddsmb is off the hook for now. Still, it's not intelligent to tell me quietly whether each printer succeeded or failed, and it's an obvious scripting application written in C for crying out loud, so I am not letting it off parole quite yet.