PostScript vs. X as a graphics protocol

Thread View: comp.lang.postscript

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Jonathan Monsarrat Mon, 09 Nov 1992 23:39

#4019

Author: Jonathan Monsarrat
Date: Mon, 09 Nov 1992 23:39

79 lines
3264 bytes

Newsgroups: comp.lang.postscript,
Subject: PostScript vs. X as a graphics protocol
Summary: 
Expires: 
Sender: 
Followup-To: 
Distribution: world
Organization: Brown University Department of Computer Science
Keywords: 

*******PROBLEM:

I've heard that some people prefer PostScript as a graphics protcol
over some other protocols like the X protocol for the following
reason:

1. PostScript is a program, which means that you can pack the data in 
   the best way possible, and include a tiny program to interpret it.

2. The X protocol is defined and static, so you can only do the things
   that the X protocol allows. Your data must be in one of the
   predefined forms.

*******EXAMPLE:

If I wanted to generate a picture made up of filled regions,
I could use the X protocol like this:

    line line line line fill line line line line fill line line line fill
    etc. etc.

Where the lines and fills belong to some predefined format. In
PostScript I can prepend a special program to let me do the lines and
filling more compactly, like this:

/p 4/f{{}forall moveto gsave{dup 32 mod dup 15 mul rotate sub p div 0 rlineto}
forall fill grestore}def 4 scale 1 def(``f`f`f)dup(  )f( i).3 setgray f/p 8 def
1 setgray/h(F!6! 2477!W)def h("4)h(,C)h(6O)h(LT)h(^O)h(tC)h(~6)(7!6!"7#$&6!7 #)
(9~)(""""""""""")(}~)(fTV``Vt)(9!)(e!FR"n&44ED-w@-7&&b)(C2)11{f}repeat showpage

********THINK-UMS:

Well, pros and cons that I can think of.

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

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.

PostScript Pro: Takes less space than X.

X Pro: No need to interpret and compile incoming program. Large common
       stuff can be handled directly.

PostScript Con: Unless you combined a little of the "static programs"
                of the X method, you'd never be able to interpret data
                at all unless there were a program sent with it!

PostScript Con: Is PostScript fast enough?

********DISCUSSION?

Now, I come from MIT where a lot of X stuff happened, but I also
like PostScript a lot. So I am undecided.

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?

I'm not going to cross-post this to an X newsgroup because I'm just
kind of curious to hear some opinions. I'm not trying to start a
flame session between two newsgroups or anything!! :)

-Jon
%! Jon Monsarrat   jgm@cs.brown.edu   Brown University %! Obfuscated PostScript
0 0 moveto 15 setlinewidth(qlllll-??LHHL??llH?hH7t,7olCAHH@)1 setlinejoin{dup
10 mul rotate 80 lt{50 0 rlineto}{50 0 rmoveto}ifelse}forall stroke showpage

Re: PostScript vs. X as a graphics protocol

#4031

Author: Scott Byer
Date: Tue, 10 Nov 1992 17:47

84 lines
4115 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads