In the hopes that a Scribus user may be able to help, I am posting my problem here, although the problem happens with all PDFs, not just those created with Scribus, so it's not really a Scribus issue.
Platform is Ubuntu Dapper amd-64. Printer is HP Laserjet 8000DN. I use this printer as a printing press. The printer has just about every option, including input capacity of 3,000 sheets and output stacker that will hold 3,000 sheets. Its rated speed for duplexed printing is 22 ppm. When printing from Adobe Reader on Windows it prints the first copy at about 15 ppm and subsequent copies at 21.8 ppm. I can tell it to print 100 copies of a 500-page book collated and it will spend the next several days doing so. All I have to do is add/remove paper every few hours. I am printing short run textbooks from PDF files. Ultimately I plan to switch to Scribus for layout, but I will still want to export to PDF and print from the PDF files. The printer has a feature common on modern high end lasers -- "RIP once, print many." When you add sufficient RAM (or a hard disk) to the printer, the printer will image each page of a print job and hold that image internally. Thus, the first copy may print slowly, as each page must be imaged, but subsequent copies will print at the rated speed of the printer. I am unable to do this satisfactorily from Linux. If I print from Adobe Reader, either the Linux version (7.0.8) or the Windows version via CrossOver Office (7.0.5), I have two options. I can use an lp or lpr command and insert -n or -# to the command, or I can use the print dialog box to specify the number of copies and check the Collated box. If I use the lp or lpr command it does not access the "RIP once, print many" feature. It will print the specified number of copies and they will be collated, but each copy will print at only about 15 ppm because it must re-image the job for each copy. I have read all the documentation I can find on the lp and lpr commands, but I cannot find a way to tell it to use "RIP once, print many." Furthermore, if I shut down the computer (a laptop), the print job ceases, because evidently the lp or lpr command is sending the job over and over again for the specified number of copies. If I use the print dialog box it will concatenate individual print jobs into a massive spool file. Again, I cannot shut down the computer without stopping the print job, and it must re-image each copy, and in addition I need space to hold a spool file of several GB. If I use Kpdf it works properly, that is, it prints with "RIP once, print many." This is an important fact, because it means that accessing this feature from Linux must be possible. Kpdf is using the drivers I have installed via CUPS using the latest PPD file. However, when I use Kpdf it prints the first job glacially slowly -- about two minutes per page. So if I tell it to print 100 copies of a 500 page book, it will take all day to print the first copy (about 12 hours), although the remaining 99 copies will print at about 23 minutes per copy. If I could figure out why Kpdf is so slow on the first copy it would solve my problem. I have googled and searched everywhere, and I have posted a question on the KDE forums, but have not received any answers. Hence my interest in the other thread where Ghostview was mentioned. However, it only uses an lp or lpr command, which I cannot get to access "RIP once, print many." If anyone has any suggestions, I'd love to hear them. I'd love to be able to ditch Windows completely.
