Why didn't PostScript eliminate the need for printer drivers?
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
|
show 2 more comments
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
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
|
show 2 more comments
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
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
history printer driver postscript windows
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
|
show 2 more comments
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
|
show 2 more comments
7 Answers
7
active
oldest
votes
they save every program from needing its own separate encyclopedic knowledge of every printer on the market.
But then came PostScript, the theory behind which was that you would prepare a printable file in a standard format
For one, Postscript isn't a standard format printable file, but a standard format document description. It may (and does) contain many more information than just what a printer needs.
and throw it at the printer,
Which in turn may need considerably less knowledge about a printer but still does need some. To begin with, how to communicate with that printer? Keep in mind the underlying layer isn't as defined as one might think. Starting with what lines of a Centronics interface are supported or if there's a way (and which way) for return information. The point is that this not just differs between interfaces (like serial vs. Centronics or USB), but also by what printer is connected.
Postscript only cares for document description, not interface handling. It's the very basic idea of Postscript to be device agnostic.
which would contain its own knowledge of how to translate it to bitmap on paper.
Which would mean providing the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-market is.
Yet decades later, printer drivers are still with us. Why?
- Price of the printer
- Device-dependent interface handling
and, let's not forget
- Support of applications using existing interfaces to print.
In fact, all these reasons made Microsoft introduce the GDI-printers (*1). GDI (Graphics Device Interface) is the device independent rendering engine of Windows. Its use is the counter-thesis to what you expect of Postscript. Printers can be as primitive as possible, since all high-level handling is done in the GDI driver - a component that is already on the PC to handle screen output anyway (*2).
During the 90s GDI-printers where quite successful - not in the least due their price advantage.
The summary calls TrueImage a PostScript clone. Was it actually such in the sense of an independent reimplementation of the same language?
Yes, it was. It's the base for Microsoft's own Postscript interpreter (used on top of GDI), as well as being implemented by Oki in their Postscript (compatible) laser printers. Oh, and don't forget, it solved the Apple/Adobe fight by making Adobe lower the price to a level Apple could agree to.
In that case the issue of obviating the need for printer drivers should stand. Or was it a different language? If so, is that the reason drivers continued to be needed?
No, the reasons are still different interfaces, different interface protocols and of course printers without Postscript.
*1 - The idea was already used years before by Atari for the SLM 804. Here the printer buffered almost nothing and relied on just-in-time DMA transfer from the ST. Every kind of rendering was done by the GEM-VDI (Virtual Device Interface). Ofc, with 'just' 4 MiB maximum memory it did create problems with very detailed documents.
*2 - Kind of the reverse way of the evolution of Postscript to Display Postscript, intended to be the as sole source of screen content on the NeXT.
Display Postscript functioned similar to GDI on the NeXT-machines.
– Thorbjørn Ravn Andersen
Jan 21 at 13:50
@ThorbjørnRavnAndersen And your point is?
– Raffzahn
Jan 21 at 14:07
That Display Postscript was not a printer feature now you are doing a historical tour de force.
– Thorbjørn Ravn Andersen
Jan 21 at 14:21
@ThorbjørnRavnAndersen Mind to read the answer again (and possibly take what's said in context)? There is no word, that Display Postscript is a printer feature.
– Raffzahn
Jan 21 at 14:26
DPS+NeXT Laser Printer is the same concept as GDIP or SLM804, but several years before either. DPS had "display" in the name, but was still a complete PS system. I recall writing programs in PS that would then interpret in real time on the screen, which was fun. Never got to use NeWS.
– Maury Markowitz
Jan 21 at 20:57
|
show 1 more comment
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.
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
add a comment |
PostScript was quite demanding. In the early days a PostScript printer might well be the most powerful computer in the building, hence expensive. University students ran jobs on the printer to get done faster.
In a world where price is important, this was most likely the primary reason. Look at the cheapest printers available and check if they run Postscript. The answer is probably no (as there most likely is a license fee attached).
Also the REAL contender for the ubiquous language is PDF, which is essentially a version of PostScript which only describes pages, but cannot run programs.
PDF is inside Apples Airprint which is driverless, and this - combined with a lot of good PDF-engines - will most likely make this so cheap that it will be the future.
So in a way, Postscript is overtaking the printer world, just not in the form you thought.
1
Not gonna lie, imagining a university server room with a cluster of PostScript printers doing all the number crunching made me chuckle.
– undercat
Jan 21 at 14:32
2
I will rigorously deny writing a postscript program at uni that sat on the printer and parsed incoming postscript with the objective of just occasionally replacing a 'b' with 'd' in the users job.... Nope, not me, not the week before project submissions!
– Dan Mills
Jan 21 at 21:41
1
@DrSheldon I can't support such a claim, but when I was an undergrad, one of the grad students told me that the LaserWriters ran his Forth-like programs faster than our VAX-11/750. He may have been yanking my chain.
– Erik Bennett
Jan 22 at 1:01
3
During my freshman year of college, I was in the computer lab after hours, and discovered the printer wasn't printing my job. Checking the queue, there was one job on the printer, "1 page", which was stuck there for over half an hour before it finished without printing anything. Talking to the computer center admin: "Oh, yeah, it's CS414 hell week. That printer has a vector processor. That's going to be happening a lot this week, outside of lab class hours." I'm not sure how much evidence you need for my anecdote to count as actual evidence.
– Ed Grimm
Jan 22 at 2:23
1
@ErikBennett quoth Wikipedia "The VAX-11/750 ... CPU has a 320 ns cycle time (3.125 MHz)" so I can believe a 12 MHz 68000 (that your program gets sole use of!) would be faster.
– Coxy
Jan 22 at 2:43
|
show 5 more comments
In addition to manassehkatz's answer, the other reason for printer drivers is to reduce cost in the printer. A postscript interpreter requires significant computing resources, especially for complex documents. By doing that processing on the computer and then sending a simpler, easier to handle data stream to the printer you can leverage the greater power of the computer to do that work.
The result is a printer that can print quickly even with less processing power on board. Historically printing was such a complex process that there was often an entire computer dedicated to it, and then that computer was moved into the printer itself, and finally the client PC itself was used.
Embedded software developers are also a lot more expensive than desktop ones, so it's usually cheaper to develop drivers than it is to develop complex printer firmware.
A similar thing happened with dial-up modems, where cheap "WinModems" reduced the complexity of the modem itself by offloading much of the processing on to the host computer.
After WiFi printing became popular and computer power cheap, this trend has reversed. Now printers need to be complete computers to do what is expected. Also people being burnt by upgrading windows and finding that the drivers doesn’t work anymore rendering their printer useless, doesn’t help. You generally only do that once
– Thorbjørn Ravn Andersen
Jan 24 at 13:46
@ThorbjørnRavnAndersen: I have an ALPS printer that could print gold and silver metalic "inks" [actually, dry stuff on a ribbon]. Doesn't seem to be able to do that on anything since Win98, alas, and I haven't seen any printer since that could do that either.
– supercat
Jan 29 at 16:42
@supercat So you run Win98 in a virtual machine to use your printer?
– Thorbjørn Ravn Andersen
Jan 30 at 14:42
@ThorbjørnRavnAndersen: It's been in a box for a long time, but if I find the driver disks I've been thinking it might be interesting to take to something like a Vintage Computer Fair.
– supercat
Jan 30 at 15:52
add a comment |
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).
add a comment |
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.
add a comment |
I think the most basic answer to your question is that PS did not describe an interface, only the document.
So at a minimum you needed to implement some sort of physical interface on the printer, say Ethernet or Centronics, and then write a driver for the computer. For much of the history since then, this basic pattern has not changed.
It's worth pointing out that the original rendering engine from Adobe did include the interface and was licensed to various vendors. Apple licensed it and replaced their code with an AppleTalk interface. You still needed the driver to talk to the printer's job control system though.
But things are changing. Now there is a single universal physical interface one can use for this sort of thing, it's the internet. Printers also have lots of leftover power and memory too. So you can short circuit much of the remaining gap by assigning the printer a local-only DNS (like Bonjour) and sending it PDFs. All that remains is the protocol to "send", which IIRC, HP uses SMTP to complete. This reduces the driver to something that creates a PDF and mails it to a known 'net node.
Isn't that more of just pushing the driver onto a remote machine? The 'node' as you call it still needs to now how to interface the printer - depending on interface and printer. Isn't it?
– Raffzahn
Jan 21 at 21:53
Yup. But it's inside the printer, so I don't think there's any practical difference.
– Maury Markowitz
Jan 21 at 22:05
Just because server and printer are in the same housing (or better the server nowadays so small that it fits inside the printer) doesn't make it any difference. But I agree, from a user perspective it may as well be. Oh, and as usual, it creates loads of new classes of 'interface' errors - eventually calling for (application/computer side) drivers again :))
– Raffzahn
Jan 21 at 22:09
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
they save every program from needing its own separate encyclopedic knowledge of every printer on the market.
But then came PostScript, the theory behind which was that you would prepare a printable file in a standard format
For one, Postscript isn't a standard format printable file, but a standard format document description. It may (and does) contain many more information than just what a printer needs.
and throw it at the printer,
Which in turn may need considerably less knowledge about a printer but still does need some. To begin with, how to communicate with that printer? Keep in mind the underlying layer isn't as defined as one might think. Starting with what lines of a Centronics interface are supported or if there's a way (and which way) for return information. The point is that this not just differs between interfaces (like serial vs. Centronics or USB), but also by what printer is connected.
Postscript only cares for document description, not interface handling. It's the very basic idea of Postscript to be device agnostic.
which would contain its own knowledge of how to translate it to bitmap on paper.
Which would mean providing the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-market is.
Yet decades later, printer drivers are still with us. Why?
- Price of the printer
- Device-dependent interface handling
and, let's not forget
- Support of applications using existing interfaces to print.
In fact, all these reasons made Microsoft introduce the GDI-printers (*1). GDI (Graphics Device Interface) is the device independent rendering engine of Windows. Its use is the counter-thesis to what you expect of Postscript. Printers can be as primitive as possible, since all high-level handling is done in the GDI driver - a component that is already on the PC to handle screen output anyway (*2).
During the 90s GDI-printers where quite successful - not in the least due their price advantage.
The summary calls TrueImage a PostScript clone. Was it actually such in the sense of an independent reimplementation of the same language?
Yes, it was. It's the base for Microsoft's own Postscript interpreter (used on top of GDI), as well as being implemented by Oki in their Postscript (compatible) laser printers. Oh, and don't forget, it solved the Apple/Adobe fight by making Adobe lower the price to a level Apple could agree to.
In that case the issue of obviating the need for printer drivers should stand. Or was it a different language? If so, is that the reason drivers continued to be needed?
No, the reasons are still different interfaces, different interface protocols and of course printers without Postscript.
*1 - The idea was already used years before by Atari for the SLM 804. Here the printer buffered almost nothing and relied on just-in-time DMA transfer from the ST. Every kind of rendering was done by the GEM-VDI (Virtual Device Interface). Ofc, with 'just' 4 MiB maximum memory it did create problems with very detailed documents.
*2 - Kind of the reverse way of the evolution of Postscript to Display Postscript, intended to be the as sole source of screen content on the NeXT.
Display Postscript functioned similar to GDI on the NeXT-machines.
– Thorbjørn Ravn Andersen
Jan 21 at 13:50
@ThorbjørnRavnAndersen And your point is?
– Raffzahn
Jan 21 at 14:07
That Display Postscript was not a printer feature now you are doing a historical tour de force.
– Thorbjørn Ravn Andersen
Jan 21 at 14:21
@ThorbjørnRavnAndersen Mind to read the answer again (and possibly take what's said in context)? There is no word, that Display Postscript is a printer feature.
– Raffzahn
Jan 21 at 14:26
DPS+NeXT Laser Printer is the same concept as GDIP or SLM804, but several years before either. DPS had "display" in the name, but was still a complete PS system. I recall writing programs in PS that would then interpret in real time on the screen, which was fun. Never got to use NeWS.
– Maury Markowitz
Jan 21 at 20:57
|
show 1 more comment
they save every program from needing its own separate encyclopedic knowledge of every printer on the market.
But then came PostScript, the theory behind which was that you would prepare a printable file in a standard format
For one, Postscript isn't a standard format printable file, but a standard format document description. It may (and does) contain many more information than just what a printer needs.
and throw it at the printer,
Which in turn may need considerably less knowledge about a printer but still does need some. To begin with, how to communicate with that printer? Keep in mind the underlying layer isn't as defined as one might think. Starting with what lines of a Centronics interface are supported or if there's a way (and which way) for return information. The point is that this not just differs between interfaces (like serial vs. Centronics or USB), but also by what printer is connected.
Postscript only cares for document description, not interface handling. It's the very basic idea of Postscript to be device agnostic.
which would contain its own knowledge of how to translate it to bitmap on paper.
Which would mean providing the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-market is.
Yet decades later, printer drivers are still with us. Why?
- Price of the printer
- Device-dependent interface handling
and, let's not forget
- Support of applications using existing interfaces to print.
In fact, all these reasons made Microsoft introduce the GDI-printers (*1). GDI (Graphics Device Interface) is the device independent rendering engine of Windows. Its use is the counter-thesis to what you expect of Postscript. Printers can be as primitive as possible, since all high-level handling is done in the GDI driver - a component that is already on the PC to handle screen output anyway (*2).
During the 90s GDI-printers where quite successful - not in the least due their price advantage.
The summary calls TrueImage a PostScript clone. Was it actually such in the sense of an independent reimplementation of the same language?
Yes, it was. It's the base for Microsoft's own Postscript interpreter (used on top of GDI), as well as being implemented by Oki in their Postscript (compatible) laser printers. Oh, and don't forget, it solved the Apple/Adobe fight by making Adobe lower the price to a level Apple could agree to.
In that case the issue of obviating the need for printer drivers should stand. Or was it a different language? If so, is that the reason drivers continued to be needed?
No, the reasons are still different interfaces, different interface protocols and of course printers without Postscript.
*1 - The idea was already used years before by Atari for the SLM 804. Here the printer buffered almost nothing and relied on just-in-time DMA transfer from the ST. Every kind of rendering was done by the GEM-VDI (Virtual Device Interface). Ofc, with 'just' 4 MiB maximum memory it did create problems with very detailed documents.
*2 - Kind of the reverse way of the evolution of Postscript to Display Postscript, intended to be the as sole source of screen content on the NeXT.
Display Postscript functioned similar to GDI on the NeXT-machines.
– Thorbjørn Ravn Andersen
Jan 21 at 13:50
@ThorbjørnRavnAndersen And your point is?
– Raffzahn
Jan 21 at 14:07
That Display Postscript was not a printer feature now you are doing a historical tour de force.
– Thorbjørn Ravn Andersen
Jan 21 at 14:21
@ThorbjørnRavnAndersen Mind to read the answer again (and possibly take what's said in context)? There is no word, that Display Postscript is a printer feature.
– Raffzahn
Jan 21 at 14:26
DPS+NeXT Laser Printer is the same concept as GDIP or SLM804, but several years before either. DPS had "display" in the name, but was still a complete PS system. I recall writing programs in PS that would then interpret in real time on the screen, which was fun. Never got to use NeWS.
– Maury Markowitz
Jan 21 at 20:57
|
show 1 more comment
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.
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.
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
|
show 1 more comment
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
|
show 1 more comment
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
PostScript was quite demanding. In the early days a PostScript printer might well be the most powerful computer in the building, hence expensive. University students ran jobs on the printer to get done faster.
In a world where price is important, this was most likely the primary reason. Look at the cheapest printers available and check if they run Postscript. The answer is probably no (as there most likely is a license fee attached).
Also the REAL contender for the ubiquous language is PDF, which is essentially a version of PostScript which only describes pages, but cannot run programs.
PDF is inside Apples Airprint which is driverless, and this - combined with a lot of good PDF-engines - will most likely make this so cheap that it will be the future.
So in a way, Postscript is overtaking the printer world, just not in the form you thought.
1
Not gonna lie, imagining a university server room with a cluster of PostScript printers doing all the number crunching made me chuckle.
– undercat
Jan 21 at 14:32
2
I will rigorously deny writing a postscript program at uni that sat on the printer and parsed incoming postscript with the objective of just occasionally replacing a 'b' with 'd' in the users job.... Nope, not me, not the week before project submissions!
– Dan Mills
Jan 21 at 21:41
1
@DrSheldon I can't support such a claim, but when I was an undergrad, one of the grad students told me that the LaserWriters ran his Forth-like programs faster than our VAX-11/750. He may have been yanking my chain.
– Erik Bennett
Jan 22 at 1:01
3
During my freshman year of college, I was in the computer lab after hours, and discovered the printer wasn't printing my job. Checking the queue, there was one job on the printer, "1 page", which was stuck there for over half an hour before it finished without printing anything. Talking to the computer center admin: "Oh, yeah, it's CS414 hell week. That printer has a vector processor. That's going to be happening a lot this week, outside of lab class hours." I'm not sure how much evidence you need for my anecdote to count as actual evidence.
– Ed Grimm
Jan 22 at 2:23
1
@ErikBennett quoth Wikipedia "The VAX-11/750 ... CPU has a 320 ns cycle time (3.125 MHz)" so I can believe a 12 MHz 68000 (that your program gets sole use of!) would be faster.
– Coxy
Jan 22 at 2:43
|
show 5 more comments
PostScript was quite demanding. In the early days a PostScript printer might well be the most powerful computer in the building, hence expensive. University students ran jobs on the printer to get done faster.
In a world where price is important, this was most likely the primary reason. Look at the cheapest printers available and check if they run Postscript. The answer is probably no (as there most likely is a license fee attached).
Also the REAL contender for the ubiquous language is PDF, which is essentially a version of PostScript which only describes pages, but cannot run programs.
PDF is inside Apples Airprint which is driverless, and this - combined with a lot of good PDF-engines - will most likely make this so cheap that it will be the future.
So in a way, Postscript is overtaking the printer world, just not in the form you thought.
1
Not gonna lie, imagining a university server room with a cluster of PostScript printers doing all the number crunching made me chuckle.
– undercat
Jan 21 at 14:32
2
I will rigorously deny writing a postscript program at uni that sat on the printer and parsed incoming postscript with the objective of just occasionally replacing a 'b' with 'd' in the users job.... Nope, not me, not the week before project submissions!
– Dan Mills
Jan 21 at 21:41
1
@DrSheldon I can't support such a claim, but when I was an undergrad, one of the grad students told me that the LaserWriters ran his Forth-like programs faster than our VAX-11/750. He may have been yanking my chain.
– Erik Bennett
Jan 22 at 1:01
3
During my freshman year of college, I was in the computer lab after hours, and discovered the printer wasn't printing my job. Checking the queue, there was one job on the printer, "1 page", which was stuck there for over half an hour before it finished without printing anything. Talking to the computer center admin: "Oh, yeah, it's CS414 hell week. That printer has a vector processor. That's going to be happening a lot this week, outside of lab class hours." I'm not sure how much evidence you need for my anecdote to count as actual evidence.
– Ed Grimm
Jan 22 at 2:23
1
@ErikBennett quoth Wikipedia "The VAX-11/750 ... CPU has a 320 ns cycle time (3.125 MHz)" so I can believe a 12 MHz 68000 (that your program gets sole use of!) would be faster.
– Coxy
Jan 22 at 2:43
|
show 5 more comments
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.
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.
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
|
show 5 more comments
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
|
show 5 more comments
In addition to manassehkatz's answer, the other reason for printer drivers is to reduce cost in the printer. A postscript interpreter requires significant computing resources, especially for complex documents. By doing that processing on the computer and then sending a simpler, easier to handle data stream to the printer you can leverage the greater power of the computer to do that work.
The result is a printer that can print quickly even with less processing power on board. Historically printing was such a complex process that there was often an entire computer dedicated to it, and then that computer was moved into the printer itself, and finally the client PC itself was used.
Embedded software developers are also a lot more expensive than desktop ones, so it's usually cheaper to develop drivers than it is to develop complex printer firmware.
A similar thing happened with dial-up modems, where cheap "WinModems" reduced the complexity of the modem itself by offloading much of the processing on to the host computer.
After WiFi printing became popular and computer power cheap, this trend has reversed. Now printers need to be complete computers to do what is expected. Also people being burnt by upgrading windows and finding that the drivers doesn’t work anymore rendering their printer useless, doesn’t help. You generally only do that once
– Thorbjørn Ravn Andersen
Jan 24 at 13:46
@ThorbjørnRavnAndersen: I have an ALPS printer that could print gold and silver metalic "inks" [actually, dry stuff on a ribbon]. Doesn't seem to be able to do that on anything since Win98, alas, and I haven't seen any printer since that could do that either.
– supercat
Jan 29 at 16:42
@supercat So you run Win98 in a virtual machine to use your printer?
– Thorbjørn Ravn Andersen
Jan 30 at 14:42
@ThorbjørnRavnAndersen: It's been in a box for a long time, but if I find the driver disks I've been thinking it might be interesting to take to something like a Vintage Computer Fair.
– supercat
Jan 30 at 15:52
add a comment |
In addition to manassehkatz's answer, the other reason for printer drivers is to reduce cost in the printer. A postscript interpreter requires significant computing resources, especially for complex documents. By doing that processing on the computer and then sending a simpler, easier to handle data stream to the printer you can leverage the greater power of the computer to do that work.
The result is a printer that can print quickly even with less processing power on board. Historically printing was such a complex process that there was often an entire computer dedicated to it, and then that computer was moved into the printer itself, and finally the client PC itself was used.
Embedded software developers are also a lot more expensive than desktop ones, so it's usually cheaper to develop drivers than it is to develop complex printer firmware.
A similar thing happened with dial-up modems, where cheap "WinModems" reduced the complexity of the modem itself by offloading much of the processing on to the host computer.
After WiFi printing became popular and computer power cheap, this trend has reversed. Now printers need to be complete computers to do what is expected. Also people being burnt by upgrading windows and finding that the drivers doesn’t work anymore rendering their printer useless, doesn’t help. You generally only do that once
– Thorbjørn Ravn Andersen
Jan 24 at 13:46
@ThorbjørnRavnAndersen: I have an ALPS printer that could print gold and silver metalic "inks" [actually, dry stuff on a ribbon]. Doesn't seem to be able to do that on anything since Win98, alas, and I haven't seen any printer since that could do that either.
– supercat
Jan 29 at 16:42
@supercat So you run Win98 in a virtual machine to use your printer?
– Thorbjørn Ravn Andersen
Jan 30 at 14:42
@ThorbjørnRavnAndersen: It's been in a box for a long time, but if I find the driver disks I've been thinking it might be interesting to take to something like a Vintage Computer Fair.
– supercat
Jan 30 at 15:52
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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).
add a comment |
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).
add a comment |
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).
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).
answered Jan 21 at 13:34
nekomaticnekomatic
1314
1314
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 21 at 21:09
supercatsupercat
7,362740
7,362740
add a comment |
add a comment |
I think the most basic answer to your question is that PS did not describe an interface, only the document.
So at a minimum you needed to implement some sort of physical interface on the printer, say Ethernet or Centronics, and then write a driver for the computer. For much of the history since then, this basic pattern has not changed.
It's worth pointing out that the original rendering engine from Adobe did include the interface and was licensed to various vendors. Apple licensed it and replaced their code with an AppleTalk interface. You still needed the driver to talk to the printer's job control system though.
But things are changing. Now there is a single universal physical interface one can use for this sort of thing, it's the internet. Printers also have lots of leftover power and memory too. So you can short circuit much of the remaining gap by assigning the printer a local-only DNS (like Bonjour) and sending it PDFs. All that remains is the protocol to "send", which IIRC, HP uses SMTP to complete. This reduces the driver to something that creates a PDF and mails it to a known 'net node.
Isn't that more of just pushing the driver onto a remote machine? The 'node' as you call it still needs to now how to interface the printer - depending on interface and printer. Isn't it?
– Raffzahn
Jan 21 at 21:53
Yup. But it's inside the printer, so I don't think there's any practical difference.
– Maury Markowitz
Jan 21 at 22:05
Just because server and printer are in the same housing (or better the server nowadays so small that it fits inside the printer) doesn't make it any difference. But I agree, from a user perspective it may as well be. Oh, and as usual, it creates loads of new classes of 'interface' errors - eventually calling for (application/computer side) drivers again :))
– Raffzahn
Jan 21 at 22:09
add a comment |
I think the most basic answer to your question is that PS did not describe an interface, only the document.
So at a minimum you needed to implement some sort of physical interface on the printer, say Ethernet or Centronics, and then write a driver for the computer. For much of the history since then, this basic pattern has not changed.
It's worth pointing out that the original rendering engine from Adobe did include the interface and was licensed to various vendors. Apple licensed it and replaced their code with an AppleTalk interface. You still needed the driver to talk to the printer's job control system though.
But things are changing. Now there is a single universal physical interface one can use for this sort of thing, it's the internet. Printers also have lots of leftover power and memory too. So you can short circuit much of the remaining gap by assigning the printer a local-only DNS (like Bonjour) and sending it PDFs. All that remains is the protocol to "send", which IIRC, HP uses SMTP to complete. This reduces the driver to something that creates a PDF and mails it to a known 'net node.
Isn't that more of just pushing the driver onto a remote machine? The 'node' as you call it still needs to now how to interface the printer - depending on interface and printer. Isn't it?
– Raffzahn
Jan 21 at 21:53
Yup. But it's inside the printer, so I don't think there's any practical difference.
– Maury Markowitz
Jan 21 at 22:05
Just because server and printer are in the same housing (or better the server nowadays so small that it fits inside the printer) doesn't make it any difference. But I agree, from a user perspective it may as well be. Oh, and as usual, it creates loads of new classes of 'interface' errors - eventually calling for (application/computer side) drivers again :))
– Raffzahn
Jan 21 at 22:09
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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