Back then, Warnock already had a rough idea how to “Print Anything.” But later he ran into a different obstacle, when his employer, Xerox Corp., proved loath to support a truly standard language. So off he went, with Charles Geschke and several other colleagues, to found Adobe Systems Inc. in Mountain View, Calif. By that time, PostScript was only two major pieces of research away, although one—the development of type font algorithms—was “a research project that had to succeed,” says Warnock, and the other had been described as one of the world’s most difficult problems.

The rest is desktop publishing history. PostScript can truly do anything, though extremely complex images can take as much as an hour of computation time. It first appeared in the Apple LaserWriter, which was introduced in January of 1985. Today it has been adopted by 23 manufacturers of laser printers, with more still signing on.

Still, this story is as much about luck and guts as about matters of principle and brilliant software engineering. It would have been quite different had Warnock and company not been in the right place at the right time to meet the right person.

The time was right because of the imminence of three hardware developments: the first low-cost, bit-mapped personal computer, the first low-cost laser printer, and a decline in price of high-density memory chips. And the right person was Apple founder Steven Jobs, who invented the first, hoped for the second, and told Adobe to tough out the third.

Today laser printers are rapidly replacing the daisy-wheel printers in the office, pushing out letter-quality type as their laser obeys the commands of simple software. But given more sophisticated software like PostScript, laser printers can do far more. They can print many different type fonts and make the letters dance around the page hand in hand with drawings and photographs. PostScript does all this implies—draws lines and curves, tilts text at arbitrary angles, or shades a photograph in various tones of gray. It is as complete and flexible a programming language as Pascal or C or Forth, having variables, loops, conditionals, operators, and routines and offering any number of ways to get the same output.

The PostScript program is created on the computer either by someone using the language or by desktop publishing software or other applications software that translates, say, the movements of a mouse into a PostScript program. (Other page description languages are optimized for one of these purposes, not both.) That program is sent over a local-area network or through an RS-232 port to the laser printer. There it is converted into instructions for the printer by the PostScript interpreter, software resident in ROM. On the same circuit board as up to 2 megabytes of ROM is a Motorola 68000 series processor, which executes the instructions and causes the pages to be printed.

Things were more elementary with the first laser printers, which were in regular use at the Xerox Palo Alto Research Center (PARC) in the mid-1970s. They were controlled by a printing protocol called Press, which was not a programming language but a set of instructions that sent image data to a printer in a steady stream. It handled letters and simple images well, but for anything more detailed, got the printer to return the message: “Page Too Complex.” Thereupon the typical PARC engineer would simplify the image.

But when Warnock, a computer scientist with a Ph.D. from the University of Utah, joined the center in 1978, he immediately began work on a new printer protocol. Six years of experience at Evans & Sutherland in Mountain View, Calif., had taught him where to start.

The PostScript program is created on the computer either by someone using the language or by desktop publishing software or other applications software that translates, say, the movements of a mouse into a PostScript program. (Other page description languages are optimized for one of these purposes, not both.) That program is sent over a local-area network or through an RS-232 port to the laser printer. There it is converted into instructions for the printer by the PostScript interpreter, software resident in ROM. On the same circuit board as up to 2 megabytes of ROM is a Motorola 68000 series processor, which executes the instructions and causes the pages to be printed.

Things were more elementary with the first laser printers, which were in regular use at the Xerox Palo Alto Research Center (PARC) in the mid-1970s. They were controlled by a printing protocol called Press, which was not a programming language but a set of instructions that sent image data to a printer in a steady stream. It handled letters and simple images well, but for anything more detailed, got the printer to return the message: “Page Too Complex.” Thereupon the typical PARC engineer would simplify the image.

But when Warnock, a computer scientist with a Ph.D. from the University of Utah, joined the center in 1978, he immediately began work on a new printer protocol. Six years of experience at Evans & Sutherland in Mountain View, Calif., had taught him where to start.

Simulating New York Harbor

In 1971, Evans & Sutherland had undertaken to equip the New York Maritime Academy with a simulator for training harbor pilots. The trainees were to sit on the mockup of a ship’s bridge, surrounded by five 12-foot-high, 30-ft-long (3.6-by-9 meter) screens displaying a computer-generated representation of New York Harbor, complete with buildings, piers, movable buoys, changing weather conditions, and other ships to be avoided. The system had to produce images in full color for five projectors at 30 frames a second.

