On Sunday 07 January 2007 17:23, John Jason Jordan wrote: > 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. > _______________________________________________
I don't know much about this but I think you should inform the hplip developers about that issue. Your printer is supported by the project so I it won't be a problem. http://hplip.sourceforge.net Regards, Ludi
