[Tfug] ethernet to USB?

[Michael Salivar]

Ok, so it sounds like LPRng and Samba will probably do everything I'm looking for, now I just have
to do enough research so that what you said actually begins to make sense.  The software and
network side of printing really isn't my strong suit going into this, which is one of the reasons
I'm making the proposal.  The other being that our network runs like crap.

Anyway, thanks for the long reply, it was very helpful.

And if anyone has any thoughts on networking random USB devices on an SMB network, I'm all ears.  I
can kind of see how it might be done, but I have no idea if it exists.

On Sat, 02 Jul 2005 01:43:19 -0700
Stephen Hooper <schooper at email.arizona.edu> wrote:

> Do you need to have a printer driver to spool for it, or can the 
> server just pass jobs on without understanding them?
> 
> Short answer:
> 
> No, and Yes.
> 
> Long answer:
> 
> I work for the University of Arizona at CCIT, and just happen to have
> the incredibly unfortunate job of managing "printing" for our Production
> Systems, Mainframe, and U-System.
> 
> CUPS was told to you as an option, but IMHO the biggest selling point of
> CUPS is that provides an easily configurable printer environment for a
> desktop.
> 
> Most of the features that really sell CUPS would be useless to you, and
> may actually make it more difficult for you to print if you are just
> trying to use the "smarts" that your printers have.  
> 
> For example: last time I looked PostScript is ripped into PostScript
> using CUPS (seems silly read out loud, but actually makes a good amount
> of sense from CUPS's point of view).  I don't think that has changed,
> and that CUPS just leaves the passed  PostScript alone (the tacked on
> PPD file support of CUPS, pretty much guarantee that it can't if I am
> thinking correctly).
> 
> You can check this by writing a simple PostScript file that defies one
> of the options that CUPS supplies (for example (and my PostScript is a
> bit rusty (especially my DSC))):
> 
> %!PS-Adobe-3.0
> %%DocumentMedia: Plain 612 792 75 white ()
> 
> %%BeginDocument
> 
> %%BeginSetup
> <</Duplex true /Tumble false>> setpagedevice
> /Helvetica findfont 20 scalefont setfont
> %%EndSetup
> 
> %%Page: Hello
> 8.5 72 mul 2 div 11 72 mul 2 div moveto (Hello) show showpage
> %%Page: Goodbye
> 8.5 72 mul 2 div 11 72 mul 2 div moveto (Goodbye) show showpage
> %%EndSetup
> 
> %%EndDocument
> %%EOF
> 
> Set CUPS to Simplex the job, and print the job.  If CUPS messes with it,
> you  should get simplex, otherwise  you should get duplex.  Of course,
> my DSC'ing may mess that up.
> 
>  
> Anyways, that works great for a desktop machine, but it is not so great
> when you start accepting jobs from clients that don't understand how to
> pass those options to CUPS.
> 
> The printers at CCIT use LPRng as their "print" server.
> 
> I set that up, and for a couple of reasons.  The main advantage to me
> was that it was a very easy configuration to run in guaranteed "pass
> through" mode.
> 
> So for example you can throw anything at our queues, and we will pass it
> to the printers.  PCL, PDF, PostScript, Word Documents, etc. 
> 
> For us that is kind of a problem... every now and then we have people
> throw unsupported data at the printers (Word documents are not
> understood by most printers).  However, I think that this is  better
> than what we had before: thirty-two different queues to specify
> different print options (two-up,four-up, border, two-up with border,
> etc.), and the fact that people don't really understand how to change
> documents with a2ps should in theory lead to me meeting hot women :}
> 
> The LPRng based solution with a pass through configuration:
> 
> printer:
>     :af=/var/spool/lp/%P/acct
>     :lf=/var/spool/lp/%P/log
>     :ps=/var/spool/lp/%P/status
>     :sd=/var/spool/lp/%P
>     :rp=raw     
>     :rm=192.168.17.101
> 
> 
> Which is all it really takes to do printing using the printer, instead
> of printing with pre-RIP-RIP (example for an HP).
> 
> Then, you could use Samba to set up a Windows printer share:
> 
>  [global]
>  ...
>  ...
>  lpq command = /usr/local/gnu/bin/lpq -P%p
>  lppause command = /usr/local/gnu/bin/lpc hold %p %j
>  lpresume command = /usr/local/gnu/bin/lpc release %p %j
>  lprm command = /usr/local/gnu/bin/lprm -P%p %j
>  print command = /usr/local/gnu/bin/lpr -P%p -r
> 
>  [printer]
>  guest ok = yes
>  guest only = no
>  printable = yes
>  available = yes
>  writable = no
>  printer = ps
>  path = /var/spool/lp/samba
>  public = yes
>  create mask = 0700
> 
> 
> Or, you could just tell your Windows clients to talk to the LPD server
> on the UNIX machine.
> 
> 
> On RIP (as an aside to Adrian):
> 
> For me the RIP is a Raster-Image Processor.  It takes the Page
> Description Language, and converts it into raster scans (TIFF files in
> my case), which then get passed to the "MIP".
> 
> The MIP is the Marking Image Processor which acts a buffer between the
> Raster Image it is receiving, and the SCSI commands (or whatever) that
> make the laser turn on at point X, turn off at point Y, move the drum,
> etc. That goes way beyond me.  
> 
> The RIP too is actually a ways beyond me.  In my case the RIP is Kodak
> software sitting on a Solaris machine sold by IBM as the front unit  to
> the MIP that talks to their printers.  The most that ever happens there
> is that sometimes CE's need to get in, and monkey with getting the RIP
> software to allocate more memory.  
> 
> In other words, GhostScript is a RIP.  It can convert PDL's, into raster
> graphics.
> 
> 
> _______________________________________________
> tfug mailing list
> tfug at tfug.org
> http://www.tfug.org/mailman/listinfo/tfug