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.

  • What printing system are you using (lpr, LPRng, CUPS, other)? What does the printer support — the solution may be as simple as switching to the same protocol Windows was using? Commented Nov 11, 2012 at 0:32
  • I mistook the model number originally, my apologies it is a Xerox 4127. I am using lpr with the following driver: Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.8-pre1. According to the Xerox website lpr is the only option on Linux for that printer. They provide specific drivers for Windows and Mac, though.
    – Yardboy
    Commented Nov 12, 2012 at 19:42
  • Just to check, what does nmap printer.ip.add.ress report? Commented Nov 12, 2012 at 23:03
  • Host is up (0.050s latency). Not shown: 993 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 139/tcp open netbios-ssn 445/tcp open microsoft-ds 515/tcp open printer 631/tcp open ipp 9100/tcp open jetdirect
    – Yardboy
    Commented Nov 13, 2012 at 1:18
  • We may have a way through. It appears that the printer itself can actually run as an LPD or IPP print server, so we turned those on and are going to test tomorrow and see if that gets us over the hurdle. I'd appreciate any thoughts you still have, though.
    – Yardboy
    Commented Nov 13, 2012 at 1:21


You must log in to answer this question.

Browse other questions tagged .