On Wed, Feb 12, 2003 at 02:37:01PM -0500, Thomas H. George wrote:
| Progress Report:
|
| Wimp came home.
|
| Following a suggestion in the "Sharing a printer with SAMBA"
| string, I put "load printers = yes" in the [global] section of
| smb.conf. Next, I told wimp to add a network printer and, in
| the appropriate box, typed
|
| http://Phoenix:631/printers/lp
|
| and wimp asked for and I entered my regular user name and
| password. After a brief delay, wimp asked for printer
| information and, after I selected HP and DeskJet 940c, announce
| the printer was installed and available.
Beautiful, almost.
| I tried sending a line
| of text from MSWord and it seemed to be transmitted but nothing
| was printed. Checking /var/log/cups/log.phoenix I found:
|
| auto-typing file
| unsupported format 'application/octel stream'
| sending error:
| client-error-document-format-not-supported
Precisely. CUPS (and many unix-dsigned systems) use a thin-client
architecture. Microsoft is extremely fond of fat-client
architectures.
The Windows/SMB printing system requires each and every client to
locally convert the data from an abstract canvas to the datastream
required by the printer. That is just a horrible configuration
management nightmare on a LAN of any size -- each client must be
(re)configured for each printer and any changes must be repeated on
each client. The server in that environtment doesn't do any data
processing apart from queueing and then directing the data at the
proper device (eg "LPT1" if a windows server is sharing a parallel
port printer).
The CUPS layout pushes all the data format conversion to the server.
The client doesn't need to know a thing about the printer. Instead
the client merely tells the server what is has (in MIME notation) or
the server guesses based on magic numbers. The server then constructs
a filter chain to convert from the given ("abstract canvas") data to
the printer's protocol.
What you are seeing is a bad mix of the two. The MS box is converting
from the abstract canvas to HP Deskjet protocol, then CUPS, first of
all, doesn't know what HP Deskjet protocol data is and thus doesn'
know how to convert it to HP Deskjet protocol.
Depending on specifically what you want you have two options :
Option 1)
Use the MS fat-client architecture letting the Windows driver
control specifically how the result will appear. To do this you
need to tweak cups to allow "raw" data to be fed directly to the
printer device. This is done by (IIRC) uncommenting the
"application/octet-stream" line in /etc/cups/mime.types and
uncommenting the filter with the same type in
/etc/cups/mime.convs.
(or create the queue as a "raw" queue, not an "HP Deskjet XXX"
queue)
Do note that this option could become a support nightmare because
your debian machine and "wimp" will more than likely produce
different results at times because they use different drivers
developed by different groups. For example, my dad has an old
Canon BJC-610. ghostscript generates nice a BJC datastream that
prints correctly. Various "compatible" windows drivers (that are
network-aware, the canon one predates SMB) produce varying degrees
of output ranging from wholly dysfunctional to not-quite-right
color.
Option 2)
Use the CUPS thin-client architecture, letting the driver on the
debian system control specifically how the result will appear. To
do this change the driver on the Windows client to one that
generates data CUPS knows how to handle. For example, I often use
the "HP Laserjet IIIp Postscript" driver to make windows generate
postscript which cups then converts to PCL (for my printer).
Since my printer(s) are B&W only this works well. Unfortunately
that windows driver converts color to grayscale, thus you won't
want to use that driver for a color printer. The last time I
tried with the HP ColorLaserjet Postscript driver the postcript
windows generated was really weird. CUPS didn't find any pages to
print, but 'gv' would render it correctly. If I used gv to
regenerate the postscript (by printing marked pages) it would
work. If you try this option, let us know which printer model to
pick to get functional postscript with color from windows.
HTH,
-D
--
"Don't use C; In my opinion, C is a library programming language
not an app programming language." - Owen Taylor (GTK+ developer)
http://dman.ddts.net/~dman/
Attachment:
pgpjfr1KT7qj0.pgp
Description: PGP signature