Re: [SLUG] slow linux printing

From: Paul M Foster (paulf@quillandmouse.com)
Date: Wed Dec 18 2002 - 00:19:02 EST


On Tue, Dec 17, 2002 at 09:44:58PM -0500, Russ Wright wrote:

> I know this was discussed some time ago but I cannot find it. My linux
> box prints very slow. I'm running RH 8.0 and using LPR as it comes
> shipped. On average a page of plain text takes more than a minute to
> print. Same printer accessed by a pc running Windows 98 will do about 8
> pages a minute.
>
> Is there anything I can adjust or tweak to speed up this process?

Well... the Linux print subsystem typically works this way: You feed
your job to the lpr daemon. The /etc/printcap file is what regulates
lpr, and in that file there is an entry that dictates the "filter"
software that lpr uses. Two of the biggies are magicfilter and apsfilter
(my personal choice). The filter program tries to figure out what kind
of file this is, and do some conversions on it to make it suitable for
your printer. For example, most printers expect you to have a CR/LF
combination at the end of each line for straight text files. But
Linux/Unix use only a LF at the end of a line. So the filter program has
to replace the LF with a CR/LF combination. If your file is anything
beyond straight text, it may be converted to Postscript, the lingua
franca of Linux printing. Ghostscript is the usual tool that then takes
that file and sends it to your actual lpr daemon. But if your printer is
not natively Postcript compatible, ghostscript will have to translate it
into a form your printer understands.

Kind of like having to hand crank a Model-T. It works, but it's a pain.

I don't know that I'd call lpr "deprecated", but lprng and cups are
supposed to be superior for a variety of reasons. Given the description
above, you can see why Linux printing might be slow. I doubt lprng is
any faster; it's not that major a rewrite, from the viewpoint of
filtering. CUPS, I don't know.

On the other hand, though, straight text is no slower on Linux than
Windows, in my experience. This is particularly true of multi-page jobs.
Linux takes a bit to start, but it typically feeds bits to the printer
as fast as the printer will take them, once it starts printing. And
queued jobs will likewise roll off at full speed. Linux has far better
multithreading and multitasking than Windows.

What happens if you take a DOS straight text file (CR/LF, and you check
it with less first to ensure it has no extraneous non-text cruft in it)
and send it to the printer by:

cat myfile.txt > /dev/lp0

(You have to do this as root.) That should _immediately_ hit the
printer. If it does, then your filtering is the problem. For straight
text jobs, you could consider setting up a new printer in /etc/printcap
that does minimal filtering (probably only CR/LF). Then, instead of

lpr -Pmylaser myprintjob

(where "mylaser" is the printer name from /etc/printcap) you would do

lpr -Pminimalfilter myprintjob

HTH,

Paul



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:30:19 EDT