Evans & Sutherland had never produced anything as complex. It let time slip by until, with only one of the contract’s three years left, “everybody hit the panic button,” Warnock says. So to save time, the company had the hardware and software developed in parallel, the first in Utah and the second by a team led by Warnock in California.

The rush planted the first two seeds for what was to become PostScript. Obviously, a database listing everything in the harbor was both essential and would have to be built in total ignorance as to the hardware it would eventually run on. So Warnock’s team decided to invent a language unrelated to any computer. Only when the simulator hardware was ready would they build a compiler to translate the database into the appropriate machine language.

Meanwhile, feeding information about the harbor into the database proved arduous. Putting maps on a digitizing tablet and touching them with a stylus at numerous points was not so bad; but using a keyboard to enter the details—whether the point touched was a pier of a certain type or a building or an island—was slow going. To make this task easier, John Gaffney, one of Warnock’s group, spent a weekend writing a software routine that would generate the information about the objects from menus.

By the time the harbor simulator was completed, only slightly behind schedule, Warnock had discovered how powerful an object-oriented language is. Unlike Basic or Fortran, say, which require the user to spell out every last instruction, it packs all those details into modules, or objects, which the user controls with just a few directives. Warnock had also discovered that making software device-independent “gives you a great deal of leverage and flexibility.”

Those lessons learned, his group turned to expanding Gaffney’s little interpreter into a full programming system for computer-aided design (CAD). In 1977, that project was released by Evans & Sutherland as The Design System. “It had an interactive, stack-oriented architecture,” Gaffney said, “with simple commands for pushing and popping arguments onto and from the stack and a rich dictionary for look-ups.” (Such an architecture stores data as it is received, stacking it like a pile of books. A command like “add” would “pop” the topmost pieces of data from the stack, act on them, and “push” the result back on the pile.)

Only one copy of The Design System was ever released, as a test bed for the final development, but the other company’s project director died and The Design System died with him. Warnock, however, took the stack and dictionary ideas—along with what he had learned from the harbor project—to PARC.

A “Jam” session

PARC was then using a programming language called Mesa. In 1978, soon after arriving at the center, Warnock persuaded another Xerox researcher, Martin Newell, to help him re-create The Design System in Mesa. The result, called Jam, for John and Martin, proved the concepts he brought from Evans & Sutherland were appropriate for laser printing.

Jam was object oriented and device independent, like the harbor simulator, and in some ways simpler than The Design System, because printing requires only two dimensions, versus CAD’s three. But it needed a few features, such as type fonts, found in neither of its ancestors. Moreover, Warnock recalls, “Xerox was using a different printing scheme on every printer. The Star workstations [then being developed] were crumbling under the load of trying to drive them all differently.”

So Warnock and a group of researchers headed by Charles Geschke set out to merge Jam with the older Press protocol into Interpress, a standard, device-independent language capable of driving all Xerox Corp.’s laser printers. Interpress was completed in 1981, but unhappily, the end was not in sight. Because of the compromise between Jam and Press, “the language became complicated in its redesign,” Warnock says. And Xerox begged the issue of standardization by producing several versions of the language, so the company’s older laser printers could run some form of it.

Worst of all, to Warnock, was the insistence that printers always run at their rated speeds. Since a 20-page-per-minute printer could not produce anything very complex in three seconds, he was back facing his “Page Too Complex” nemesis. The constraint derived from the copier business, Geschke explains, where “pricing of leased machines was based on copies per day. But in electronic printing, in our opinion, function was most important, so there was a real variance between our and the Xerox position.”

All the same, in the belief that any standard was better than none, Warnock and Geschke began promoting Interpress within Xerox Corp. Eventually, they won—sort of. But Xerox added, Warnock recalls, “’We’re going to keep it a secret because it is so wonderful and if we publish it the Japanese might implement it before we do.’ “Gee,’ I said, ‘A secret standard—I find this a hard concept to understand.’”

Convinced that Xerox was making a mistake, Warnock and Geschke left PARC to implement their page description language once again, but this time within a corporation they controlled. With the help of David Evans of Evans & Sutherland and William Hambrecht of Hambrecht and Quist, a San Francisco-based venture capital firm, they wrote a business plan and incorporated in December of 1982.

