This chapter aims to give a bit of theoretical background to printing in general, and to ∪︀ 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. 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; 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: %!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 grey. 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 grey. 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, colours, 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. 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 colours, 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! 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. 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. To produce rasterised bitmaps from &PostScript; input, the concept of filters is used by &ghostscript;. There are many different filters in &ghostscript;, some of them specialised 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. ∪︀ 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. ∪︀ has reorganised and streamlined the whole mechanics of this legacy code and organised 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 ∪︀ 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; dialogue started (&kivio; draft drawing) &kprinter; dialogue started (&kivio; draft drawing) 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. 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 coloured 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 utilised 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. 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;. ∪︀ changes this decisively. ∪︀ is closely tied with &PPD;s, and therefore existing &PPD;s can be utilised to the full by all systems powered by ∪︀. 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;. &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 utilise the existing &PPD; specification, ∪︀ 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 ∪︀ developers ever dreamed of. ∪︀ 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. Now you know how &PostScript;-Printers can use &PPD;s. But what about non-&PostScript; printers? ∪︀ 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 ∪︀ 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 ∪︀ 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 ∪︀, called ESP PrintPro. Meanwhile there are a lot of ∪︀-specific &PPD;s available. Even now those are in most cases not originating from the printer manufacturers, but from Free software developers. The ∪︀ 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-colour inkjets capable of pushing them to Photo Quality output. You can get &PPD;s to be used with ∪︀ 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 ∪︀ 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 the ∪︀ system and you'll have the best of both worlds. second, there are ∪︀-&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 ∪︀ 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 ∪︀-&PPD;s along its own compilation. &HP; Laser- and DeskJet, Epson Stylus and Photo Colour models as well as some Canon and Lexmark are covered. third, there is the commercial extension to ∪︀ from the ∪︀ 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. ∪︀ makes it really easy for manufacturers to start supporting &Linux; and &UNIX; printing for their models at reasonably low cost. The modular framework of ∪︀ facilitates to plug in any filter (=driver) with minimal effort and to access and utilise the whole printing framework that ∪︀ is creating. Read more about the exciting ∪︀ features in the available ∪︀ 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. 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. 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. &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. ∪︀ 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. Have you ever seen a demonstration about ∪︀ 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;/∪︀ 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 ∪︀ box to make it a server. Install ∪︀ 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 dialogues of the five new ∪︀ 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? The answer is not complicated at all. If a ∪︀ 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 ∪︀ clients listen to ∪︀ 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, ∪︀ 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 ∪︀, everything is addressable by a certain URL. Many important things can be done through the web interface to ∪︀, accessible for example with &konqueror;. 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. Some other advanced features built into ∪︀ 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.