Peter l Jakobi wrote:
On Tue, Sep 29, 2009 at 11:48:07AM -0400, Bowie Bailey wrote:
I set the printer type as raw and then restarted cups just to make sure the change was active. No effect. Still have the delays.
Avoid cups for a quick test:
2 ways:
- get the lprng rpm and extract lpr and lpq to a
directory, both should be usable even with little to no configuration aside the normal host printing setup. The nice effect: things like lprng -Plj@host just work, without adding queues, discovery and other annoyances.
- just ftp the file to the printer (maybe newer jetdirect
cards also support things like ipp / http as well?).
The 2nd method at least reduces the components being tested to the raw network connection between two boxes.
And of course, effects due to funny things being printed (testing with multiple printers and having one set of tests print a single file run thru gs to produce pcl-3 or higher may be a good way to detect funny postscript like strange font embedding (e.g. from the application/library/... on a badly configured client), or full color for a black&white laser, etc).
I'm not sure avoiding cups would be useful. The problem seems to be with cups getting the print jobs from the queue to the printer. Once the printer finishes a job, it takes cups about 15 seconds to realize that the printer is available for the next job.