Desktop publishing, though, was not what Warnock and Geschke at first had in mind. The system they foresaw consisted of a workstation linked by a device-independent, page-description language like Jam to a laser printer for draft printing, a photo-typesetter for the final output, and whatever other output device they might later add. No other publishing package then available used the same software for different output devices. And they intended both to sell this setup as a turnkey system and to franchise the publishing equivalent of a one-hour photo store.

Adobe then consisted of Warnock, Geschke, and a core of other engineers hired from PARC: Daniel Putman, Thomas Boynton, and Douglas Brotz. As they planned to buy whatever hardware they needed after they had perfected their programming language, they focused first on Jam. They worked in C, on a VAX 750 running Berkeley Unix, to develop the language, and they tested in on a Sun workstation driving a full-size laser printer that they had borrowed from Digital Equipment Corp. “At that time,” recalls Putman, “most companies required that we spell our names and pay in cash, so we had to beg, borrow, and steal the tools to prototype PostScript.”

To avoid copyright problems, they licensed The Design System concepts from Evans & Sutherland. They were free to use their PARC research results, as those had been published.

Warnock and Geschke were not close-mouthed about their plans, and soon not only Jobs heard (he was then chairman of Apple Computer Inc. of Cupertino, Calif.) but also C. Gordon Bell, then vice president of engineering at Digital Equipment in Maynard, Mass. Bell told the pair that six research teams at Digital had been trying for years to devise a decent means of driving its laser printers, and if Adobe could solve the problem, Digital would be interested in licensing the solution.

Jobs had been facing a similar problem. The Macintosh was well into development, but without a letter-quality printer would go nowhere in the business market. Daisy-wheel printers were out of the question, because they could not produce the bit-mapped graphics basic to the Macintosh. But Apple’s own engineers could not get high-quality graphics out of a laser printer in time for the Macintosh introduction.

Undeterred, Jobs and Robert Belleville, then director of engineering for Apple and now director of strategic planning for Convergent Technologies Inc., San Jose, Calif., had dreamed up the perfect Macintosh laser printer—one that could produce all the fonts in the world with no help from a disk drive. But they lacked “the slightest idea of how to do this,” says Belleville, until he ran into Putman at a cocktail party, heard what Adobe was doing, and brought Jobs over for a visit.

“I was overjoyed!” recalls Belleville. “Their system could do simple things fast and also do full graphics and scanned images. And when I saw font scaling was possible across such wide ranges, we were sold.”

Jobs suggested that Adobe become a software company, sell to manufacturers instead of at retail, and negotiate a licensing agreement with Apple. Adobe liked the idea, signed the agreement with Apple at the end of 1983, and much to Hambrecht & Quist’s surprise, showed a profit at the end of its first year.

Font algorithms

Reimplementing the Jam language with its object orientation, stacks, postfix notation (in which operands precede their operators), and dictionary was relatively straightforward. Most of the research had been completed at Evans & Sutherland and at PARC. Basically all Adobe had to do was engineer it into a product, named PostScript after the postfix notation it uses and because it was to be the last thing that happened to an image before it was printed. Also, since the product had to “Print Anything,” it had to put functionality above speed and cost—the three factors traded off in the design of microprocessor systems like the one that would control the laser printer, explains Putman, now vice president of engineering at Adobe. Still, two key breakthroughs remained to be made.

One of them was creating the font algorithms, proprietary formulas for the creation of text. “Even with Interpress,” says William Paxton, director of advanced development for Adobe, “fonts were a wart on the side of an otherwise elegant design.” Interpress could do arbitrary transformations, like scale and rotate, on images, but in its early versions could not do them on bit-mapped text without degrading its quality.

PostScript, however, unifies text and graphics by storing the fonts as outline representations of the letters, not as bit maps. Back in early 1983, however, this unification was easier to propose than to realize. “Getting high-quality fonts from outline representations of characters was seen as an insoluble problem,” Warnock says, because it was hard to produce smooth curves of varying widths without jagged edges. Print quality seemed unobtainable from anything less than a phototypesetter.

But in mid-1983, Warnock says, he had an idea for a fundamentally new set of algorithms that might do the trick. His initial experiments promised success, so he set Paxton to refining the algorithms. The results are proprietary and are encrypted inside the ROMs that contain PostScript instructions because this font technology is the key distinction between Adobe’s product and others.

