Fedora Users — Re: Tackling a shared USB printer (linux -> WXP)

Brion Swanson wrote:

Jeff,
Thank you for your very informative (and cool-headed) explanation of linux printing. If I had more time (I'm a little pressed right now, unfortunately) I'd read the CUPS and Printing HOW-TOs cover to cover and hopefully extract what you just distilled for me.

You are quite welcome.

I suppose it's partly the Windows indoctrination that has occurred to me
over the years and partly a frustration at what appeared to be a common
problem among newsgroups but without a well-known solution.

Since I have three types of systems trying to access this printer (Windows,
Linux, Mac), I will set up two queues: one postscript, one raw, and see if I
can get all the systems to talk to the printer successfully (so far I have
the Windows machines happily spitting binary data at the printer, and linux
happily using the normal postscript drivers on a separate queue -- I'm not
sure why the Mac has decided to stop printing.  Should I be using IPP,
Windows Printing, or LPD as the protocol for the Mac?)

Sorry, but I don't do Mac. Someone else will have to answer here. At a *guess*, I would say Mac likely does like Windows in that it may be able to use the raw queue for that, but also likely needs something such as IPP for the connection. Anyone able to assist him here?

Thank you again for your explanation.
Brion
----- Original Message ----- From: "Jeff Vian" <jvian10@xxxxxxxxxxx> To: "For users of Fedora Core releases" <fedora-list@xxxxxxxxxx> Sent: Tuesday, May 04, 2004 7:59 PM Subject: Re: Tackling a shared USB printer (linux -> WXP)
Brion Swanson wrote:
It seems to me that the printer is hooked up to a single machine - i.e. presumably a machine that only runs one operating system at a time - or
it's

hooked up to a hardware print server. In either case, the interface

through

which the printer receives its data should be of one type. In other

words,

when I - as the software printing driver - talk to the physical printer,

I

use only one language to talk to that printer -- the most appropriate

common

language. All other devices that want to talk through the printer must

go
through the printer driver -- a single printer driver.
The concept here is that window refuses to queue a file before it is
processed thru the driver for that printer. If spooled raw it will not
print properly, EVER.
If I set up a printer in Windows and shared it, I don't believe I'd need
to

set up multiple versions of the same printer, one for each different OS

that

uses it. Windows would configure one printer, with one driver (the Canon driver in my case) and then other computers would talk to Windows to

print,

not to the printer directly. In which case, I only need the driver that works with windows to be loaded and possibly some translation software to convert, say, a stream of bytes into something the printer will

understand.
This is wrong in concept but right in queueing.
If you have a printer on an XP machine and are sharing it with a 98 machine they both have their own version of the driver for that printer (for many printers) and each sends the file preformatted to the print
queue.

The biggest difference is when the file gets queued. By default a file to be printed on linux is spooled. Then when it is despooled for printing it is handed off to the printer driver for the formatting that is printer specific and streamed to the printer. This means the queue is set up specifically for each printer because the queue config knows what driver to hand the job to for formatting And if I want, I can use different drivers for the same printer -- postscript, non postscript, PCL, or otherwise depending on the abilities of the printer and my wants. I just set up a different print queue for each type handling I

want.
On Windows, the file is formatted (and binary) before it is spooled to
the queue (raw on Windows as well as on Linux).
With these differences it is important that the linux queue knows what
type file it is receiving.  Preformatted or Raw.
I agree it's logical to have one queue for each device that needs a
different driver, but managing 'n' number of queues for a single printer
because I have 'n' number of different OSes, each of which talk to the
printer in a different language is, if not difficult at least annoying.
Think of the linux print queue as doing the job the windows print
drivers do before spooling.
The file spooled is raw, usually much smaller than the formatted file,
(and often saves a lot of space) as well as making a single point in
time where the formatting occurs  (exactly when needed). After the
driver manages the formatting the file is now binary and streamed  to
the printer.
I want to set up the printer locally in linux, then tell the rest of the world, "Hey! I have a printer you can use if you want to talk to it
through
me!" and have that be it.  It doesn't seem like such a difficult task.
Other operating systems do it - why not this one?
If you change the way linux spools the print files so they are
preformatted before spooling then ALL print sources would be able to use
a raw print queue. In the present setup, the printer drivers do not even
touch the file until it is despooled for printing.
The raw print queue is functionally identical to the print queue in
Windows.  It receives a (binary) file to be spooled and sends it to the
printer without doing any other processing.
Sorry this turned into a little rant, but it just bugs me that this "thousand-queue" solution is the best thing linux has to offer when
sharing
a USB printer with other operating systems.
Brion
This is not difficult.  When sharing with linux machines you have a
choice on the sending machine of  preformatting and sending to a raw
queue or sending it raw an using a printer specific queue on the print
server.  The same choices are (theoretically) available whether you are
providing services for Linux workstations or Windows (except Windows
does NOT allow the choice.  It MUST be sent to a raw print queue).
OTOH, the concept of the print queue providing the driver formatting on
*nix goes a little deeper.  It not only saves space in a print queue,
but it also meens the workstations being served do NOT have to even
install a printer driver and do not care what printer their job is sent
to. (I know, this is a carry-over from when workstations were dumb and
drive space was at a premium;  But the idea is still sound)
----- Original Message ----- From: "Jeff Vian" <jvian10@xxxxxxxxxxx>
Why does it seem wrong.??
The os being used to print (windows), preformats the printer output so
it is correctly printed.  Thus it needs to be streamed to the printer
via a "RAW" queue that gets no further processing.
Linux also needs to format its output for the printer, so it cannot use
the raw queue but needs a different path that does process the output
and prepares it for the printer.
This seems very logical to me.
BOTTOM LINE: flexibility. Windows is not, Linux is almost limitless.
Tailor it as you see fit.
A few seconds spent in planning and configuration provides a lot of
later flexibility.
If you do not like the flexibility options of windows why not get a
network print server appliance and remove the printing from Linux
totally?  Then every station would have to send files to the printer
exactly the same - preformatted and all.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list