Process the printjob completely, then print--can it be done?

[Gary Carroll]

In article <31500-cups.general at news.easysw.com>,
 Dave Frantz <imperial_courier at yahoo.com> wrote:

> I have an Okidata B4250 printer on a FreeBSD 7.0 machine running CUPS 1.3.4. 
> The printer can easily print 30 pages a minute. However, when I try to print, 
> it prints far slower than this---the printer has to wait for each page to get 
> laid out by Ghostscript, so printing is a start-stop-start type affair. Is 
> there a way to get CUPS to process the entire print job _before_ printing? Or 
> is there a way to get Ghostscript to process the job faster?

I had an issue about a year ago where I was generating large raster 
files for multiple fast (over 100 pages/minute) printers using multiple 
Fedora (Core 5) boxes. Trying to debug very slow printing we discovered 
that the jobs were being rasterized quickly enough, but the Linux boxes 
were only sending to their respective printers at about 65 kb/sec. If we 
pointed them to a Windows print queue the data went at about 10mb/sec, 
The Windows box could send to the printer at 10mb/sec. 
We verified the problem was ³Linux to the model of printer² by testing 
various combinations of cables, routers, and intermediate print servers. 
We did not test different flavors of Linux (or FreeBSD). We did test a 
few other printers and the problem did not occur, but we liked the 
printer hardware for many other reasons.
A serviceable workaround was to have the Linux boxes built the raster 
jobs which were sent to a Windows box, which simply spooled and released 
to the printer as a front-end. This worked perfectly, and the cost was 
negligible compared to the printer. 
You may want to test and see if your problem is similar. 

Due to the constraints of time and being satisfied with the solution we 
never found out why the printers did not work properly with Linux. 
However, a cursory look at the traffic using Wireshark suggested that 
the printer had a flaw in acknowledging receipt of a packet that Linux 
interpreted as a failure and thus resent many, many packets. Windows did 
not think it was an issue.