General musing on PS and Display PostScript

[onewing...@gmail.com]

Hello everyone,
I'm pretty new to PostScript, haven't even made my first program yet. Though I find many things about the language, and its applications, to be very intriguing as I've read 1/4 to 1/3 of the PLRM researching/developing a PS-interpreter (in Ada).

Display PostScript is a good example of why I find PS intriguing: it (and the PDF version Apple uses) makes much more sense than, say, HTML5/CSS — precisely because PS/PDF were designed for layout description rather than the HTML idea of "let the implementation decide layout" (which is the whole reason for CSS's existence) — for UI.

So, I guess the latent question in the back of my mind is: "Why did DPS vanish?" Is it because it was too far ahead of its time, like Acrobat was, or was it a poor execution of the basic idea? (I'd like to write an OS, sometime, and using PS/PDF for the UI/display-system would be great if if creates a system where everything visual is handled the in same common manner and there is no need for printer-drivers. [assuming a PS printer])

[KE]

DPS was killed by three things:

1. Its pricing structure. Adobe's big concern when they came out with
DPS was that it would kill their printer RIP business. After all, with
licensable DPS interpreter, any PS document could be rendered to an
image and sent to a non-PS printer; good-bye PS printer licenses (which
at the time was by far Adobe's biggest source of revenue).

So, Adobe's pricing for licensing DPS was based on the pricing for
their printer RIPs: a fairly big percentage of the retail price with a
quite large minimum quarterly royalty amount. Very expensive.

Add to this:

2. Work station wysiwyg was a problem already solved, sufficiently
well, anyway. If you were a graphics/text layout software company back
then, you had already written the code to make what was displayed on
your customers' Mac or Windows screens look close enough to what they
were going to get from the printer. And, of course, although PostScript
printer drivers are always a nuisance, they already existed when DPS
was released and so that was work already done.

3. End users didn't care (and still don't); DPS was always much more
attractive to engineers than to users. A graphic artist really has no
interest in how the graphics they see on the screen is produced. Even
saying that what they see on the screen is now produced using the same
code as will be sent to the printer means very little (nothing,
usually) to them; certainly they aren't willing to pay more for that
feature. Whether their screens are drawn with PostScript, QuickDraw, or
GDI, it's all the same to them.

DPS died because it was overpriced software that addressed a problem
already solved for which customers would not pay for.

Bummer.

In the end, the importance of DPS was that in creating that product,
Adobe did an awful lot of work that found its way into PostScript Level
2, such as automatic garbage collection.

P.S. I really enjoyed messing around with DPS back then. I looked into
using their CPSI interpreter to do screen preview software, but was
discouraged by the cost. I ended up using the Jaws RIP.

- John


========
John Deubert
Acumen Training
PostScript & PDF Engineering Classes & Consulting
www.acumentraining.com

Learn PostScript programming techniques
Read the free Acumen Journal
www.acumentraining.com/acumenjournal.html

[onewing...@gmail.com]

Thank you for the explanation/history of the demise of DPS.