So successful was Adobe’s solution to the font problem that Linotype, Letraset, and other owners of the most popular typeface designs were willing for the first time to license the outline representations of their typefaces. No earlier technology had done them justice. (Ironically, Adobe is now licensing its font technology to Linotype, and Linotype is converting its entire library of some 2000 fonts into PostScript representations.)

Adobe’s other technical breakthrough is the algorithm, called Reducer, that breaks down complex shapes into simpler ones easier for PostScript to describe. Such an algorithm is a key component of any graphics language, and theoretical papers about a universal form of it were numerous: but, says Brotz, “they tended to gloss over the hard cases that arise in real applications—figures with large amounts of data and multiple intersections at the same point, for example.” So when the page printed, certain images would come out badly fragmented or warped, violating Adobe’s “Print Anything” rule.

“About a week after I had joined Adobe in 1983,” Brotz recalls, “John Warnock mentioned this rather important algorithm that had to be written. And I, with no graphics background, volunteered. Several months later, older and wiser, I realized it truly was one of the world’s hardest problems.”

But Brotz did not give up, and he says, “We have now an exactly correct reducer algorithm. It is the heart of the graphics system in PostScript.” And a tally Brotz keeps reveals that no bugs have been discovered in the Reducer in more than two years.

Adobe had agreed to deliver its software for installation into the LaserWriter during the summer of 1984. But because of marketing and manufacturing concerns, the LaserWriter itself was to be introduced in January of 1985. So the Adobe engineers used the time to tighten the code (the final release contained some 200,000 bytes) and fine-tune the algorithms. They also made some more specific changes.

One had to do with handling input devices. As originally conceived, PostScript was to have been independent of the output, but not the input, device. Warnock had thought that PostScript, to take in scanned images, would need to contain information about a wide range of optical scanners. But Brotz, after programming the parameters of just two of many scanner types, realized that the task was not only horrendous and repetitive but ate up a lot of memory.

Andy Shore, an Adobe computer scientist, overheard him complaining one day and suggested writing a PostScript procedure that would pretend that it was an input device and spit out the image information in a standard format, regardless of the characteristics of the actual standard. Brotz did not think it would work and “Warnock promptly labeled it ‘Andy’s Stupid Input Device.’”

Still, Brotz thought it might be helpful for generating test patterns, and when he implemented it, “it turned out that Andy’s Stupid Input Device was the lowest common denominator and all the special-case code could disappear.” Problems arise only when the image data has been compressed for transmission or storage; the programmer then has to insert a routine to decompress the data before it is handed to the image algorithm.

Another improvement involved performance profiling—running various tests to see what frequently used functions slowed down operation. Floating-point routines were the chief culprits because they are computationally intensive. So the team took some of the algorithms for the common operations, such as breaking curves into vectors and drawing outlines, and rewrote them in less flexible fixed-point arithmetic. Now only when fixed-point arithmetic would be too imprecise does the interpreter call the floating-point routine.

“So with no loss of generality,” says Edward Taft, Adobe senior computer scientist, “we were handling 99 percent of the cases five times faster than we were before.”

To improve the other 1 percent, Belleville sent one of his engineers over from Apple—Jerome Coonen, a recognized expert in floating point. He optimized the algorithms so, Taft says, “whereas formerly an algorithm required six multiplies, four divides, and three square roots, now it only required three multiplies, four divides, and some approximation of a square root.”

Throughout the design of PostScript, speed was regularly traded off to ensure that any image would print. The group reasoned that if they built in all this functionality, they could eventually improve the performance; but if they left out functions, they might never be able to add them back in.

However, says Putman, sometimes they had doubts. So they designed a version of PostScript that spat out information as fast as the laser moved across the page. The expense of the frame buffer was eliminated—along with the ability to print pages too complicated for the software to process in time.

Adobe called this implementation Subscript, but dropped it after six months. As Taft says, “If you’re trying to promote a standard, there is nothing worse than issuing a subset of the standard. It means that all of the applications are going to be targeted to the lowest common denominator.”

Debugging throughout the project was strenuous because the Adobe team was “terrified of putting all this code out on ROMs,” Brotz says. “We came from the school of thought that software is soft. So if you have problems, you just have another release. But Apple was telling us, ‘Hey, we always ship our system in ROM, why can’t you?’”

