tdebase/doc/tdeprint/theory.docbook

<chapter id="theory">
<title>Some Theoretical Background: &CUPS;, <acronym>IPP</acronym>,
&PostScript; and <application>Ghostscript</application></title>

<para>This chapter aims to give a bit of theoretical background to
printing in general, and to &CUPS; especially.  If you are not in need
of this, you might like to skip ahead to the <link
linkend="getting-started">next chapter</link>. Chances are you will
come back to this chapter at some point anyway, because sometimes one
needs extra theory to solve a practical problem.</para>

<sect1 id="basics-of-printing">
<title>Basics About Printing</title>

<para>Printing is one of the more complicated chapters in
<acronym>IT</acronym> technology.</para>


<para>Earlier on in history, every developer of a program that was
capable of producing printable output had to write his own printer
drivers too.  That was quite complicated, because different programs
have different file formats.  Even programs with the same purpose, for
example: word processors, often do not understand each other's formats.
There was therefore no common interface to all printers, hence the
programmers often supported only a few selected models.</para>

<para>A new device appearing on the market required the program authors
to write a new driver if they wanted their program to support it.  Also
for manufacturers, it was impossible to make sure their device was
supported by any program known to the world (although there were far
fewer than today).</para>

<para>Having to support ten application programs and a dozen printers,
meant a system administrator had to deal with 120 drivers.  So the
development of unified interfaces between programs and printers became
an urgent need.</para>

<para>The appearance of <quote>Page Description Languages</quote>,
describing the graphical representation of ink and toner on sheets of
paper (or other output devices, like monitors, photo typesetters, &etc;)
in a common way, was a move that filled a big gap. <!-- FIXME --></para>

<para>One such development was &PostScript; by Adobe.  It meant that an
application programmer could concentrate on making his program generate
a &PostScript; language description of his printable page, while
printing device developers could focus on making their devices
&PostScript; literate.</para>

<para>Of course, over time, there came the development of other description
methods.  The most important competitors to &PostScript; were
<acronym>PCL</acronym> (<quote>Print Control Language</quote>, from
&Hewlett-Packard;), <quote>ESC/P</quote> (from Epson) and
<acronym>GDI</acronym> (<quote>Graphical Device Interface</quote> from
&Microsoft;).</para>

<para>The appearance of these page description languages made life easier,
and facilitated further development for everybody.  Yet the fact that there
still remained different, incompatible, and competing page description
languages keeps life for users, administrators, developers and
manufacturers difficult enough.</para>

<sect2>
<title>&PostScript; in memory - Bitmaps on Paper</title>

<para>&PostScript; is most heavily used in professional printing
environments such as PrePress and printing service industries.  In the
&UNIX; and &Linux; domains, &PostScript; is the predominant standard
as a <acronym>PDL</acronym>. Here, nearly every program generates a
&PostScript; representation of its pages once you push the
<quote>Print</quote> button.  Let us look at a simple example of
(hand-made) &PostScript; code.  The following listing describes two
simple drawings:</para>

<example id="coded-postscript">
<title>&PostScript; Code</title>
<screen>%!PS
100 100 moveto
0 50 rlineto
50 0 rlineto
0 -50 rlineto
closepath
.7 setgray fill
% first box over; next
160 100 moveto
0 60 rlineto
45 10 rlineto
0 -40 rlineto
closepath
.2 setgray fill</screen>
</example>

<para>This tells the imaginary &PostScript; <quote>pen</quote> to draw
a path of a certain shape, and then fill it with different shades of
gray.  The first part translates into more comprehensive English as
<quote>Go to coordinate (100,100), draw a line with length 50 upward;
then one from there to the right, then down again, and finally close
this part.  Now fill the drawn shape with 70% darkness gray.</quote></para>

<example id="rendered-postscript">
<title>Rendered &PostScript;</title>
<mediaobject>
<imageobject>
<imagedata fileref="ps-boxes.png" format="PNG"/>
</imageobject>
<textobject>
<phrase><xref linkend="coded-postscript"/> example rendered as an
image.</phrase>
</textobject>
</mediaobject>
</example>

