[Tfug] ethernet to USB?

[Stephen Hooper]

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.