> 2 3 add ==
5
> (hello world) (putting stuff on stack) stack
hello world,putting stuff on stack
> exch stack
putting stuff on stack,hello world
/cv framebuffer newcanvas def
framebuffer setcanvas
130 130 translate
0 0 100 0 360 arc
cv reshapecanvas
cv /Mapped true put
cv setcanvas
erasepage
{
createevent dup begin
/Canvas cv def
/Name /LeftMouseButton def
/Action /UpTransition def
end expressinterest
{
awaitevent begin
0 0 moveto
XLocation YLocation lineto stroke
end
} loop
} fork
See basic tests (especially the Densmore OOP test), and examples. Check out the live test page.
PostScript is the future of words on paper.
Dewdrop is a work-in-progress reimplementation of Sun's NeWS (Network/extensible Window System) version 1.1, by Omar Rizwan. Its PostScript interpreter and standard library are based on Tom Hlavaty's WPS. It's licensed under the GPLv3. Source is on GitHub.
NeWS is a window system and UI/graphics API based on a superset of Adobe's PostScript (a stack-based programming language made for printable graphics). NeWS adds interaction support, a UI toolkit, cooperative multitasking, and OOP on top of Adobe PostScript and its graphics model.
NeWS was developed in the 1980s at Sun Microsystems and originally named "SunDew." (Many of the people behind NeWS ended up building Java.) NeWS was ahead of its time – proponents argue it was technically superior to the MIT X Window System that outcompeted it – and its design actually resembles the modern Web. (will add more here...)
NeWS was architecturally similar to what is now called AJAX, except that NeWS:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML/CSS for rendering.
- used PostScript data instead of XML/JSON for data representation.
Curiously, NeWS got to the same place as the modern Web, but took a very different path, decades earlier. The argument the NeWS Book makes for the NeWS architecture is basically a *compression* argument.
Suppose we have two computers: one is a 'server', where logic runs, and one is a 'client' which sits on our desk. How can we build a window system where a graphical app runs remotely on the server, but we interact with it from our desk?
One approach would be to stream full video of the screen from the server to our desk. Steam can do this. But that's bandwidth-intensive and hard to pull off if you're back in the 1980s.
Another approach, which is taken (in theory) by the X Window System when you do `ssh -X`, is to come up with a basic set of objects, like buttons and text boxes, and have the server stream a display list of all the objects to the client. If you do this, however, then your objects are frozen in stone and might not be what applications want to use -- what if they want to have a custom UI, or what if your system button style just looks ugly? -- and if an application draws its own stuff, you end up streaming that custom stuff pixel by pixel anyway.
NeWS asks: why do we need to send flat lists at all, whether of pixels or of higher-level display objects? Our client is a full-fledged computer. Why not send a small *program* from the server to the client, and let that program draw whatever it wants on the client?
In fact, Adobe built PostScript to solve a very similar problem: your Mac could send your LaserWriter printer a compact PostScript program describing the pages to print, and the LaserWriter would interpret the program on its own CPU. (A faster CPU than the original Mac's CPU, by the way.)