On Fri, Mar 12, 1999 at 02:08:40PM -0600, Paul Sack wrote:
> Thanks for the help. But it still doesn't work. lp is in
> /proc/devices now (post-kernel-recompile). But I still get
> warning: no daemon present, even though I am pretty sure it is
> present from manually stopping and starting lpd from the script
> in etc/rc.d/init.d. Where could I look at the logs for starting
> and stopping the daemon. I think maybe that would indicate the
> problem. I have been printing in windows (the only reason i
> booted into windows), so it's not a physical problem. ls -l
> /dev/lp* produced the same results as on your computer, btw.
> There is no lp* in /var/logs. My .config looks like yours
> except that I have CONFIG_PARPORT_OTHER set as well. (I have a
> parallel zip drive that I'd like to install after I get the
> printer working and I thought there was a possibility I would
> need to have that option set and the help in the config
> indicated it couldn't do any harm.)
Geez, I'm sorry, I meant to answer you on Friday, but I forgot
when I got home.
Please forgive me if I say something that is already obvious to
you. I'm not sure what kind of linux background you have.
The next thing you probably need is an entry in /etc/printcap.
Here is what I use at home:
# HP Laser jet 4P
lp|ps|hp4p:\
:lp=/dev/lp0: \
:sd=/var/spool/lpd/lp: \
:mx#0: \
:sh: \
:ff=:
"man printcap" will tell you about the fields that are not
obvious in this entry. Here's what I get from running the
command "ls -ld /var/spool/lpd/lp":
drwxrwsr-x 2 root lp 1024 Mar 16 09:54 /var/spool/lpd/lp
Now here is the catch. Unless you bought a real nice printer,
it probably doesn't support printing postscript documents. But
lots of documents you print from Linux are liable to be
postscript documents. Linux does not subscribe to the same model
for printing that Windows does. In Windows, every printer
manufacturer is free to use their own printing language, and
either Microsoft, or more often the printer manufacturer, writes
a Windows driver that provides a consistent API to programs like
Word and Excel.
In Linux, the consistent interface is provided by the printing
language itself, postscript, not the driver. So what do you do
if your printer does not understand postscript? Use Ghostscript.
In debian I think the package name is just "gs". Ghostscript
understands many different printer languages, and can transform a
postscript document (created in LaTeX, or LyX, or StarOffice, or
WP for linux I think) into a PCL document for an HP printer, or
some other language for another type of printer. If my printer
didn't support postscript, the printcap entry above would have
one extra line, and look like this:
# HP Laser jet 4P
lp|ps|hp4p:\
:lp=/dev/lp0: \
:sd=/var/spool/lpd/lp: \
:mx#0: \
:sh: \
:ff=: \
:if=/var/spool/lpd/lp/filt:
the "lf=/var/spool/lpd/lp/filt" line names the script through
which a printed document is filtered en route to the raw printer
device (in this case /dev/lp0). And my /var/spool/lpd/lp/filt
script would look something like this:
----------- begin /var/spool/lpd/lp/filt -----------
#!/bin/sh
#
tmpfile=`/bin/date +/tmp/lpjob.%b%d.%H%M`
errfile=/var/spool/lpd/lp/filt.err
cat - >$tmpfile 2>$errfile
gs -q -dNOPAUSE -sDEVICE=ljet2p -r300 -sOutputFile=- \
$tmpfile 2>>$errfile
rm -f $tmpfile 2>/dev/null
----------- end /var/spool/lpd/lp/filt -----------
You may need to change the DEVICE flag to gs if you have a
different kind of printer. And you can do a "man gs" to
learn about various other gs options if you need them.
I realize printing is a bit of a mess in Linux. At least for
now. The problem is that every printer manufacturer out there
develops software for Windows when they create the printer, so
the Windows world gets to use the printer without any development
effort required from Microsoft. But the printer manufacturers
(and video card, network card, etc. manufacturers) don't write
any software for Linux, so the Linux community itself has to take
up the slack. Hopefully as Linux becomes more mainstream the
hardware makers will recognize Linux enough to support it.
Anyway, if you still have problems, I'm happy to help. Oh, and
sorry this was so long. I erred on the side of too much info,
just in case.
later,
- rick
--
Richard Kilgore | [EMAIL PROTECTED]
Electrical & Computer Engineering | http://lore.ece.utexas.edu/~rkilgore/
The University of Texas at Austin | (512) 471-8011
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
