In the days of dot matrix printers connected by RS-232 or the IBM/Centronics parallel port, each with its own quirky set of commands, it's obvious why printer drivers were a necessary and important invention: they save every program from needing its own separate encyclopedic knowledge of every printer on the market.

But then came PostScript, the theory behind which was that you would prepare a printable file in a standard format and throw it at the printer, which would contain its own knowledge of how to translate it to bitmap on paper.

Yet decades later, printer drivers are still with us. Why?

I know there was an issue with Adobe charging on the order of a thousand dollars for a PostScript license, which was fine when a laser printer cost ten thousand, but problematic when printers got cheaper. At some point Apple and Microsoft got together to create an alternative... right, here's a summary of that event: https://appleinsider.com/articles/10/05/14/adobe_apple_war_on_flash_reminiscent_of_postscript_struggle which also refers to the same book I read about it in.

The summary calls TrueImage a PostScript clone. Was it actually such in the sense of an independent reimplementation of the same language? In that case the issue of obviating the need for printer drivers should stand. Or was it a different language? If so, is that the reason drivers continued to be needed?

  • 3
    There are still printers around that doesn't talk Postscript. They use the printer driver as a translator to whatever they talk. – UncleBod Jan 21 at 7:23
  • 14
    PostScript was quite demanding. In the early days a PostScript printer might well be the most powerful computer in the building, hence expensive. – Thorbjørn Ravn Andersen Jan 21 at 13:44
  • 4
    The point of PostScript is to make document manipulating applications cheaper and more compatible. The translation from (cheap) application PostScript output to (cheap) printer is done in the driver. PostScript made printer drivers even more important than before, while vastly simplifying printing from applications. There's a lot more applications that support printing than printer drivers. Drivers are a lot cheaper than "a 50 cent chip in each printer". – Luaan Jan 21 at 13:49
  • 7
    Keep in mind that, when PostScript started to evolve, a printer capable of interpreting PS had to have CPU and memory at least at par with the workstation connected: Connecting a Macintosh to an Apple LaserWriter in the early 80s meant you had more memory and a faster CPU in the printer than in the computer... – tofro Jan 21 at 15:50
  • 5
    There's more to printing than just rendering the document. How about things like 2-sided printing? You need the driver to tell you whether the device even has that capability. – Barmar Jan 21 at 18:10

they save every program from needing its own separate encyclopedic knowledge of every printer on the market.

But then came PostScript, the theory behind which was that you would prepare a printable file in a standard format

For one, Postscript isn't a standard format printable file, but a standard format document description. It may (and does) contain many more information than just what a printer needs.

and throw it at the printer,

Which in turn may need considerably less knowledge about a printer but still does need some. To begin with, how to communicate with that printer? Keep in mind the underlying layer isn't as defined as one might think. Starting with what lines of a Centronics interface are supported or if there's a way (and which way) for return information. The point is that this not just differs between interfaces (like serial vs. Centronics or USB), but also by what printer is connected.

Postscript only cares for document description, not interface handling. It's the very basic idea of Postscript to be device agnostic.

which would contain its own knowledge of how to translate it to bitmap on paper.

Which would mean providing the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-market is.

Yet decades later, printer drivers are still with us. Why?

  • Price of the printer
  • Device-dependent interface handling

and, let's not forget

  • Support of applications using existing interfaces to print.

In fact, all these reasons made Microsoft introduce the GDI-printers (*1). GDI (Graphics Device Interface) is the device independent rendering engine of Windows. Its use is the counter-thesis to what you expect of Postscript. Printers can be as primitive as possible, since all high-level handling is done in the GDI driver - a component that is already on the PC to handle screen output anyway (*2).

During the 90s GDI-printers where quite successful - not in the least due their price advantage.

The summary calls TrueImage a PostScript clone. Was it actually such in the sense of an independent reimplementation of the same language?

