OK, the print queue is not jammed up. I read the man page for lpr and discovered the -l option. This option says "don't mess with this file, it is already formatted for the printer, so just send it and shut up." I was printing to a Phaser 7400DN, which I understand has the new Adobe PDF print engine (in addition to genuine Adobe PS3 and PCL-something. Well guess what happened? I sent the obstreperous PDF file with lpr using the -l option, and a few moments later a single sheet popped out of the printer. The sheet says "This printer is not configured to support direct PDF printing. Please use Adobe Acrobat to print your PDF file."
Well, that's really special. First, either the printer is lying or Xerox (who sold it to me directly) is lying. Second, it is really annoying that Xerox tells users that they must print from Adobe Acrobat for this printer. Not only have I printed to it regularly with the free Adobe Reader, but I also have at my disposal Okular, Evince and Xpdf, all of which are FOSS and can print PDF files to it. There is no need to buy a $350 software package to print to this printer. Grrr. So then I decided that, as long as I am sure there is nothing hung up in the print queue, I should try Adobe Reader again. Reader happily sent the job to the printer, the print job appeared in the Manage Print Jobs window, and I waited for something to happen at the printer. Meanwhile I also had top running. Right after sending the print job from Reader I noticed that top reported that Ghostscript was running, and consuming huge CPU cycles. I left it alone for a few minutes, then Ghostscript disappeared and pdftops replaced it, also consuming a lot of CPU horsepower. I left it for a few minutes longer, whereupon pdftops disappeared and the print job disappeared from the Manage Print Jobs window. Nothing came out of the printer and its display said "Ready to Print" throughout the entire process. So where did it send the print job? (CUPS is properly configured - just now I printed a document from OOo.) Oh, and I was also monitoring the ethernet and no bytes were sent anywhere during the process. And why is an Adobe product using Ghostscript, eh? And pdftops? Too cheap to write their own software? I also tried sending the print job with lpr, but without the -l option. This time top reported that pdftopdf was running and consuming a lot of CPU time. I watched it until pdftopdf disappeared, However, this time the print job did not disappear from the Manage Print Jobs window. The printer still never received a signal and the network device manager reported zero bytes going out during the process. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
