Brian writes: > The question is whether the gray bar is an artifact produced by CUPS > (unlikely), by cups-filters (possible, but unlikely), the Gutenprint > driver (could be) or the printer (one never knows). Or it could be > part of the original file. We assume the file is something produced by > a text editor, vim etc.
The file is: qwertyuiop asdfghjkl Produced by vi. > Your printer is a PostScript printer. Obtain the URI of the parallel > port with > lpstat -v Ok: toncho/~ lpstat -v device for HPLJ5: parallel:/dev/lp0 > and set up a print queue with > lpadmin -p HP5M-test1 -v <URI> -E -m drv:///sample.drv/generic.ppd Ok: toncho/~ lpadmin -p HP5M-test1 -v parallel:/dev/lp0 -E -m drv:///sample.drv/generic.ppd > Print with > lp -d HP5M-test1 <text_file> Ok: toncho/~ lp -d HP5M-test1 text Second LED comes on, first LED blinks a few times, second LED goes off. Nothing prints, though the Cups Web interface says it did. > You could also try > lpadmin -p HP5M-test2 -v <URI> -E -m lsb/usr/cupsfilters/textonly.ppd Ok: toncho/~ lpadmin -p HP5M-test2 -v parallel:/dev/lp0 -E -m lsb/usr/cupsfilters/textonly.ppd toncho/~ lp -d HP5M-test2 text Produces same result as above except that both LEDs stay on. I wrote: > There is no difference in using lp or lpr. > ... > Yes. That's unimportant. Brian writes: > Not for the people who think there is a significant difference. In this context it is unimportant. The requirement is to type "lpr filename" on a workstation and have the file print correctly regardless of whether it is a pdf or plain text. Works now but only for pdfs. I have no need to print directly from the server: its function is to provide a parallel port. -- John Hasler jhas...@newsguy.com Elmwood, WI USA