In January of 1985 the Apple LaserWriter was introduced, virtually bug-free. In 1984, Adobe signed licensing agreements with QMS Inc., Linotype, and Dataproducts Corp. Today, even Hewlett-Packard Co., whose PCL page description language was one of PostScript’s earliest competitors, is among the 23 companies offering PostScript interpreters for their printers.

Cheap pays off

Although the Adobe group made some key technical breakthroughs, three other components were necessary to make PostScript a runaway success not just in low-volume professional publishing but in the high-volume office environment.

As noted earlier, one was a cheap laser printer. When Adobe was founded, the cheapest cost around $10,000. It also weighed as much as a desk, so that it had to be serviced on site and sold through a distributor, not on a cash-and-carry basis. Then Canon Inc., of Tokyo, Japan, introduced the Canon LBP-CX desktop laser printer, which, moreover, printed beautifully. “If it had been poor xerography,” says Paxton, “it wouldn’t have mattered how good our technology was.”

Also on the horizon was a bit-map-based personal computer—the Apple Macintosh. All previous low-cost personal computers had used character graphics, for which daisy-wheel printers made more sense.

The third piece of luck was the decline in the price of memory chips. “We started this development on an uneconomic basis,” Warnock says. “The LaserWriter’s first controller needed forty-eight 256K DRAM chips, which up to December of 1984 cost about $30 each. That meant Apple would have had to sell that machine for about $10,000—but its computer cost $2400.”

But, with Belleville’s and Jobs’s strong support, the Adobe team bet that the memory process would drop. “Sure,” says Paxton, “the projections were that the RAM prices were going to drop, but you had to have a very strong stomach to be able to go up to the wall and pray that the door was going to open.”

Warnock comments, “Most companies will only deal with present-day technology and known costs. The brilliance of Steve Jobs is that he will say, ‘There will be this chip coming out at that price point at that time, and I will design my product to use it.’” And indeed, when the LaserWriter was announced in January of 1985, 256K RAMs cost about $4 each and the printer could be priced at $6995.

Today, some 40 companies have announced their equipment is compatible with PostScript and that their interpreters run faster and cost less than Adobe’s version. They cannot offer the same font library, but they say they have fonts and font algorithms as good as Adobe’s. At this writing, however, none of these companies had apparently shipped a PostScript clone to a customer, and they reportedly have found it harder to replicate Adobe’s work than they had anticipated.

When they do finally ship, and if they can interpret 80 or 90 percent of PostScript programs, Adobe is resigned to facing “good old-fashioned American competition,” says Geschke. The company has no patents to defend, only copyrights and trade secrets, so if other companies can reproduce Adobe’s technology, it has no legal recourse. “The most we can do is to continue to improve our technology,” Geschke says.

What’s NeXT?

Adobe’s latest technical breakthrough, demonstrated in San Francisco in January, is a version of PostScript that controls images on a computer screen as well as on a printed page. Called Display PostScript, this product is the first to provide device-independent graphics for computer screens.

Display PostScript, like the original PostScript printer protocol, had a nudge from Jobs. His new company, NeXT Inc., Palo Alto, Calif., worked with Adobe to develop it, and it will be the graphics standard for all NeXT’s computers. Digital Equipment has already licensed Display PostScript for its DEC Windows workstation architecture. If other major companies follow, Adobe could be well on the way to setting its second standard.

To probe further

Everything a programmer or user might want to know about the PostScript language is provided in “PostScript Language Tutorial and Cookbook“ and “PostScript Language Reference Manual,” both written by Adobe Systems Inc. and published by Addison Wesley Publishing Co. (New York, 1985). In addition, Adobe periodically publishes a newsletter, “Colophon,” with programming tips and news about PostScript products.

Interpress, the page description language from Xerox Corp.’s Palo Alto Research Center (PARC) that preceded PostScript in the laboratory but followed it in the marketplace, is described in the June 1986 issue of IEEE’s magazine, Computer (pp. 72-77). For more information on Xerox PARC, see “Inside the PARC: the ‘information architects,’” Spectrum, October 1985, p. 62.

“Window on PostScript” in MacWeek, Feb. 2, 1988, pp. 28-29, contains a discussion of competitors’ attempts to clone the language.

Update April 2022: While most home and office printers rely on other page description languages these days, PostScript remains the choice of graphics artists and commercial printers for its ability to accurately produce complex images. And the ubiquitous Portable Document Format (PDF) is based on PostScript.