<para>Of course, &PostScript; can be much more complicated than this
simplistic example. It is a fully fledged programming language with
many different operators and functions. You may even write
&PostScript; programs to compute the value of Pi, format a hard disk or
write to a file. The main value and strength of &PostScript; however
lies in the field to describe the layout of graphical objects on a
page: it also can scale, mirror, translate, transform, rotate and
distort everything you can imagine on a piece of paper  -- mdash; such as
letters in different font representations, figures, shapes, shades,
colors, lines, dots, raster...</para>

<para>A &PostScript; file is a representation of one or more pages
to be printed, in a relatively abstract way. Ideally, it is meant
to describe the pages in a device-independent way. &PostScript; is
not directly <quote>visible</quote>; it only lives on hard disks
and in <acronym>RAM</acronym> as a coded representation of
future printouts.</para>

</sect2>

<sect2>
<title>Raster Images on Paper Sheets</title>

<para>What you see on a piece of paper is nearly always a
<quote>raster image</quote>. Even if your brain suggests to you that
your eyes see a line: take a good magnifying glass and you will
discover lots of small dots...  (One example to the contrary are
lines that have been drawn by <quote>pen plotters</quote>).  And that
is the only thing that the <quote>marking engines</quote> of today's
printers can put on paper: simple dots of different colors, size and
resolution, to make up a complete <quote>page image</quote> composed of
different bitmap patterns.</para>

<para>Different printers need the raster image prepared in different
ways. Thinking about an inkjet device: depending on its resolution,
the number of inks used (the very good ones need 7 different inks, while
cheaper ones might only use 3), the number of available jets (some print
heads have more than 100!) dispensing ink simultaneously, the
<quote>dithering algorithm</quote> used, and many other things, the
final raster format and transfer order to the marking engine is heavily
dependent on the exact model used.</para>

<para>Back in the early life of the <quote>Line Printer Daemon</quote>,
printers were machines that hammered rows of <acronym>ASCII</acronym>
text mechanically on to long media, folded as a zig-zag paper
<acronym>snake</acronym>, drawn from a cardboard box beneath the
table... What a difference from today!</para>

</sect2>


<sect2>
<title><acronym>RIP</acronym>: From &PostScript; to Raster</title>

<para>Before the final raster images are put on paper cut-sheets, they
have to be calculated somehow out of their abstract &PostScript;
representation. This is a very computing-intensive process. It is called
the <quote>Raster Imaging Process</quote>, more commonly
<quote><acronym>RIP</acronym></quote>).</para>

<para>With &PostScript; printers the <acronym>RIP</acronym>-ping is
taken care of by the device itself. You just send the &PostScript;
file to it. The <quote>Raster Imaging Processor</quote> (also called the
<acronym>RIP</acronym>) inside the printer is responsible (and
specialized) to fulfill quite well this task of interpreting the
&PostScript;-page descriptions and put the raster image on paper.</para>

<para>Smaller &PostScript; devices have a
hardware-<acronym>RIP</acronym> built in; it is etched in silicon, on a
special chip. Big professional printers often have their
<acronym>RIP</acronym> implemented as a software-<acronym>RIP</acronym>
inside a dedicated fast &UNIX; run computer, often a Sun SPARC Solaris
or a &SGI; &IRIX; machine.</para>

</sect2>

<sect2>
<title><application>Ghostscript</application> as a Software
<acronym>RIP</acronym></title>

<para>But what happens, if you are not lucky enough to have a
&PostScript; printer available?</para>

<para>You need to do the <acronym>RIP</acronym>-ing before you send
the print data to the marking engine. You need to digest the &PostScript;
generated by your application on the host machine (the print client)
itself. You need to know how the exact raster format of the target
printer's marking engine must be composed.</para>

