nobody@mimsy.UUCP (Nobody) (12/19/88)
--text follows this line--
Glenn,
From: don@brillig.umd.edu (Don Hopkins)
Path: brillig.umd.edu!don
Is there any effort at Adobe to make your extension to Red Book
PostScript compatible with the NeWS extension? Display PostScript and
NeWS each have a different set of extensions to Red Book PostScript,
but where they overlap, are the names the same? And in those cases,
are the arguments the same?
Some examples of the types of NeWS extension I mean:
currentpath % - => path
setpath % path => -
currentstate % - => graphics_state
setstate % graphics_state => -
copyarea % dx dy => -
undef % dict key => -
dictbegin % - => - (new dict pushed on dict stack)
dictend % - => dict (popped from dict stack)
case % value {key {proc} key key {proc} ... /Default {proc}} => -
append % obj1 obj2 => obj3
printf % formatstring arrayarg => -
sprintf % formatstring arrayarg => sting
stringbbox % string => x y w h
I don't have the Display PostScript documentation yet, but I'm
ordering it soon. I'm looking forward to reading about it, and even
further forward to using it!
I think it would be a great idea to make NeWS and Display PostScript
compatible. What do you people at Adobe think of Display PostScript
"clones"? I hope you don't find the inevitable alarming. I certianly
think people would be encouraged to write Display PostScript
applications, if they knew they would run on top of X11/NeWS as well.
Is there any reason that NeWS couldn't be programmed to emulate
Display PostScript? Is there anything about Display PostScript's
model of processes, drawing surfaces, interprocess and network
communication, that couldn't be simulated in NeWS by a simple
compatibility package, and maybe a few gratuitious server extensions?
NeWS could easily be taught to understand the pswrap byte encoding,
and communicate with Display PostScript clients. Adobe hasn't gone to
any effort to make Display PostScript incompatible with NeWS, have
they? (Like giving the function that closes a network connection the
two character name "^C". ;-)
Does Adobe have any plans about adopting a classing mechanism? Have
you considered Owen Densmore's public domain object oriented
PostScript programming package, class.ps? It's some really elegant
code, written in Red Book PostScript, and it's very well matched with
the PostScript language and imaging model. It makes PostScript into a
Smalltalk-like programming environment! Now there's a version
supporting multiple inheritance. I really enjoy programming in object
oriented PostScript, and I want to see the PostScript language evolve
to its full potential. Standard Common object oriented PostScript
would be a good thing!
-Doniau@ukc.ac.uk (I.A.Utting) (12/20/88)
In article <15066@mimsy.UUCP> don@brillig.umd.edu.UUCP (Don Hopkins) writes:
->Is there any effort at Adobe to make your extension to Red Book
->PostScript compatible with the NeWS extension? [ ... eg. ]
->currentpath % - => path
->setpath % path => -
->currentstate % - => graphics_state
->setstate % graphics_state => -
->copyarea % dx dy => -
->undef % dict key => -
->dictbegin % - => - (new dict pushed on dict stack)
->dictend % - => dict (popped from dict stack)
->case % value {key {proc} key key {proc} ... /Default {proc}} => -
->append % obj1 obj2 => obj3
->printf % formatstring arrayarg => -
->sprintf % formatstring arrayarg => sting
->stringbbox % string => x y w h
While agreeing entirely with your general point, at least the last 5 (7?) of
these are implementable directly in Red Book PostScript, although it would
be nice if they were "officially sanctioned" by Adobe.
->Does Adobe have any plans about adopting a classing mechanism? Have
->you considered Owen Densmore's public domain object oriented
->PostScript programming package, class.ps?
Is this generally available? How can I get hold of details, or even a copy?
Ian.