Translating lpd administration into CUPS

[Anonymous]

I'm trying to figure out how to do with CUPS a bunch of things I'm
used to doing with lpd/lprng.  This is hampered by my lack of a clear
conceptual model of what CUPS does internally with the bits I send to it.
I've read all the admin guides, but I'm not sure which config files are
consulted when for what information to make which decisions in what order.

I'm used to having an elaborate processing echeme involving magicfilter,
ifhp, and possibly smbclient to send a print job to an HP printer attached
to someone's Windows box.  I know how to configure magicfilter to covert
a variety of inputs to a format the printer speaks.  I know how to configure
ifhp to add options like duplexing, and to display useful messages on the
printer while it's printing.  And I know how to point smbclient at
the right machine.

I'm used to setting up a variety of named logical printers with different
options to cope with a varity of needs.  For example, I usually export a
"raw", a "cooled" and a "dos" version of each printer.  The former is for
use by Windows machines with a full-featured on-board print driver that
has already done all the heacy lifting.

The cooked one is for all the lpd clients I have to support that don't
have massive format-conversion locally.

And the dos version is a lot like the cooked one, but knows to use cp-427 for
plain text, so the old DOS software still in use has line-drawing characters.

I can't see how to do that sort of thing in CUPS.  Hell, I can't see how to
create an alias printer (I have a couple of legacy printer names that have
to be supported as aliases for current ptinters), except my making a class and
making the alias taget the only member of the class.

Or am I supposed to make a second printer with the same device URI?
Can I do that without causing problems with things like
parallel:/dev/lp0?


First of all, let me just check an understanding I have.  The following
is what I believe; if it's wrong, please tell me:
- Foomatic is a rasterizer.  Its job is to convert the input format
  (usually PostScript, but sometimes pdf or text) to a printer-specific
  output format.
- Because of the large clientele using cheap consumer inkjet printers,
  foomatic is given a great deal of prominence in the setup instructions.
- If I have all native PostScript printers and am submitting PostScript
  to the print queues, then foomatic isn't used.
- When I say "not used", I mean I could delete the executable or replace it
  with a stub like "cat".  It doesn't even check the PostScript for validity.


I realize that CUPS has support for smart clients that can set a lot
of options themselves, but I have a large population of lpd clients that
do things based on queue names, and I'm not sure how to port that forward.

Printer capabilities seem to be expressed in PPD files, which is file
for PostScript (the PPD file includes the snippets of PostScript you
need to include to switch features on and off), but I'm not clear on how
that applies to hative handling of other formats (e.g. PCL and PJL).

How do I tell CUPS how to insert instructions into a PCL file to staple
in groups?  (HP is selling the HP Q2443A - 500 Sheet Stapler/Stacker
for $99.00 right now.  Should be $250, but we called and got it for that
price.  Received it on Tuesday.)

I'm sure CUPS has dealt with this issue before and I'm just not seeing the
true beauty of the configuration system, but primitive me, stuck in my
:if=/usr/local/bin/script: mindset, has so far failed to grasp it.

Thanks for any enlightenment.