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

1 files changed, 0 insertions, 690 deletions

diff --git a/doc/kdeprint/theory.docbook b/doc/kdeprint/theory.docbook
deleted file mode 100644
index 7b137f1c3..000000000
--- a/doc/kdeprint/theory.docbook
+++ /dev/null
@@ -1,690 +0,0 @@
-<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>