diff options
Diffstat (limited to 'doc/kdeprint/theory.docbook')
| -rw-r--r-- | doc/kdeprint/theory.docbook | 690 |
1 files changed, 690 insertions, 0 deletions
diff --git a/doc/kdeprint/theory.docbook b/doc/kdeprint/theory.docbook new file mode 100644 index 000000000..a90aa2755 --- /dev/null +++ b/doc/kdeprint/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. &kdeprint; 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;. &kdeprint; 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> |