From 4aed2c8219774f5d797760606b8489a92ddc5163 Mon Sep 17 00:00:00 2001 From: toma Date: Wed, 25 Nov 2009 17:56:58 +0000 Subject: Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdebase@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- doc/kdeprint/theory.docbook | 690 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 690 insertions(+) create mode 100644 doc/kdeprint/theory.docbook (limited to 'doc/kdeprint/theory.docbook') 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 @@ + +Some Theoretical Background: &CUPS;, <acronym>IPP</acronym>, +&PostScript; and <application>Ghostscript</application> + +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 next chapter. Chances are you will +come back to this chapter at some point anyway, because sometimes one +needs extra theory to solve a practical problem. + + +Basics About Printing + +Printing is one of the more complicated chapters in +IT technology. + + +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. + +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). + +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. + +The appearance of Page Description Languages, +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. + +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. + +Of course, over time, there came the development of other description +methods. The most important competitors to &PostScript; were +PCL (Print Control Language, from +&Hewlett-Packard;), ESC/P (from Epson) and +GDI (Graphical Device Interface from +&Microsoft;). + +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. + + +&PostScript; in memory - Bitmaps on Paper + +&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 PDL. Here, nearly every program generates a +&PostScript; representation of its pages once you push the +Print button. Let us look at a simple example of +(hand-made) &PostScript; code. The following listing describes two +simple drawings: + + +&PostScript; Code +%!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 + + +This tells the imaginary &PostScript; pen 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 +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. + + +Rendered &PostScript; + + + + + + example rendered as an +image. + + + + +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... + +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 visible; it only lives on hard disks +and in RAM as a coded representation of +future printouts. + + + + +Raster Images on Paper Sheets + +What you see on a piece of paper is nearly always a +raster image. 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 pen plotters). And that +is the only thing that the marking engines of today's +printers can put on paper: simple dots of different colors, size and +resolution, to make up a complete page image composed of +different bitmap patterns. + +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 +dithering algorithm used, and many other things, the +final raster format and transfer order to the marking engine is heavily +dependent on the exact model used. + +Back in the early life of the Line Printer Daemon, +printers were machines that hammered rows of ASCII +text mechanically on to long media, folded as a zig-zag paper +snake, drawn from a cardboard box beneath the +table... What a difference from today! + + + + + +<acronym>RIP</acronym>: From &PostScript; to Raster + +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 Raster Imaging Process, more commonly +RIP). + +With &PostScript; printers the RIP-ping is +taken care of by the device itself. You just send the &PostScript; +file to it. The Raster Imaging Processor (also called the +RIP) 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. + +Smaller &PostScript; devices have a +hardware-RIP built in; it is etched in silicon, on a +special chip. Big professional printers often have their +RIP implemented as a software-RIP +inside a dedicated fast &UNIX; run computer, often a Sun SPARC Solaris +or a &SGI; &IRIX; machine. + + + + +<application>Ghostscript</application> as a Software +<acronym>RIP</acronym> + +But what happens, if you are not lucky enough to have a +&PostScript; printer available? + +You need to do the RIP-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. + +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. + +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 RIP capable of running many +different devices. + + + + +<quote>Drivers</quote> and <quote>Filters</quote> in General + +To produce rasterized bitmaps from &PostScript; input, the +concept of filters 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. + +Not all &ghostscript; filters work equally well for their +printers. Yet, some of the newer ones, like the +stp Filter of the +Gimp Print project, produce excellent +results leading to photographic quality on a par or even superior to +their &Microsoft; &Windows; driver counterparts. + +&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. + + + + +Drivers and Filters and Backends in CUPS + +&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. + +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 flow 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. + + +&kprinter; dialog started (&kivio; draft drawing) + + + + + +&kprinter; dialog started (&kivio; draft +drawing) + + + + + +Spoolers and Printing Daemons + +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. + +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. + + + + + + + + +Excursion: How <quote>CUPS</quote> uses the power of +&PPD;s + +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: +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;? + +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 +ASCII text files. + +&PPD;s were invented 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. + + +Device Dependent Print Options + +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;. + +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 +device-independent &PostScript; page description +language files and specify device-dependent finishing options on top, +which are added to the application-generated &PostScript;. + + + + +Where to get the &PPD;s for &PostScript; Printers + +&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. + +&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. + + + + +How Special &PPD;s are Now Useful Even For Non-&PostScript; +Printers. + +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). + +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 ESP +PrintPro. + +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. + + + + +Different Ways to get &PPD;s for non-&PostScript; +Printers + +You can get &PPD;s to be used with &CUPS; and non-&PostScript; +printers from different areas in the Web: + + + + first, there is the repository at www.linuxprinting.org, +which lets you generate a CUPS-O-Matic-&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. + + + +second, there are &CUPS;-&PPD;s for the more than 120 printer +models, which are driven by the new universal +stp driver. stp +(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 gimp-print.sourceforge.net. +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, Epson Stylus and Photo Color models as +well as some Canon and +Lexmark are covered. + + + +third, there is the commercial extension to &CUPS; from the +&CUPS; developers themselves: it is called ESP +PrintPro and comes with more than 2.300 printer +drivers. There are even improved imagetoraster and pstoraster filters +included. + + + +&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. + +Read more about the exciting &CUPS; features in the available +&CUPS; documentation at http://www.cups.org/documentation.html +and http://www.danka.de/printpro/faq.html. +Also at http://www.linuxprinting.org/ +is a universal repository for all issues related to &Linux; and &UNIX; +printing. + + + + + + +How &IPP; Support Makes &CUPS; the Best Choice Around + + +<quote><acronym>LPD</acronym> Must Die!</quote> + +For a long time many developers were deeply dissatisfied with good +old LPD. Quite a few new projects were started to +improve printing: LPRng is the best known +example. Others are PDQ, PPR, +PLP, GNUlpr and +RLPR. But none of the new programs were seen as a +big shot; most of them are just implementing the same old +LPD specification with a few (or many) new +extensions, which again make them incompatible with each other. + +Having seen the development of not just one, but different +viable alternatives to venerable BSD-style +LPD, Grant Taylor, author of the Linux +Printing HOWTO, finally rallied the call LPD +Must Die! in his Campaign To Abolish The Line +Printer Daemon. + + + + + + +How the &IPP; Came to Be + +Along with the above, on the industry side of things, there were +efforts to overcome the well-known weaknesses of +LPD. It started with proprietary extensions to +plain old LPD, 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. + +In the end, an initiative to define a new common industry and +IETF standard took shape. The Printer +Working Group or PWG, a loose aggregation +of vendors in hardware, software, and operating systems, drafted the +new Internet Printing Protocol, &IPP;. &IPP; v1.1 has +now been approved by the IETF (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 LPR/LPD or +JetDirect Printing. + + + + +Why &IPP; is Solving Many Problems + +&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. + +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. + +The most striking advantage will be it's integration into the +existing set of other robust IP protocols. Being +an extension of the proven and robust HTTP 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: + + + +Basic, Digest, and Certificate Authentication for users seeking +access to print services. + + +SSL3 and TLS encryption for transferring +data. + + +Bi directional communication of clients with print devices, using +the HTTP/&IPP; GET and +POST mechanism. + + +LDAP directory service integration to keep a consistent database +of available printers, their capabilities and page-costs, &etc;, as well +as user passwords, ACLs &etc;. + + +Pull (as opposed to the usual Push +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. + + + + + + + + +Printer <quote>Plug'n'Play</quote> for Clients + +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. + +Imagine you as the administrator of a LAN. 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, ringing all the bells and whistles 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? + +Wrong. Just change one setting in the original &CUPS; box to +make it a server. Install &CUPS; on five other boxes, +as clients. 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 server. +Somehow magically the printers had appeared on all the +Print dialogs of the five new &CUPS; client +boxes. + +Your users print, but not a single driver had been installed on +the clients, nor a printer queue defined. + +So, how does this magic work? + + + + +<quote>Seeing</quote> Printers Not Installed Locally? + +The answer is not complicated at all. + +If a &CUPS; server is on the LAN, it +broadcasts the names of all available printers to the +LAN, using the UDP protocol and +port 631. Port 631 is reserved as a well-known port by +IANA (the Internet Assigning Numbers +Authority) 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 +path to the printers as well. + +Using &IPP;, which is really a clever extension to +HTTP v1.1, &CUPS; is able to address all objects +related to the printing system via Universal Resource +Locators or URLs. 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 URL. Many important +things can be done through the web interface to &CUPS;, accessible for +example with &konqueror;. + + + + +Printing Without Installing a Driver + +And more, the clients basically can administer +and use 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 any +clients may use any printer as it likes. + +The clients even are able to print without the appropriate filter +(or driver) installed locally. + +So how does this work? If a client wants to know about and +select printer-specific options, it sends a request (called +CUPS-get-ppd) 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 raw &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 (drivers +or filters) to do this. + +This way a client prints without needing to install a driver +locally. + +Any change on the server, such as adding or modifying a printer, +is instantly known to the clients with no further +configuration. + + + + +<quote>Zero Administration</quote>, Load Balancing, and +<quote>Failover Switching</quote> + +Some other advanced features built into &CUPS; are the capacity to +do load balancing. + +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. + + + + + + -- cgit v1.2.1