I have a ruby/rails web application, one action of which sends PDF files that have been generated by the app to a Xerox 4127 printer on the network. This is accomplished via shelling out and running multiple lpr commands (to default print queue, using -s to prevent spooling copies and -o InputSlot to identify the tray). The PDF's cannot be combined into one single doc/printjob because they are sent to different trays depending on file specifics and the color of paper needed. A "cycle" might consist of 15k or more pages, sent to the printer in batches of 20 or 30 up to several hundred at a time.
I set up the printer on the server as an lpd queue with the generic pcl 6 gutenprint driver. Xerox does not provide a Linux driver, but says it will work with lpd/lpr. And it does - I am able to send documents successfully, both manually from the command line and via the web application.
This process was prototyped as a Windows program in Foxpro. The prototype generates a PDF for each page of the batch and sends it as an individual print job. Because the printer has a metric butt-ton of memory, the prototype just dumps job after job to the printer and allows the printer to manage them all, which it does very well. A batch of several hundred pages/print jobs queues into the printer almost immediately and the printer spits them out with little pause as if they were part of one giant document.
My web application actually combines pages that are destined for the same tray one right after another into a single PDF, so I actually expected things to be faster, but they are not. By an order of magnitude, the process is much slower. A "cycle" that would take 8 hours to run in the prototype takes several days to get through in the web app.
What appears to be happening is that the print jobs are not "dumping" to the printer like they do in the prototype. Monitoring the printer through it's onscreen utilities, we only see one print job showing up at a time. The print queue on the server seems to be waiting to send each print job until the printer signals back that the prior job is complete. As such, instead of everything spitting out constantly as if one document, we get a page, then a pause while the next file comes in, then a few pages, then a pause, then a page, then a pause, etc.... you get the idea.
Is the print queue on the server actually waiting for the printer to say "done"? If so, is there anyway for me to configure it to just send, send, send and not wait for comms back from the printer?
Two notes: the server is in another building, but we did some testing with a machine on the exact same sub-net as the printer and saw no measurable improvement, ie does not seem to be network related. Likewise, I'm aware that lpr is converting the PDF documents to postscript before sending, so I pre-converted them and tested the process without that. Some improvement in the queuing process at the server, not terribly significant, but no impact on the fact that only one job is going to the printer at a time, which I believe is the root problem.