Tackling a shared USB printer (linux -> WXP)

[Jeff Vian]

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 at charter.net>
>To: "For users of Fedora Core releases" <fedora-list at redhat.com>
>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 at charter.net>
>>>
>>>
>>>      
>>>
>>>>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 at redhat.com
>>To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>>
>>
>>    
>>
>
>
>  
>