CUPS
We’ve mentioned before that CUPS was based on the Internet Printing Protocol (IPP), which it
is hoped will become a cross-platform standard for network printing. CUPS also provides
some additional advantages besides just those presented by IPP.
The designers of CUPS have gone to great lengths to make it easy to use and easy to
transition to. Administration is simplified through the use of a web-based front end to server
configuration (although third-party GUI configuration tools exist as well) and clients often
need no configuration at all. Printers are discovered automatically when possible. From the
client’s view of printing, CUPS will emulate many of the tools you’ve become used to under
lpd-style systems (or System V, if you’ve worked with that elsewhere).
CUPS introduces the concept of classes, which allow you to send a print job to a group of
printers, and have it printed on the first available machine in that group. This approach to load
balancing and failover is carried further with implicit classes, which allow multiple servers to
address the same physical printer. When two servers point to a printer of the same name, an
implicit class is automatically created with no effort required from an administrator.
Printer instances allow multiple queues to point to the same printer with slightly different
settings. This makes it really easy to choose between common features that your printer makes
available.
By using pluggable back ends for the actual output from a queue, not only is it easy to
support many types of printer hardware, but third parties can easily add support for output that
isn’t bundled in the core package. For example, Windows printing is handled by a back end
provided by the Samba team. In addition, CUPS uses a text file called a PostScript Printer
Description (PPD) to describe the features provided by a particular piece of printer hardware
We’ve mentioned before that CUPS was based on the Internet Printing Protocol (IPP), which it
is hoped will become a cross-platform standard for network printing. CUPS also provides
some additional advantages besides just those presented by IPP.
The designers of CUPS have gone to great lengths to make it easy to use and easy to
transition to. Administration is simplified through the use of a web-based front end to server
configuration (although third-party GUI configuration tools exist as well) and clients often
need no configuration at all. Printers are discovered automatically when possible. From the
client’s view of printing, CUPS will emulate many of the tools you’ve become used to under
lpd-style systems (or System V, if you’ve worked with that elsewhere).
CUPS introduces the concept of classes, which allow you to send a print job to a group of
printers, and have it printed on the first available machine in that group. This approach to load
balancing and failover is carried further with implicit classes, which allow multiple servers to
address the same physical printer. When two servers point to a printer of the same name, an
implicit class is automatically created with no effort required from an administrator.
Printer instances allow multiple queues to point to the same printer with slightly different
settings. This makes it really easy to choose between common features that your printer makes
available.
By using pluggable back ends for the actual output from a queue, not only is it easy to
support many types of printer hardware, but third parties can easily add support for output that
isn’t bundled in the core package. For example, Windows printing is handled by a back end
provided by the Samba team. In addition, CUPS uses a text file called a PostScript Printer
Description (PPD) to describe the features provided by a particular piece of printer hardware
