Skip to main content
Commonmark migration
Source Link

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.

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.

Correct capitalization of company/product name, minor grammatical cleanup
Source Link

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 considerableconsiderably 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 spendingproviding 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-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 NextNeXT.

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 considerable 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 spending the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-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 body
Source Link
user
  • 5.4k
  • 3
  • 27
  • 43

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 considerable 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 spending the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-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 relaidrelied 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 considerable 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 spending the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-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 relaid on just-in-time DMA transfer from the ST. Every kind of rendering was done by the GEM-VDI (Virtual Device Interface). Ofc, with 'just' 4 MiB maximum memory it did create problems with very detailed documents.

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

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 considerable 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 spending the device a lot of memory. It's a universal constant: Like computers, printers always need more memory than available. This increases the price - not good in a price sensitive market like the PC-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.

Source Link
Raffzahn
  • 236.1k
  • 23
  • 682
  • 976
Loading