<para>In other words, as you can't rely on the printer to understand
and interpret the &PostScript; itself, the issue becomes quite a bit
more complicated.  You need software that tries to solve for you the
issues involved.</para>

<para>This is exactly what the omnipresent &ghostscript; package is
doing for many &Linux;, *BSD and other &UNIX; boxes that need to print
to non-&PostScript; printers: &ghostscript; is a &PostScript;
interpreter, a software <acronym>RIP</acronym> capable of running many
different devices.</para>

</sect2>

<sect2>
<title><quote>Drivers</quote> and <quote>Filters</quote> in General</title>

<para>To produce rasterized bitmaps from &PostScript; input, the
concept of <quote>filters</quote> is used by &ghostscript;.  There are
many different filters in &ghostscript;, some of them specialized for
a certain model of printer.  &ghostscript; filterspecializedin devices
have often been developed without the consent or support of the
manufacturer concerned.  Without access to the specifications and
documentation, it was a very painstaking process to reverse engineer
protocols and data formats.</para>

<para>Not all &ghostscript; filters work equally well for their
printers.  Yet, some of the newer ones, like the
<application>stp</application> Filter of the
<application>Gimp</application> Print project, produce excellent
results leading to photographic quality on a par or even superior to
their &Microsoft; &Windows; driver counterparts.</para>

<para>&PostScript; is what most application programs produce for
printing in &UNIX; and &Linux;.  Filters are the true workhorses of
any printing system there.  Essentially they produce the right bitmaps
from any &PostScript; input for non-&PostScript; target
engines.</para>

</sect2>

<sect2>
<title>Drivers and Filters and Backends in CUPS</title>

<para>&CUPS; uses its own filters, though the filtering system is
based on Ghostscript. Namely the pstoraster and the imagetoraster
filters are directly derived from Ghostscript code. &CUPS; has
reorganized and streamlined the whole mechanics of this legacy code
and organized it into a few clear and distinct modules.</para>

<para>This next drawing (done with the help of &kivio;) gives an
overview of the filters and backends inside &CUPS; and how they fit
together. The <quote>flow</quote> is from top to bottom. Backends
are special filters: they don't convert date to a different format,
but they send the ready files to the printer. There are different
backends for different transfer protocols.</para>

<screenshot id="architecture-diagram">
<screeninfo>&kprinter; dialog started (&kivio; draft drawing)
</screeninfo>
<mediaobject>
<imageobject>
<imagedata fileref="cups-filterarchitecture-kivio-70Percent-scaled.png"
format="PNG"/></imageobject>
<textobject>
<phrase>&kprinter; dialog started (&kivio; draft
drawing)</phrase></textobject>
</mediaobject>
</screenshot>

</sect2>
<sect2>
<title>Spoolers and Printing Daemons</title>

<para>Besides the heavy part of the filtering task to generate a
print-ready bitmap, any printing software needs to use a SPOOLing
mechanism: this is to line up different jobs from different users for
different printers and different filters and send them accordingly to
the destinations. The printing daemon takes care of all this.</para>

