Htydjtk

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?

In addition to the 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), and 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.

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.

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 dormat document description. It may (and does) contain many more information whan just what a printer needs.

and throw it at the printer,

Which in turn may need considerable less knowledge about a printer but still does. To be gin with, how to communicate with that printer. Keep in mind the underlaying 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 spending 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 is.

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

• Price of the printer


• Device dependant interface handling

and, lets not forget

• Support of aplication 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 counterthesis 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 at 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 Microsofts 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 reason 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 relaid 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.