From: byer@adobe.com (Scott Byer)
Subject: Re: PostScript vs. X as a graphics protocol
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Date: Tue, 10 Nov 1992 17:47:43 GMT

Jonathan Monsarrat writes

> Well, pros and cons that I can think of.

> PostScript Con: the program passed in through the protocol
>                 could be a security problem.

Current DPS/X implementations have accounted for this; a PostScript
program can do nothing destructive to the user's files.

> PostScript Con: the program could be non-portable. When you port 
>                 X to a platform, it's done. With a PostScript protocol
>                 each protocol program needs porting.

Actually, this is the other way around.  Each X implementation
tends to have it's own problems (due to tweaking from the provider)
requiring their own work-arounds.  Every DPS/X implementation contains
the same interpreter.

And don't forget color.  X's lack of a reasonably device-independent
color model is horrifying to contemplate programming for.  With
Display PostScript, color is easy.  When NeXT introduced their
first color machine, for example, programs just ran on it - no
change.  You could even take a window and have it straddle two
screens - one grayscale, one color - with no changes to the
application.

> PostScript Con: Is PostScript fast enough?

Display PostScript is plenty fast.  Far faster than "conventional
wisdom" seems to think.  Take a look at some of the NeXT programs
that use Display PostScript heavily, such as PasteUp, for an example
of PostScript's ability to render quickly.

PostScript can be made to look slow easily enough, and there are
quite a few programs with an uncanny knack for doing so.  Programming
Display PostScript to go fast is not hard enough to justify these
programs' behavior, though.


You also missed:

PostScript Pro: Functionality.

Display PostScript can do things X can't even currently imagine
doing.  Such as typography, page layout, image placement, and
arbitrary manipulation of pages.  And Display PostScript does them
quickly.

The X protocol is fine for basing a window manager on - it satisfies
the simple requirements of a window manager quickly and effectively.
But any sophisticated graphics applications need far more than X
provides.


PostScript Pro: Printing model.

Somebody once remarked to me:  "Printing under X is like a black
hole".  I replied "But black holes exist".

> Any opinions on this choice and where/when one or the other is best?

> What systems use PostScript as a protocol? The NeXT does this, right?

My opinion is that the current split under DPS/X is quite effective.
Window managers that don't need fancy graphics capabilities are
done quite effectively using a limited, known protocol that they
can count on.

However, doing pieces of a toolkit using Display PostScript has
some distinct advantages.  Icons, for example.  If you had a button
widget that used the PostScript image command, you wouldn't need
an icon for each depth of screen.  Or, you could easily do
non-rectangular things quickly.  Or rotated text.  There aren't
many instances where you would want such functionality within a
window manager or toolkit, but enough instances that the lack of
ability to do such things is highly annoying.

--
Scott Byer                             NeXTMail: byer@mv.us.adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------