<para>This daemon is keeping the house in order: it is also
responsible for the job control: users should be allowed to cancel,
stop, restart, &etc; their jobs (but not other peoples's jobs) and so
on.</para>

</sect2>

</sect1>



<sect1 id="cups-and-ppd">
<title>Excursion: How <quote>CUPS</quote> uses the power of
&PPD;s</title>

<para>Now that you know how a &PostScript; language file (which
describes the page layout in a largely device independent way) is
transformed into a Raster Image, you might ask:
<quote>Well, there are different kinds of raster output devices: first
they differ in their resolution; then there are the different paper
sizes; it goes on with many finishing options (duplex prints,
pamphlets, punched and stapled output with different sheets of colored
paper being drawn from different trays, &etc;). How does this fit into
our model of device-independent &PostScript;?</quote></para>

<para>The answer comes with so called &PostScript; Printer Description
(&PPD; files. A &PPD; describes all the device dependent features
which can be utilized by a certain printer model.  It also contains
the coded commands that must be used to call certain features of the
device.  But &PPD;s are not a closed book, they are simple
<acronym>ASCII</acronym> text files.</para>

<para>&PPD;s were <quote>invented</quote> by Adobe to make it easy for
manufacturers to implement their own features into &PostScript;
printers, and at the same time retain a standard way of doing so.
&PPD;s are well documented and described by Adobe.  Their
specification is a de-facto open standard.</para>

<sect2 id="ppd-files">
<title>Device Dependent Print Options</title>

<para>Remember, advanced &PostScript; printing was originally only
developed for use on &Microsoft; &Windows; and Apple &Mac; systems.
For a long time, all of the feature rich printing on modern devices
was simply unavailable for &Linux; and &UNIX;. &CUPS; changes this
decisively. &CUPS; is closely tied with &PPD;s, and therefore existing
&PPD;s can be utilized to the full by all systems powered by
&CUPS;.</para>

<para>Using &PPD;s, printer manufacturers were able to insert
device-specific hardware features into their products, for features such
as duplexing, stapling, punching, finishing, &etc;. The printer drivers
load this &PPD; just like an additional configuration file. Thus the
printer driver learns about the available device options and how to
call them; the driver also presents them in a &GUI; to the user. Through
this mechanism you are still able to print
<quote>device-independent</quote> &PostScript; page description
language files and specify device-dependent finishing options on top,
which are added to the application-generated &PostScript;.</para>

</sect2>

<sect2>
<title>Where to get the &PPD;s for &PostScript; Printers</title>

<para>&PPD;s originally were not used routinely in &UNIX; and &Linux;
systems.  The vendors providing those &PPD;s never intended them for
anything other than the originally supported &OS;s: &Microsoft; &Windows; and
&MacOS;.  Through its brilliant move to fully support and utilize
the existing &PPD; specification, &CUPS; now gives the power to use
all features of modern printers to users of &Linux; and &Linux;-like
systems.  &tdeprint; makes its usage even more comfortable than the
&CUPS; developers ever dreamed of.</para>

<para>&CUPS; can use original &Windows; &PPD;s, distributed by the
vendors in the case of &PostScript; printers.  Those normally don't
cost any money, and they can be grabbed from any &Windows; computer
with an installed &PostScript; driver for the model concerned, or from
the disks provided with the printer.  There are also several places on
the web to download them.</para>

</sect2>

<sect2>
<title>How Special &PPD;s are Now Useful Even For Non-&PostScript;
Printers.</title>

<para>Now you know how &PostScript;-Printers can use &PPD;s. But what
about non-&PostScript; printers? &CUPS; has done a very good trick: by
using the same format and data structure as the &PostScript; Printer
Descriptions (&PPD;s) in the &PostScript; world, it can describe the
available print job options for non-&PostScript; printers just the
same. For its own special purposes &CUPS; just added a few special
options (namely the line which defines the filter to be used for
further processing of the &PostScript; file).</para>

<para>So, the developers could use the same software engine to parse
the Printer Description Files for available options for all sorts of
printers.  Of course the &CUPS; developers could not rely on the
non-&PostScript; hardware manufacturers to suddenly develop &PPD;s.
They had to do the difficult start themselves and write them from
scratch.  More than 1000 of these are available through the commercial
version of &CUPS;, called <application>ESP
PrintPro</application>.</para>

<para>Meanwhile there are a lot of &CUPS;-specific &PPD;s available.
Even now those are in most cases not originating from the printer
manufacturers, but from Free software developers.  The &CUPS; folks
proofed it, and others followed suit: where &Linux; and &UNIX;
printing one or two years ago still was a kludge, it is now able to
support a big range of printers, including 7-color inkjets capable of
pushing them to Photo Quality output.</para>

</sect2>

<sect2>
<title>Different Ways to get &PPD;s for non-&PostScript;
Printers</title>

<para>You can get &PPD;s to be used with &CUPS; and non-&PostScript;
printers from different areas in the Web:</para>

<itemizedlist>
<listitem>
<para> first, there is the repository at <ulink
url="http://www.linuxprinting.org">www.linuxprinting.org</ulink>,
which lets you generate a <quote>CUPS-O-Matic</quote>-&PPD; online for
any printer that had been supported by traditional &ghostscript;
printing already. This helps you to switch over to &CUPS; with little
effort, if you wish so. If your printer was doing well with the
traditional way of &ghostscript; printing, take CUPS-O-Matic to plug
your driver into th e &CUPS; system and you'll have the best of both
worlds.</para>
</listitem>

<listitem>
<para>second, there are &CUPS;-&PPD;s for the more than 120 printer
models, which are driven by the new universal
<application>stp</application> driver. <application>stp</application>
(stood originally for Stylus Photo) is now developed by the gimp-print
project; it was started by Mike Sweet, the leading &CUPS; developer
and is now available through <ulink
url="http://gimp-print.sourceforge.net">gimp-print.sourceforge.net</ulink>.
This driver prints real Photo quality on many modern inkjets and can
be configured to make 120 &CUPS;-&PPD;s along its own
compilation. &HP; Laser- and DeskJet, <trademark
class="registered">Epson</trademark> Stylus and Photo Color models as
well as some <trademark class="registered">Canon</trademark> and
<trademark class="registered">Lexmark</trademark> are covered.</para>
</listitem>

<listitem>
<para>third, there is the commercial extension to &CUPS; from the
&CUPS; developers themselves: it is called <application>ESP
PrintPro</application> and comes with more than 2.300 printer
drivers. There are even improved imagetoraster and pstoraster filters
included.</para>
</listitem>
</itemizedlist>

<para>&CUPS; makes it really easy for manufacturers to start
supporting &Linux; and &UNIX; printing for their models at reasonably
low cost. The modular framework of &CUPS; facilitates to plug in any
filter (=driver) with minimal effort and to access and utilize the
whole printing framework that &CUPS; is creating.</para>

<para>Read more about the exciting &CUPS; features in the available
&CUPS; documentation at <ulink
url="http://www.cups.org/documentation.html">http://www.cups.org/documentation.html</ulink>
and <ulink
url="http://wwww.danka.de/printpro/faq.html">http://www.danka.de/printpro/faq.html</ulink>.
Also at <ulink
url="http://www.linuxprinting.org">http://www.linuxprinting.org/</ulink>
is a universal repository for all issues related to &Linux; and &UNIX;
printing.</para>

</sect2>

</sect1>

<sect1 id="cups-ipp-support">
<title>How &IPP; Support Makes &CUPS; the Best Choice Around</title>

<sect2>
<title><quote><acronym>LPD</acronym> Must Die!</quote></title>

<para>For a long time many developers were deeply dissatisfied with good
old <acronym>LPD</acronym>. Quite a few new projects were started to
improve printing: <application>LPRng</application> is the best known
example. Others are <acronym>PDQ</acronym>, <acronym>PPR</acronym>,
<acronym>PLP</acronym>, <acronym>GNUlpr</acronym> and
<acronym>RLPR</acronym>. But none of the new programs were seen as a
<quote>big shot</quote>; most of them are just implementing the same old
<acronym>LPD</acronym> specification with a few (or many) new
extensions, which again make them incompatible with each other.</para>

<para>Having seen the development of not just one, but different
viable alternatives to venerable <acronym>BSD</acronym>-style
<acronym>LPD</acronym>, Grant Taylor, author of the <citetitle>Linux
Printing HOWTO</citetitle>, finally rallied the call <citetitle>LPD
Must Die!</citetitle> in his <quote>Campaign To Abolish The Line
Printer Daemon</quote>.</para>

<!-- FIXME: look up URLs for the above -->

</sect2>

<sect2>
<title>How the &IPP; Came to Be</title>

<para>Along with the above, on the industry side of things, there were
efforts to overcome the well-known weaknesses of
<acronym>LPD</acronym>.  It started with proprietary extensions to
plain old <acronym>LPD</acronym>, and stretched as far as
&Hewlett-Packard;'s attempt to establish &HP; JetDirect as a new
standard for a network printing protocol.  The result were even more
incompatibilities.</para>

<para>In the end, an initiative to define a new common industry and
<acronym>IETF</acronym> standard took shape. The <quote>Printer
Working Group</quote> or <acronym>PWG</acronym>, a loose aggregation
of vendors in hardware, software, and operating systems, drafted the
new <quote>Internet Printing Protocol</quote>, &IPP;.  &IPP; v1.1 has
now been approved by the <acronym>IETF</acronym> (Internet Engineering
Task Force) as a proposed standard, and now enjoys the unanimous
support throughout the industry in Europe, USA and Japan.  Most
current network printer models have now built in &IPP; support on top
of traditional <acronym>LPR</acronym>/<acronym>LPD</acronym> or
JetDirect Printing.</para>

</sect2>

<sect2>
<title>Why &IPP; is Solving Many Problems</title>

<para>&IPP; promises to solve a lot of problems network administrators
face. This trade normally deals with heterogeneous network
environments and spends more than half of its working hours dealing
with printing problems.</para>

<para>By creating a unified set of query functions for &IPP; enabled
printers and servers, for transferring files and setting job-control
attributes &etc;, &IPP; is destined to work across all &OS; platforms.
It's rollout however, will not happen overnight, as many legacy print
devices will still be in use for many years to come.  Therefore, in
&IPP; there is a provision made for backwards compatibility of all
&IPP; implementations.  &CUPS; is proving the viability of &IPP;
printing in all environments.</para>

<para>The most striking advantage will be it's integration into the
existing set of other robust <acronym>IP</acronym> protocols.  Being
an extension of the proven and robust <acronym>HTTP</acronym> 1.1
protocol, for the special task of handling print file and related
data, it is also very easy to plug in other standards as they are
being developed and deployed:</para>

<itemizedlist>
<listitem>
<para>Basic, Digest, and Certificate Authentication for users seeking
access to print services.</para>
</listitem>
<listitem>
<para>SSL3 and <acronym>TLS</acronym> encryption for transferring
data.</para>
</listitem>
<listitem>
<para>Bi directional communication of clients with print devices, using
the <acronym>HTTP</acronym>/&IPP; <command>GET</command> and
<command>POST</command> mechanism.</para>
</listitem>
<listitem>
<para>LDAP directory service integration to keep a consistent database
of available printers, their capabilities and page-costs, &etc;, as well
as user passwords, <acronym>ACL</acronym>s &etc;.</para>
</listitem>
<listitem>
<para><quote>Pull</quote> (as opposed to the usual <quote>Push</quote>
model) printing, where a server or printer just needs to be told the
&URL; of a document, whereupon it is retrieved from the resource on the
internet and printed.</para>
</listitem>
</itemizedlist>

</sect2>

<!--
<sect2>
<title>&CUPS;, &IPP; and &tde;</title>

<para>&CUPS; is the most advanced implementation of &IPP; on all &OS;
platforms.  That makes &CUPS; a crucial ally to help "conquer the
desktop" for projects like &tde;. &tdeprint; is the best utility to
make &CUPS; core functionality available to &tde; Desktop
users.</para>

</sect2> -->

<sect2>
<title>Printer <quote>Plug'n'Play</quote> for Clients</title>

<para>Have you ever seen a demonstration about &CUPS; capabilities in
the network?  You must have been quite impressed if you didn't know in
advance what to expect.</para>

<para>Imagine you as the administrator of a <quote>LAN</quote>.  For
testing purposes you fully installed one &tde;/&CUPS; box on your net,
complete with a dozen printers configured and functional:
&PostScript;, LaserJets, InkJets and BubbleJets, and so on.  Your
&tde; users on that box are very happy, they can print like never
before, <quote>ringing all the bells and whistles</quote> of every
printer.  It took you 2 hours to make everything run perfectly... and
now all the other 100 users on the network want the same.  Two hours
again for every box?  No way you could do that before next year, you
think?</para>

<para>Wrong.  Just change one setting in the original &CUPS; box to
make it a <quote>server</quote>.  Install &CUPS; on five other boxes,
as <quote>clients</quote>.  By the time you turn back to your first
client, you find the users happily playing with the settings for the
dozen printers you had defined earlier on the <quote>server</quote>.
Somehow magically the printers had appeared on all the
<quote>Print</quote> dialogs of the five new &CUPS; client
boxes.</para>

<para>Your users print, but not a single driver had been installed on
the clients, nor a printer queue defined.</para>

<para>So, how does this magic work?</para>

</sect2>

<sect2>
<title><quote>Seeing</quote> Printers Not Installed Locally?</title>

<para>The answer is not complicated at all.</para>

<para>If a &CUPS; server is on the <acronym>LAN</acronym>, it
broadcasts the names of all available printers to the
<acronym>LAN</acronym>, using the <acronym>UDP</acronym> protocol and
port 631.  Port 631 is reserved as a <quote>well-known port</quote> by
<acronym>IANA</acronym> (the <quote>Internet Assigning Numbers
Authority</quote>) for &IPP; purposes.  All &CUPS; clients listen to
&CUPS; server info sent to their port 631.  That's how they know about
available printers, and that's how they learn about the
<quote>path</quote> to the printers as well.</para>

<para>Using &IPP;, which is really a clever extension to
<acronym>HTTP</acronym> v1.1, &CUPS; is able to address all objects
related to the printing system via <quote>Universal Resource
Locators</quote> or <acronym>URL</acronym>s.  Print jobs to be deleted
or restarted, printers to be queried or modified, admin tasks to be
performed on the server, with &IPP; and &CUPS;, everything is
addressable by a certain <acronym>URL</acronym>.  Many important
things can be done through the web interface to &CUPS;, accessible for
example with &konqueror;.</para>

</sect2>

<sect2>
<title>Printing Without Installing a Driver</title>

<para>And more, the clients basically can <quote>administer</quote>
and <quote>use</quote> any printer they see, just as if it was a
locally installed one.  Of course, you can set restrictions on it with
access control lists &etc;, so that not <emphasis>any</emphasis>
clients may use <emphasis>any</emphasis> printer as it likes.</para>

<para>The clients even are able to print without the appropriate filter
(or driver) installed locally.</para>

<para>So how does this work? If a client wants to know about and
select printer-specific options, it sends a request (called
<command>CUPS-get-ppd</command>) to the server.  The server tells the
client all about all printer-specific options, as read from the server
side &PPD;.  The user on the client side can see the options and
select the required ones.  He then sends the print file, usually
unfiltered <quote>raw</quote> &PostScript;, spiced up with the
printer-options to the printer server, using &IPP; as the transport
protocol.  All further processing, especially the filtering to
generate the final format for the target printer, is then done by the
server.  The server has the necessary programs (<quote>drivers</quote>
or <quote>filters</quote>) to do this.</para>

<para>This way a client prints without needing to install a driver
locally.</para>

<para>Any change on the server, such as adding or modifying a printer,
is instantly <quote>known</quote> to the clients with no further
configuration.</para>

</sect2>

<sect2>
<title><quote>Zero Administration</quote>, Load Balancing, and
<quote>Failover Switching</quote></title>

<para>Some other advanced features built into &CUPS; are the capacity to
do <quote>load balancing</quote>.</para>

<para>If you define the same printer queues on two or more different
servers, the clients will send their jobs to the first responding or
available server. This implies an automatic load balancing amongst
servers. If you have to take one server off the network for
maintenance, the others will just take over its tasks without the users
even noticing the difference.</para>

</sect2>

</sect1>

</chapter>