43.1 Introduction to Printing

This chapter discusses printing, which is a surprisingly complicated subject. To understand why printing is so complicated, though, let's think a little bit about what you might want to print.

First, in the "olden days" we had line printers and their relatives: daisy wheel printers, dot matrix printers, and other pieces of equipment that generated typewriter-like output. Printing a simple text file was easy: you didn't need any special processing, you only needed some software to shove the file into the printer. If you wanted, you might add a banner page and do a little simple formatting, but that was really pretty trivial.

The one area of complexity in the printing system was the "spooling system," which had to do several things in addition to force-feeding the printer. Most printers were (and still are) shared devices. This means that many people can send jobs to the printer at the same time. There may also be several printers on which your file gets printed; you may care which one is used, you may not. The spooling system needs to manage all this: receiving data from users, figuring out whether or not an appropriate printer is in use, and sending the file to the printer (if it's free) or storing the file somewhere (if the printer isn't free).

Historical note: why is this called the "spooling system"? Dave Birnbaum, a Principal Scientist at Xerox, says:

"SPOOL (Simultaneous Printing Off and On Line)" It was written for the early IBM mainframes (of the 3 digit, i.e., 709 kind) and extended to the early 1401 machines. Output for the printer was sent to the spool system which either printed it directly or queued it (on tape) for later printing (hence the on/off line). There was also a 2nd generation version where the 1401 would act as the printer controller for the (by then) 7094. The two were usually connected by a switchable tape drive that could be driven by either machine." [There's some controversy about exactly what the acronym means, but Dave's is as good as any I've heard. -JP  ]

The first few articles in this chapter, 43.2 , 43.3 , 43.4 , and 43.5 , discuss the basic UNIX spooling system, and how to work with it as a user. (We don't discuss the administrative aspects of spooling; that's a much more complicated topic, and not really appropriate for this book.) Article 43.6 shows one way to print to a terminal with its own printer.

The next few articles talk about how to format articles for printing - not the kind of fancy formatting people think of nowadays, but simpler things like pagination, margins, and so on, for text files that are to be sent to the line printer. Articles 43.7 through 43.10 describe this kind of simple formatting.

Historical note number two: why is the print spooler called lp or lpr ? Because it typically spooled text to a line printer, a fast printer that used a wide head to print an entire line at a time. These printers are still common in data processing applications, and they can really fly!

In the mid-'70s, lots of UNIX people got excited about typesetting. Some typesetters were available that could be connected to computers, most notably the C/A/T phototypesetter. Programs like troff and TeX were developed to format texts for phototypesetters: letting computer people think that, because they could produce fancy output, they actually had some sense of design. Most of them didn't; if you go back to the early days of typesetting, or even of laser printers, you probably remember lots of incredibly ugly documents masquerading as "good designs." (Gothic fonts on a dot matrix printer? Get real.) But that's another story. Tools like troff , nroff (a troff equivalent that produces output for a standard terminal), and TeX are still with us, and still very valuable. They're discussed in articles 43.12 through 43.21 .

Laser printers became commonplace in the mid-80s, allowing common people to do high-quality printing: almost as good (but not quite) as true typesetting. With laser printers came a widely used standard language, called PostScript, to drive the printer. Tools like troff and TeX now generated PostScript output files, which could be printed on any printer that understood the PostScript language. This was a big advantage: if you bought a new printer, you didn't have to change your software; you could ship a PostScript file cross-country and be reasonably sure the recipient could print it correctly. [1] However, another problem appeared. PostScript is a complicated language; things that were easy with a simple text file were now rather difficult. You can't just type up a letter and send it to your daisy wheel printer; you need to convert it into PostScript. It used to be easy to print "just a few pages" from the middle of a file, grep through a file to find something interesting, or to look at the file on your screen and read it. Not any more. We've ended this chapter with a few utilities for working with PostScript files. Unfortunately, not enough; I played with lots of them, and while there were some winners, there were many more losers: programs that worked sometimes but not most of the time. The winners are discussed in articles 43.22 , 43.23 , and 43.24 .

[1] Documents were reasonably "portable" back in the line-printer era. Portability disappeared in the early days of computer typesetting, and only reappeared when PostScript became the dominant page description language. [PostScript doesn't help someone who doesn't have the exact fonts used in the PostScript file - unless the person who created the file included the fonts in it. -JP  ]

Finally, article 43.25 is about the netpbm package. It's a useful tool for people who deal with graphics files. netpbm converts between different graphics formats.