Yes, it was. It's the base for Microsoft's own Postscript interpreter (used on top of GDI), as well as being implemented by Oki in their Postscript (compatible) laser printers. Oh, and don't forget, it solved the Apple/Adobe fight by making Adobe lower the price to a level Apple could agree to.

In that case the issue of obviating the need for printer drivers should stand. Or was it a different language? If so, is that the reason drivers continued to be needed?

No, the reasons are still different interfaces, different interface protocols and of course printers without Postscript.

*1 - The idea was already used years before by Atari for the SLM 804. Here the printer buffered almost nothing and relied on just-in-time DMA transfer from the ST. Every kind of rendering was done by the GEM-VDI (Virtual Device Interface). Ofc, with 'just' 4 MiB maximum memory it did create problems with very detailed documents.

*2 - Kind of the reverse way of the evolution of Postscript to Display Postscript, intended to be the as sole source of screen content on the NeXT.

  • Display Postscript functioned similar to GDI on the NeXT-machines. – Thorbjørn Ravn Andersen Jan 21 at 13:50
  • @ThorbjørnRavnAndersen And your point is? – Raffzahn Jan 21 at 14:07
  • That Display Postscript was not a printer feature now you are doing a historical tour de force. – Thorbjørn Ravn Andersen Jan 21 at 14:21
  • @ThorbjørnRavnAndersen Mind to read the answer again (and possibly take what's said in context)? There is no word, that Display Postscript is a printer feature. – Raffzahn Jan 21 at 14:26
  • DPS+NeXT Laser Printer is the same concept as GDIP or SLM804, but several years before either. DPS had "display" in the name, but was still a complete PS system. I recall writing programs in PS that would then interpret in real time on the screen, which was fun. Never got to use NeWS. – Maury Markowitz Jan 21 at 20:57


There are significant licensing costs and equipment costs. I'm sure PostScript needs quite a bit more RAM & processing than some of the lower levels of PCL and similar printer languages. As I noted in my answer on trackballs and elsewhere, even a small increase in cost can have a big impact on sales and/or profitability, particularly at the low end of the market. A quick search finds that the original HP LaserJet (not the first laser printer, but one of the first for the mass market) cost $3,495 with a whopping 128k of RAM. It took a while to get to today's ~ $100 printers with 32 Meg. of RAM - and many of those printers still don't support PostScript.


Even limiting things to places where PostScript "makes sense" (i.e., page-oriented laser and inkjet printers - excluding line-oriented dot-matrix and similar printers), there are other things that go into print drivers:

  • Connectivity - PostScript handles the print job once it is in the printer, it doesn't help get it to the printer
  • Paper Handling - Duplexing, paper sizes, paper trays, etc. Even today these are handled differently by every manufacturer, and getting the codes to handle them directly like my question on Okidata are not so easy to find.

Plus there are applications where simply being able to spit out simple ASCII text instead of a full PostScript (or even formatted PCL) is what you need to do. So PostScript isn't the solution for everyone, and most page printers (e.g., HP, Brother, Okidata) that support PostScript also support PCL or other formats.

  • 1
    PostScript could define wanted paper forms, and had a standard mechanism for defining printer media capabilities. PostScript also needed quite a powerful processor in the printer, while DMPs could make do with a simple microcontroller. – scruss Jan 21 at 5:17
  • 3
    PostScript did indeed need a lot of computing power in the early eighties. Nowadays fifty cents worth of silicon will probably suffice, but for all I know, maybe by the time that became true, printer drivers had just become an institutional habit that no one any longer saw any reason to question, like the proverbial onion in the varnish. – rwallace Jan 21 at 5:23
  • 2
    @rwallace Well, even if it's 50 cents, that can still make a huge difference. Remember, you're making hardware with huge competition - there's hundreds of alternatives that are pretty much the same as yours, and you might even be selling the printer at a loss. There's not a lot of pressure on better accessibility, and a lot of pressure on lower cost. I've seen a few printers that work really well, but you couldn't really find them - no "This is the best printer ever! Plug it, and it works!", perhaps to avoid the impression of saying "All our other printers suck!". – Luaan Jan 21 at 13:45
  • 2
    @rwallace: Didn't someone literally invent PDF by trying to speed up a PostScript printout? And now, some decades later, PDF is one of the standard print job formats for "driverless" printing (IPP-Everywhere). – grawity Jan 21 at 14:35
  • 1
    @grawity: That would be a good question on its own. The brief answer is no, it was invented to use PostScript for a different purpose (as a document file format). Although many PostScript primitives have abbreviations in PDF -- shortening file sizes -- it doesn't significantly speed up processing time. – Dr Sheldon Jan 22 at 0:10

PostScript was quite demanding. In the early days a PostScript printer might well be the most powerful computer in the building, hence expensive. University students ran jobs on the printer to get done faster.

In a world where price is important, this was most likely the primary reason. Look at the cheapest printers available and check if they run Postscript. The answer is probably no (as there most likely is a license fee attached).

Also the REAL contender for the ubiquous language is PDF, which is essentially a version of PostScript which only describes pages, but cannot run programs.

PDF is inside Apples Airprint which is driverless, and this - combined with a lot of good PDF-engines - will most likely make this so cheap that it will be the future.

So in a way, Postscript is overtaking the printer world, just not in the form you thought.

  • 1
    Not gonna lie, imagining a university server room with a cluster of PostScript printers doing all the number crunching made me chuckle. – undercat Jan 21 at 14:32
  • 2
    I will rigorously deny writing a postscript program at uni that sat on the printer and parsed incoming postscript with the objective of just occasionally replacing a 'b' with 'd' in the users job.... Nope, not me, not the week before project submissions! – Dan Mills Jan 21 at 21:41
  • 1
    @DrSheldon I can't support such a claim, but when I was an undergrad, one of the grad students told me that the LaserWriters ran his Forth-like programs faster than our VAX-11/750. He may have been yanking my chain. – Erik Bennett Jan 22 at 1:01
  • 3
    During my freshman year of college, I was in the computer lab after hours, and discovered the printer wasn't printing my job. Checking the queue, there was one job on the printer, "1 page", which was stuck there for over half an hour before it finished without printing anything. Talking to the computer center admin: "Oh, yeah, it's CS414 hell week. That printer has a vector processor. That's going to be happening a lot this week, outside of lab class hours." I'm not sure how much evidence you need for my anecdote to count as actual evidence. – Ed Grimm Jan 22 at 2:23
  • 1
    @ErikBennett quoth Wikipedia "The VAX-11/750 ... CPU has a 320 ns cycle time (3.125 MHz)" so I can believe a 12 MHz 68000 (that your program gets sole use of!) would be faster. – Coxy Jan 22 at 2:43

In addition to manassehkatz's answer, the other reason for printer drivers is to reduce cost in the printer. A postscript interpreter requires significant computing resources, especially for complex documents. By doing that processing on the computer and then sending a simpler, easier to handle data stream to the printer you can leverage the greater power of the computer to do that work.

The result is a printer that can print quickly even with less processing power on board. Historically printing was such a complex process that there was often an entire computer dedicated to it, and then that computer was moved into the printer itself, and finally the client PC itself was used.

Embedded software developers are also a lot more expensive than desktop ones, so it's usually cheaper to develop drivers than it is to develop complex printer firmware.

A similar thing happened with dial-up modems, where cheap "WinModems" reduced the complexity of the modem itself by offloading much of the processing on to the host computer.

  • After WiFi printing became popular and computer power cheap, this trend has reversed. Now printers need to be complete computers to do what is expected. Also people being burnt by upgrading windows and finding that the drivers doesn’t work anymore rendering their printer useless, doesn’t help. You generally only do that once – Thorbjørn Ravn Andersen Jan 24 at 13:46
  • @ThorbjørnRavnAndersen: I have an ALPS printer that could print gold and silver metalic "inks" [actually, dry stuff on a ribbon]. Doesn't seem to be able to do that on anything since Win98, alas, and I haven't seen any printer since that could do that either. – supercat Jan 29 at 16:42
  • @supercat So you run Win98 in a virtual machine to use your printer? – Thorbjørn Ravn Andersen Jan 30 at 14:42
  • @ThorbjørnRavnAndersen: It's been in a box for a long time, but if I find the driver disks I've been thinking it might be interesting to take to something like a Vintage Computer Fair. – supercat Jan 30 at 15:52

I can't readily find a really definitive reference, but the LaserWriter driver on Classic Mac OS could be used for basic printing functionality on many PostScript printers, and it appears a similar thing exists on modern macOS (f.k.a. OS X). Printer-specific configuration and functions are specified to this driver in a PostScript Printer Description (ppd) file.

In any case, as other answers and comments indicate, PostScript can't eliminate printer drivers because most printers today don't use PostScript. Back when the first LaserWriters came on the market, they were made to connect to computers that had nowhere near enough processing power and memory to render a whole page of text and graphics at 300 dots per inch, so the computer needed to transmit the data to be printed in a compact format that encoded what the renderer needed to do, and the processing power and memory - and the actual fonts! - were on board the printer itself.

Now that our computers have ample power for handling this task, this reason for printers to understand PostScript is mostly gone, except perhaps at the highest end.

This article suggests that PostScript itself is on the way out as a standard, being replaced by PDF (which evolved out of PostScript).


Yet another factor that hasn't been mentioned is that ink jet printers have become far more common than laser printers, and have a critical ability that laser printers lack, which in turn propelled the use of PostScript: the ability to suspend and resume printing in the middle of a page.

Normal printer drivers could print pages which were too complex to fit in memory by processing all of the drawing operations on a bitmap that was large enough to handle a narrow strip at the top of the page, ignoring all operations that fell outside that region. The driver could then feed that strip to the printer, clear the bitmap, and then proceed to reprocess all of the drawing operations, but using a bitmap that represented the next strip on the page. Once that was done, it could print that, clear the bitmap, and render the strip after that.

PostScript is not designed to facilitate strip-buffering techniques, since its design assumes that any graphics operation that is requested can be performed directly on the output bitmap and then forgotten about. If most printers required a page-at-once page rendering model, using PostScript might make sense as a printer communications language, but that isn't, and likely never will be, the case.


I think the most basic answer to your question is that PS did not describe an interface, only the document.

So at a minimum you needed to implement some sort of physical interface on the printer, say Ethernet or Centronics, and then write a driver for the computer. For much of the history since then, this basic pattern has not changed.

It's worth pointing out that the original rendering engine from Adobe did include the interface and was licensed to various vendors. Apple licensed it and replaced their code with an AppleTalk interface. You still needed the driver to talk to the printer's job control system though.

But things are changing. Now there is a single universal physical interface one can use for this sort of thing, it's the internet. Printers also have lots of leftover power and memory too. So you can short circuit much of the remaining gap by assigning the printer a local-only DNS (like Bonjour) and sending it PDFs. All that remains is the protocol to "send", which IIRC, HP uses SMTP to complete. This reduces the driver to something that creates a PDF and mails it to a known 'net node.

  • Isn't that more of just pushing the driver onto a remote machine? The 'node' as you call it still needs to now how to interface the printer - depending on interface and printer. Isn't it? – Raffzahn Jan 21 at 21:53
  • Yup. But it's inside the printer, so I don't think there's any practical difference. – Maury Markowitz Jan 21 at 22:05
  • Just because server and printer are in the same housing (or better the server nowadays so small that it fits inside the printer) doesn't make it any difference. But I agree, from a user perspective it may as well be. Oh, and as usual, it creates loads of new classes of 'interface' errors - eventually calling for (application/computer side) drivers again :)) – Raffzahn Jan 21 at 22:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.