Why didn't PostScript eliminate the need for printer drivers?












16















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?










share|improve this question


















  • 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
















16















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?










share|improve this question


















  • 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














16












16








16


3






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?










share|improve this question














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?







history printer driver postscript windows






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 21 at 4:47









rwallacerwallace

9,549447141




9,549447141








  • 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














  • 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








3




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





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




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







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




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





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




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







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




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





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










7 Answers
7






active

oldest

votes


















16















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.






share|improve this answer


























  • 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



















11














Cost



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.



Features



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.






share|improve this answer





















  • 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



















9














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.






share|improve this answer





















  • 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



















3














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.






share|improve this answer
























  • 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



















3














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).






share|improve this answer































    3














    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.






    share|improve this answer































      2














      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.






      share|improve this answer


























      • 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








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "648"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8849%2fwhy-didnt-postscript-eliminate-the-need-for-printer-drivers%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      7 Answers
      7






      active

      oldest

      votes








      7 Answers
      7






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      16















      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.






      share|improve this answer


























      • 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
















      16















      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.






      share|improve this answer


























      • 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














      16












      16








      16








      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.






      share|improve this answer
















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 22 at 17:19









      Beska

      1033




      1033










      answered Jan 21 at 10:40









      RaffzahnRaffzahn

      52.7k6124213




      52.7k6124213













      • 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



















      • 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

















      Display Postscript functioned similar to GDI on the NeXT-machines.

      – Thorbjørn Ravn Andersen
      Jan 21 at 13:50





      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





      @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





      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





      @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





      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











      11














      Cost



      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.



      Features



      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.






      share|improve this answer





















      • 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
















      11














      Cost



      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.



      Features



      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.






      share|improve this answer





















      • 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














      11












      11








      11







      Cost



      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.



      Features



      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.






      share|improve this answer















      Cost



      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.



      Features



      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 21 at 15:14

























      answered Jan 21 at 5:08









      manassehkatzmanassehkatz

      3,022623




      3,022623








      • 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














      • 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








      1




      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





      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




      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





      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




      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





      @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




      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







      @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




      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





      @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











      9














      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.






      share|improve this answer





















      • 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
















      9














      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.






      share|improve this answer





















      • 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














      9












      9








      9







      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.






      share|improve this answer















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 30 at 14:42

























      answered Jan 21 at 13:49









      Thorbjørn Ravn AndersenThorbjørn Ravn Andersen

      31519




      31519








      • 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














      • 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








      1




      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





      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




      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





      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




      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





      @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




      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





      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




      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





      @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











      3














      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.






      share|improve this answer
























      • 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
















      3














      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.






      share|improve this answer
























      • 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














      3












      3








      3







      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.






      share|improve this answer













      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.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jan 21 at 10:20









      useruser

      3,355616




      3,355616













      • 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



















      • 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

















      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





      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





      @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





      @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





      @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











      3














      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).






      share|improve this answer




























        3














        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).






        share|improve this answer


























          3












          3








          3







          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).






          share|improve this answer













          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).







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 21 at 13:34









          nekomaticnekomatic

          1314




          1314























              3














              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.






              share|improve this answer




























                3














                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.






                share|improve this answer


























                  3












                  3








                  3







                  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.






                  share|improve this answer













                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 21 at 21:09









                  supercatsupercat

                  7,362740




                  7,362740























                      2














                      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.






                      share|improve this answer


























                      • 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


















                      2














                      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.






                      share|improve this answer


























                      • 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
















                      2












                      2








                      2







                      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.






                      share|improve this answer















                      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.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Jan 22 at 9:53









                      a CVn

                      1,4201826




                      1,4201826










                      answered Jan 21 at 21:32









                      Maury MarkowitzMaury Markowitz

                      2,551525




                      2,551525













                      • 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





















                      • 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



















                      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





                      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





                      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







                      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




















                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Retrocomputing Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8849%2fwhy-didnt-postscript-eliminate-the-need-for-printer-drivers%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      MongoDB - Not Authorized To Execute Command

                      How to fix TextFormField cause rebuild widget in Flutter

                      in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith