Actually move the kde files that were renamed in the last commit

1 files changed, 690 insertions, 0 deletions

diff --git a/doc/tdeprint/theory.docbook b/doc/tdeprint/theory.docbook
new file mode 100644
index 000000000..7b137f1c3
--- /dev/null
+++ b/doc/tdeprint/theory.docbook
@@ -0,0 +1,690 @@
+<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 -- 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 &kde;</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 &kde;. &tdeprint; is the best utility to
+make &CUPS; core functionality available to &kde; 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 &kde;/&CUPS; box on your net,
+complete with a dozen printers configured and functional:
+&PostScript;, LaserJets, InkJets and BubbleJets, and so on.  Your
+&kde; 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>