Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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? –  Gilles Nov 11 '12 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 Nov 12 '12 at 19:42
    
Just to check, what does nmap printer.ip.add.ress report? –  Gilles Nov 12 '12 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 Nov 13 '12 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 Nov 13 '12 at 1:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.