Subject:
Re: New submission: Printing with Debian and Windows Mini-HOWTO
From:
"Kurt Pfeifle" ####@####.####
Date:
6 Apr 2003 19:54:16 -0000
Message-Id: <3E908804.1080008@danka.de>
Ian Ward wrote on ####@####.####
> Hello,
>
> I have posted a new Mini-HOWTO about configuring Printing in Debian
> GNU/Linux that I hope will be considered for addition to tldp.org.
> It is located at:
> http://excess.org/docs/debian_windows_printing.html
>
> My HOWTO covers using shared Windows printers, sharing printers to
> Windows PCs and local printer configuration. Unlike the existing
> printing HOWTOs, it focuses on the CUPS print spooler, and gives
> troubleshooting examples that suggest ways to track down problems.
>
> I hope to expand the document to include instructions for other
> distributions and troubleshooting for other types of printers and
> Windows shares, with help from others. The document is currently in
> LaTeX format, but I would be able to convert it to SGML.
>
> Thanks for your consideration.
>
> -Ian Ward
Hi, Ian,
I've had a quick read thru this and here are my comments:
You (wrongly) reduce the printer "driver" to a PPD. Actually
the PPD is only working correctly if it is accompanied by the
correctly installed "filter". (There are no filters needed
for PostScript printers.) The required filter will be named
in the PPD header, on the line beginning with the "*cupsFilter"
keyword. In many cases this will be "foomatic-rip". foomatic-rip
(or its predecessor, "cupsomatic") are only wrapper scripts
around ghostscript. So you need ghostscript installed.
You recommend the wrong ghostscript package. For Debian you
need to use the gs-esp (or is it "esp-gs"?) version. This is
ESP Ghostscript, containing the "cups" device. (ESP Ghostscript
may be used in all other print and spooling systems too). Without
ESP Ghostscript, you may not be able to print to Gimp-Print driven
and some other printers. (You are likely to be able to print
with the foomatic-rip, though. But it needs to be Ghostscript
7.05.x).
This command is wrong:
"lpadmin -p Laser -i parallel:/dev/lp0 -P /root/laser.ppd"
It should read
"lpadmin -p Laser -v parallel:/dev/lp0 -P /root/laser.ppd"
You wrote: "You may view the printer queue and check the printer
status with the command lpq." -- With CUPS it is better to use
"lpstat -o" and "lpstat -p". "lpq" is only there for backward
compatibility. "lpstat" is more powerful.
You name the command
"lpadmin -p RicePrinter -i smb://rice/INKJET -P /root/inkjet.ppd"
This is largely correct (you again did use "-i" instead of "-v"),
but I would suggest that you lat your reader check if there is a
"smb" backend available at all:
"ls -l /usr/lib/cups/backend/smb"
If it is not there, it should be created by root using
"ln -s `which smbspool` /usr/lib/cups/backend/smb"
The section where you quote the smb.conf file is plain wrong.
Please read "man smb.conf" and the printing chapters of the
Samba-HOWTO-Collection (use the latest 2.2.x versions, please,
not the ones you find in the outmoded Debian package:
http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection.html
http://de.samba.org/samba/docs/man/smb.conf.5.html
http://de.samba.org/samba/docs/man/smb.conf.5.html#PRINTCAP
To be more specific about your mistakes:
printcap name = lpstat
# With CUPS, use "printcap name = cups". (See also "man smb.conf")
# Also, make sure that in "cupsd.conf" there is a directive of
# "Printcap /etc/printcap" set.
printing = cups
security = share
# "security = share" should not be used unless it is absolutely
# necessary. Use "security = user" (or domain) instead.
print command = /usr/bin/lpr -o raw -P%p -r %s
# *If* you set "printing = cups" and *if* your smbd is compiled
# against libcups (check with "ldd `which smbd`" -- then Samba knows
# how to print to CUPS and no manually print command will work.
# If Samba has no CUPS support compiled in, then the setting of
# "printing = cups" is useless. *If* your Samba *does* have CUPS
# support compiled in, but you desparatly want to use your
# own print command, then use "printing = sysv". (But then you
# are responsible for all the printing settings and you need
# correctly defined commands all over...
You say: "The most important part of this configuration file is
the last line. It tells CUPS not to attempt to filter the documents
sent to the printer. This is necessary because documents sent by
Windows PCs have already been formatted for the destination printer
by the Windows printer drivers."
This is true. But it still will not work for most people!
All these jobs are likely to get tagged as MIME type
"application/octet-stream" by CUPS and as such are not allowed
for printing by CUPS per default. This is a security feature,
to prevent DoS attacks, where people might send binary data
to the jprinter. To allow the "-o raw" printing of binary
data (and this is what most Windows printer drivers produce),
uncomment the last lines in "/etc/cups/mime.convs" and
"/etc/cups/mime.types". (If you don't believe me, that this
indeed *is* a very common problem, please google for "unable
to convert file 0 to printable" or look it up at
http://www.cups.org/faq.php?20 )
You are repeatedly referring to "smbclient" in the context of
CUPS printing to Windows shared printers. This is wront. CUPS
printing in these cases is done by the "smbspool" utility,
symlinked to by "smb://" and shipping with Samba.
You say: "You should see a line that reads ``Scheduler shutting
down due to SIGTERM''. This indicates that the CUPS server was
restarted successfully."
This line does signify the *shutdown* of the CUPS daemon. A
successful (re-)tart is indicated by various other messages,
especially in "LogLevel debug"...
If you have any questions, don't hesitate to contact me. If
I can help, I'll do, depending on my time.
Good ressources are also here:
http://www.linuxprinting.org/
http://www.linuxprinting.org/foomatic2.9/cups-doc.html
http://www.linuxprinting.org/foomatic2.9/CUPS-Filter-Chart.html
Cheers,
Kurt
> On Mon, Mar 31, 2003 at 10:53:16AM -0800, Tabatha Persad wrote:
>
>>Thanks for your recent submission. Before we can review and publish
>>your material, we first ask that all new documents are brought to the
>>attention of the discussion mailing list ####@####.#### for up to
>>(but not more than) a week, to gather feedback from your peers. In this
>>way, any recommendations or info can be considered and any final
>>revisions made, if required.
