Slashdot Mirror
A PostScript-like API for the X Render Extension
Pivot writes: "Carl Worth and Keith Packard have started building a PostScript-like API for drawing using the X Render extension. There are two modules, called 'Xr' (the "rendering part") and 'Xc' (the "compositing part", which is a layer on top of Render which will eventually grow to a client-side Render emulator). The API supports only cubic Bezier splines, leaving other splines out of the library, similar to PostScript.
Check out the initial announcement on the Render mailing list, and some example shots. Shurely this will remind some of NeWS, cowritten by another well known character."
Carl Worth and I have started building a postscript-like API for drawing
e code for this is in the 'spline' CVS module at keithp.com and is
using the Render extension (or a client-side Render emulator). Interested
parties are welcome to take a look at the current state of the API
in CVS at keithp.com (http://keithp.com has a pointer), the two modules
are called 'Xr' (the "rendering part") and 'Xc' (the "compositing part",
which is a layer on top of Render which will eventually grow a client-side
Render emulator).
We chatted with Lyle Ramshaw a couple of weeks ago and he suggested that we
implement only cubic Bezier splines and leave other kinds of splines out of
this library. Certainly that matches what Postscript does, and cubic
Bezier's have the nice property of being trivial to decompose into line
segments.
Filling figures bounded by a Bezier is quite easy; split the curve into
line segments and fill the resulting polygon.
Stroking these curves is somewhat more difficult. We knew that circular
pens were a bad idea; in Sharp mode, they generate lumpy lines while even
in AA mode they're computationally intractable to compute precisely.
For Sharp mode, the fix for the lumps is pretty easy -- use one of John
Hobby's pen polygons and you get a nice even stroke width along the spline.
What I hadn't realized before now is that polygonal pens solve the
computational problem as well -- instead of generating a new n-th order
polynomial describing the track of the edge of the figure, a polygonal pen
stitches translated pieces of the original path together to form the
boundary.
We know how to compute points along the spline, and certainly translating
them is easy enough, the only hard part is selecting which pieces of the
spline are glued together to form the final edges.
That part turned out to be confusing, but actually quite simple -- you move
counter-clockwise along the polygon when the counter-clockwise polygon edge
is clockwise from the spline and clockwise along the polygon when the
clockwise polygon edge is clockwise from the spline.
Another realization is that Hobby's pen polygons aren't interesting in the
anti-aliased case -- pen polygons are designed to generate the same number
of lit pixels on each scanline (and column) so that non-AA lines don't
appear lumpy, but in the AA case, we don't want to round the widths to the
nearest whole pixel like that. So, for AA splines, we just use a
symmetrical polygon with enough points to keep things looking smooth.
The final trick was to add the four points forming the start and end of
each edge of the stroke to the polygon. This preserves the precise width
of the face so that a cap or join can be applied smoothly.
Carl wrote a prototype of this algorithm, a sample of it's output
can be seen at http://keithp.com/~keithp/download/spline.png
Th
written in nickle with a C helper to do the actual drawing with Xr.
The sample uses colors to show the transition from one polygon vertex to
the next; there are 20 vertices forming a regular polygon along with the
four additional vertices from the spline ends. The colors of the polygon
progress counter clockwise through black, red, green, blue, yellow, cyan,
magenta and gray, as seen in the little sample polygon drawn at the start
of the spline.
So what is this for? Would this be used to implement a Display Postscript widget or be used directly by drawing programs or something? What's the point?
Why is there still no alpha channeling? What about genie effect?
how much money would it take to get this code written?
If you use Linux, please help development of Autopac
Theres no easy way to use Xrender so no ones using it.
Why dont you ask keith packard because I dont know, but I hope they get alpha channel working soon
If you use Linux, please help development of Autopac
It will be very interesting to see how the rendering and composting compares to Apple's Quartz in OS X. Quartz brought a lot of nice effects to OS X, but slowed down the responsiveness of the GUI, especially on older hardware. At the time there was no way of using GPU's to directly accelerate a Postscript-based engine. Quartz Extreme has partially got around this by sending parts of the process through OpenGL.
So how will this implementation get around the limitations of hardware acceleration and even in an 'unaccelerated' form how will it perform? Definitely one to watch methinks.
1. X is bloated and should be replaced with something new and spiffy.
2. Why can't I have transparent windows with the background updated in real time? Lazy X developers.
3. Speaking of X, KDE is better than Gnome.
4. Speaking of KDE, Gnome is better.
5. I can't compile X.
There. Can we talk about new stuff this time?
Can you hear me, Major Tom? I'm not the man they think I am at home...
I hope the developers keith and the other guy respond to your post.
How exactly WILL it compare to Apples Quartz? Because thats all that really matters here. Will it compete with OSX or not?
The hardware limitation isnt a big deal, first of all OpenGL will work just fine, second why the hell would they go through all this work if its just a software hack? IF we want a software hack we can just use enlightenment which does alot of software effects or we can use KDE and use the little transparency hack effect.
If you use Linux, please help development of Autopac
If they are thinking of taking this someplace serious, it could be interesting. People probably remember that OS X uses PDF to display items, and its inspiration (NeXTSTEP) used Postscript. This gives resolution-independent display, and highly accurate WYSIWYG possibilities (since you render to the printer just like you render to the screen).
GNUStep is a clone of NeXTSTEP, and uses some sort of similar rendering. I'm not clear on their status -- for a long time they were waiting for a Display Ghostscript (DGS) extension, so they could copy NeXTSTEP faithfully. Proprietary Postscript extensions for X have been around for a long time. Ultimately, it seemed like someone didn't want to wait around, and wrote a straight Xlib backend for GNUStep, with none of the vector-graphics properties. I think that backend has stuck, since it works, and DGS isn't the primary platform at this point. But I'm not sure.
This could be an alternative to DGS, or something to build ontop of, or maybe it's just people fooling around with another alternative that wouldn't be useful. Obviously, fonts and anti-aliasing and all that jazz is really essential for a complete rendering platform -- just doing splines is a long ways from that.
(If you can't get to gnustep.org, try gnustep.net -- it's good stuff, even if development has been slow over the years. Too bad FSF/GNU didn't back GNUStep instead of creating GNOME -- I don't know what was up with that)
There is actually a great reason why X isn't dead. Extensions are that reason. The entire X rendering model was designed with no intention of surviving any more than five years, the original creators figured that by then, people would have subplanted their rendering model with a completely different one. This is a great plan, and allows for unlimited flexibilty later on, unfortunately, their original design worked well enough that noone has really bothered to change it. It has aged quite well, but needs to be replaced with a new rendering engine in order to even catch up with what is going on in the Apple world. I personally would like a complete widget set on the server side, programmers, being lazy, would use the built in widgets, and all of the sudden X would have widgets that all looked and felt the same.
Mind you, I'm a pretty big fan of OS X, but that windowmanager in there is an abomination against mankind. With no virtual desktop support (except for third party kludges), windows constantly pile up, and digging through them is a pain. Hiding the icons for minimize, maximize and close until you mouse over the title bar is also something that Apple heavily recommends against in their style guide. The cheezy effects in OS X are nice for the first week, and afterwards, you just get sick of them, fortunatly you can turn most of them off.
The thing I hate most about Quartz (even more than it's bloat) is the widgets. I don't want semi-transparent, gigantic pulsating buttons to work with, I want simple, flat and slightly tinted buttons, like Java has, give me that, and I'll be an even more happy OS X user (oh, and speed Macromedia Flash up to a reasonable speed, Apple's are supposed to be good at graphics, remember?).
This is neither.
Display Postscript is an X extension that allows a application to run postscript code which can be displayed on the screen. Expose redraw event are generated normally in X pixel coordinates while the Postscript drawing happens in device independant points per inch.
As far as I can understand (Correct me if i'm wrong) NeXT took this a step further by having the postscript graphics commands rendered by a RISC processor on the graphics board.
It looks that Xfree team is slowly extending their way out of the dead end that is the X graphics model but these problems have already been fixed by adobe display postscript on propriety unices. A technology that is as dead as a door nail according to adobe. Does anyone out there actually know of a Unix app that uses display postscript?
The free unices still don't have an equivenlant of windows GDI. which offers colour calibration, hardware acceleration of graphics primitives and most importantly a consistent way of accessing fonts that is identical when outputing to the screen or the printer (I can't find raph's weblog comment on that point on advogato.org).
Attempts have been made create a display ghostscript that is compatible with display postscript but it has stalled for a number of reasons.
IMHO the issue of display APIs for BSD/Linux is the most pressing for efficient app development.
I won't even mention the whole X versus NeWS debate. As always the inferior one won.
excuse my spelling.
Does this (and display postscript in the X server) present a security risk? As I understand it, X under Linux runs SUID, enabling stuff like DRI to access the hardware directly. Would it be possible for someone to write malicious code that ran in this environment as root?
Sun did something similar in the Network Extendable Windowing System (NeWS). This was in the days of the OSF. The OSF decided that X and Motif were the way to go and left Sun out on a limb with what, IMHO, was a better system.
it's amazing that a mathemetician (two actually, decasteljau and bezier) came up with bezier curves to assist designing automobiles. their power is so incredible, like in this instance, they are still very common today.
a nd_surfaces.html
e /software.html#BEZIER
the decasteljau algorithm for determining what points on a bezier curve are is quite simple. the bezier curve takes four input XY pairs (p0,1,2,and 3), which is why they're called cubic beziers, as opposed to the similar three pointed quadratic spline (like the directional arrows on some atlases). anyways, getting back to the algorithm:
;check distance between p0 and p3
;if distance>threshold, print values
;Compute p01. (p0+p1)/2
;Compute p12. (p1+p2)/2
;Compute p23. (p2+p3/2)
;Compute P012 (p01+p12)/2
;Compute P123 (p12+p23)/2
;Compute P0123. (P012+P123)/2
;call DeCasteljau (p0,p01,p012,p0123)
;call DeCasteljau (p0123,p123,p23,p3)
--
so basically, one generates two pairs (left and right) of points, and a recursive call is made with each.
.
the implications of such a simple yet elegant system in 3d beziers is amazing. this site has many resources : http://www.daimi.au.dk/~mbl/cgcourse/wiki/curves_
you may also want to check out
http://www-unix.oit.umass.edu/~verts/softwar
"bezeier madness", a beautiful bezier design program that 0wns windows paint.
http://siokaos.org/
I know that at least part of the design goal of GhostScript was to be a basis for replacing NeWS or Display PostScript, though people settled on X instead. Why reinvent the wheel now though? If you want a PostScript-like X extension, why not use GhostScript?
It seemed to me that NeWS was a good design--it added the obvious stuff to PostScript to use in a window system. It didn't take off because its implentation stunk and it wasn't free. But using Potsscript as the format seemed just fine. Any prob?
could someone in a clear and simple say how does this make the life of the developers easier? Why was is this done? I quess there was something that was previously harder to do?
Horrible trolling attempt (one of the worst I've seen), but I'll bite..
Yeah, cause they must have reverse engineered the whole PostScript spec.. it's not open or anything.. really...
Jeez, give me a break- they aren't going to get in any more trouble than someone would for implementing HTTP and HTML parsing in a product. Adobe WANTS people to use PostScript. Hence the whole open spec thing.
slashdot!=valid HTML
From what I understand, what would have to be ported would largely be the Gdk and Qt libraries. Once these were ported, the majority of the desktop environments' jobs would be finished.
"I may not have morals, but I have standards."
There have been several attempts based on GhostScript to produce a real postscript API for X11.
That's good, as far as I'm concerned. The raw XRender interface is a bit primitive. Having a C-based API with PostScript-like drawing primitives will be really neat. That will make it much easier to get Macintosh-like screen-graphics without the mess and overhead associated with Display Postscript or Display PDF.
I could say the same thing about MacOS (X), Windows, Linux, BSD ;)
NeXTStep was a seriously spiffy and technically advanced OS that never really made it, but that spiffiness appeals to geeks. I admire NeXTStep, but I understand that a certain Steve Jobs killed it off (MacOS X is based on it though, let's see if Mr. Jobs kills that one as well).
But porting APIs to *nix won't really make it into NeXTStep...
I used to have a ton of virtual desktops when I used Linux. I was wondering how I could ever live without them! I am now mainly using XP (and NT. 2k before that) and I find the taskbar and alt-tab to be just as easy to use and just as fast and virtual desktops. I have developed some kind of system where I remember what stuff I just used (alt-tab) and then I go to the taskbar for the stuff that I still have running but haven't used for a while.
This is not "USE XP!", I am quite sure you can get it to work like this in KDE for example. I am just saying give MacOS X own system a chance for a while and stop thinking in terms of virtual desktops, you might end up liking it (or end up switching OS).
The biggest reason I used virtual desktops was the 10+ xterms I had to have up all the time. I obviously don't have many xterms in Windows. Does you guys who use MacOS X use a lot of terminals? I'm just curious about how much of the BSD part of MacOS X is used by people.
Yeah, it kicks ass.
What does it bring to the table over C
It's OO.
or C++
It doesn't make your brain melt. And it takes an hour to learn. And it's *real* OO. With messaging (in addition to methods, which are different) and dynamic typing and binding which really opens up wide possibilities for heavy runtime action. And no multiple inheritance. Instead, you get protocols and categories. It's kind of like Java in many ways, except that it isn't dog-slow (the runtimes have become pretty optimized over the years and there's none of that byte-code crap). Oh, and the other reason it's so fun is because of the damn fine OPENSTEP API (A.K.A. Rhapsody and Cocoa).
Using Objective C and OPENSTEP is like having sex--it's just that pleasurable to work with.
Because it's a lot more than how it looks. There's an excellent API as well. Oh, and nice software development tools too.
I've been developing in ObjC for nearly 6 years now. The biggest advantages of ObjC is it's simplicity, and that fact that it is really dynamic.
Some of the features that I like:
Categories: This allows you to add a method to a pre-existing class without having to have source to it. For instance, if you think the NSString class should have a urlEncodedString method, just add it. Now all NSStrings will respond to this method!
PoseAs: Even cooler. This allows a subclass to actually "pose as" it's parent. Normally a dangerous technique if you aren't careful, but it's an excellent way of tracing object interactions go or fixing library bugs.
However, I still think that the coolest part (inherited from Smalltalk) is the dynamic dispatch architecture. For instance, you can implement a method named 'forwardInvocation:' That way, if any unknown message gets sent to your instance, it will first get sent to the forwardInvocation: method allowing you a 2nd chance at processing it. This is cool because you can redirect the invocation to another object and become a transparent proxy. This makes distributed object systems EXTREMELY easy to work with.
Great! now that I've got enough hardware to run postscript in real time, maybe its time to do this. Anyone else remember how slow a sparc station 1 was doing postscript? At least you had thouse cool round buttons. Too bad postscript has a real problem doing the shaded bar things that seem to be everywhere now.
XRender is usually enabled by default in recent builds of a XFree86 (4.2.x would be a good place to start). You can tell relatively easily if you have XRender and anti-aliased fonts by doing something like:
... I believe some patches/hacks were out there, but officially, you'll need GTK2 to get AA fonts. Qt does support AA fonts via the XRender extension - if you have that xterm thing working alright, you should be able to load the KDE control panel and in the Fonts section turn on AA to get AA fonts in all Qt/KDE apps.
... this used to be pretty difficult (a few months ago), but a lot has progressed on this front. I'd recommend some Google searches and some searches in bugzilla.mozilla.org for AA fonts. KeithP helped a whole lot in getting Moz going with AA fonts using Xrender/Xft - I believe this is what he's referring to when he stated previously that he got sidetracked for a year doing client-side font things, amongst other things, too, I'm sure.
$ xterm -fa Courier -fs 14
This should launch xterm with AA fonts (Courier at size 14). If your xterm doesn't understand the switches, then your version of XFree86 isn't recent enough.
GTK 1.2 doesn't support AA fonts, far as I know
The information on these things is out there if you search the mailing lists. By now, someone may even have put together a simple Howto.
Btw - it is possible to get AA fonts in Moz as well
Cheers.
For those looking for Virtual Desktops in OS X, look no further than Space.app, a GPL'd application that provides multiple desktops (configurable) and hotkeys to switch between 'em (also configurable). The concept of a "sticky" space is also supported.
As for easing the clutter on the desktop, if virtual desktops alone don't do it for you, check out Windowshade X - this brings back the functionality of being able to double-click on the title bar of a window and collapse the window to just the title bar, as in OS 9 (and most Linux WMs).
If you don't like the dock, get rid of it! As for the widgets, you'll be happy to know that the various buttons in OS X have been on Weight Watchers during Jaguar's development .. check out any of the screen caps at Think Secret to see the new buttons before Aug. 24th - while they aren't quite like the Java buttons, they are quite a bit slimmer and make the interface look quite a bit less like candy and more like a professional workstation.
Cheers!
Unfortunately, when I tried Space.app, it wasn't good enough to be useful. For some reason (limitations of the OSX windowing model perhaps?) it allocates windows by application; i.e., all of an application's windows go in the same workspace. Given that on OSX, only one instance of any application is running at any time, this means, for example, that all your Terminal windows must be on the same desktop. This is not good enough.
Actually, there is a fundamental difference between NeWS and what is being done in Render (and Carl and Keith's latest work).
t al ks/gettys_html/img0.htm
NeWS implemented postscript in a display server; Render is only implementing the imaging primitives in the X server (in this case, AA, alphablended trapezoids), leaving anything like Postscript (or pick your favorite other graphics library) to be implemented as a client side library.
If you think Postscript is a good extension language (which NeWS was based on), you need your head examined. And machines of that era could not rely solely on a Postscript imaging model (insufficient display bandwidth available for imaging applications). What is feasible today on 1000 mip machines for applications is quite different than the 1 mip machines of that era.
Now if you want an extension language in the X server, try something like Java: note that James Gosling saw the errors of his ways with that language.... It would make infinitely more sense than NeWS ever did.
And yes, lots of time was lost: the UNIX vendors fought with each other for years rather than helping X move on. See my Usenix invited talk.
http://www.usenix.org/events/usenix2000/invited
If you want to have something "better", either help the current efforts, or go write your own window system. Grousing about the current state of things when you aren't doing either isn't acceptable. Note that we have been learning from much research in the intervening time: Plan 9's window system is the basis for the render work; it has blazed the way for a much better imaging model with great simplicity and power.
But I never believed NeWS was the answer (then again, I'm biased).
In my opinion Display Postscript is seriously flawed by an absurdly difficult interface for drawing the postscript. It is designed ONLY to "preview" a document and nobody ever writes a program that uses it to draw the interactive display. NeXT was better in that, although it used the DPS interface, it used ONLY that interface, you used PostScript to create and manipulate windows and thus you did not have to learn how to interface both DPS and X (or whatever). NeXT then messed this up by insisting that people use NeXTStep, but that is another story. NeWS shows how it should be done: the interface was an absurdly simple stream interface, with simple token substitution so that common PostScript commands could be 1 byte and numbers could be sent as raw data. A NeWS program was the only one that could dump it's entire user interface to the server with a simple block copy.
I have no idea why you are saying GDI32 is good, unless you are trying to troll here. It is exactly like X interface, in fact many parts of it are copied (there is no other explanation for the exact correspondence of the dashed line interface or the inane use of "points" to measure fonts when everything else is measured in pixels, these things were copied from X). Fonts are enormously better on GDI32 as you say. But unless you are living under a rock you would know that X uses hardware acceleration as well. And neither system does anything about color management, and neither of them should, this requires too detailed knowledge of the data being presented and is best left to the application. In fact X has a (fortunately abandoned) mess of CMS calls and I thought the LACK of these is one of GDI32's advantages, because you can assumme they do nothing.
Because of the horrid DPS interface I don't think there is any interest in emulating it. I would like to see a stateful interface like NeWS where there is no "context" argument to the calls (you can use the same tricks as OpenGL so multithreading is supported). I have not looked at what they are considering yet so I can't comment on it, but some of the XRender extension is pretty good, though I don't like the enforced creation of per-window objects.
However I have had no luck using it to draw anything other than fonts. It is supposed to draw antialiased filled trapazoids (which can then be used to draw any shape antialiased) but I have had no luck in getting them to work. I suspect there are a lot of bugs in the current implementations. This unfortunately means nobody uses them and thus nobody fixes the bugs...
Um, you are aware, of course, that Steve Jobs, as the founder and CEO of NeXT, is responsible for NeXTStep existing in the first place?
-- Alastair
I hate Bezier splines with a passion because they do not make intuitive sense. It makes more sense to use Catmull-Rom Splines where the control points fall on the line. It uses a simple parametric polynomial just like the Bezier, but unfortunately it lacks the subdivided-ness.
Look into it.
-- Making computers see, hear, and think... http://www.componica.com/
Technically, a big problem with PostScript is that documents are programs. This means you can run them, but doing anything else (text extraction, editing) is tough. Even a PostScript viewer is tough; look at the GhostScript mess. Plus there's a security issue. Compare HTML, which can be usefully postprocessed in many ways.
Because PostScript was flawed as a way to do anything other than print, Adobe came out with Acrobat as a way to ship documents around. Acrobat should have been unnecessary. And then there was the eBook format.
It's annoying that we don't have a good open format for documents. This helps give Microsoft Word its dominance. Word is the cornerstone of the Microsoft monopoly. (A few days ago, someone pointed out that Word Perfect format is now open, but that happened a decade or so too late.) By now, we should understand the problem well enough that we should have a single format, or at least related formats, which are displayable, editable, and printable.
which means in its current state it sucks.
If you use Linux, please help development of Autopac
The PDF format is essentially PostScript with the ability to execute code removed, and a declarative syntax in its place (see http://www.rlg.org/preserv/diginews/diginews5-1.ht ml#feature2
for details).
The PDF file format is open, and many tools have been written to use it without involving Adobe.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
C++ sucks, I'll never like it as a language even if its powerful.
If you use Linux, please help development of Autopac
As far as I know neither the way NeWS or the way X was distributed would be considered truly free by the FSF.
I think getting access to NeWS required a very large amount of money and a NDA-style contract so I don't think anybody would consider this free.
My understanding of X is that you were not allowed to do anything unless you paid the $100. I think this violates the rules of the FSF for a true Free software (because it limits the ability to redistribute the source code) but for a lot of people this would be considered reasonably free.
There's distribution-level issues (filesystem layout and so on), but you can fake that if you need to.
no i think ill go down on jobs one more time for the hell of it
YUM!
Billy you are next!
If you use Linux, please help development of Autopac
A vector graphics display API sure, but why postscript? Why not an open standard, like SVG?
OK, so you can dump your screen to your (postscript) printer. Would there be problems accurately converting SVG to postscript?
Why should the printer drive the display anyway - isn't the tail wagging the dog? Is the argument that technology should adapt to the device capable of producing the highest fidelity output?
Maybe it's also time for printers to start speaking SVG.
--Lawrence Lessig for Congress!
if there's such a nice API and software development tools, why was nothing ever developed with it.
Because plenty of stuff *has* been developed with it. You're just ignorant of them. For example, it has been heavily used in the intelligence industry and on Wall Street. And I'm sure you've probably heard of Mac OS X, right? Guess what the primary development platform is. You should check out Softrak and the peanuts FTP archive some time too. And maybe the OMNI Group and some others. Is there as much software as there is for Windows? No. Is that because MFC is a superior development platform? Pffffft. It's because Microsoft has the marketing muscle and lock-in advantage (and an awful lot of luck thrown in for good measure).
And why is every application that was developed as part of it so primitive and un-user friendly.
You've never used any of this stuff, have you? There are some quite attractive and usable applications out there. GNUmail is very nice, for instance, and was developed primarily by one author in a very short period of time. Are there poorly designed UIs as well? Of course. But that's the fault of those who design. And that happens everywhere--UNIX, Windows, Mac OS, BeOS, etc.
Is it just a coincidence that it was a brilliant platformed developed by people with no design sense.
I find it to be quite elegant looking. But at any rate, I was talking about the API. Y'know, stuff like Array and String classes and responder chains. Stuff you don't actually "see". How it actually looks is not set in stone. That's why Mac OS X looks completely different but is built on the same basic classes as OPENSTEP or GNUstep.
Yes, it is interesting to note James Gosling's software history. I was a HUGE fan of NeWS at the time. (That has been one of the three elegant things in computers I ever loved passionately, others being Modula-2 and Plan 9 /Inferno.
First he and others at Sun thought PostScript is an elegant interpretable general purpose language, why not send that to GUI clients to offload arbitrary GUI widgets -- or any code -- from servers? Just add input handling and host communication to PS. You also get better vector/pixel/font/colour model than the hackish X. Vector graphics NeWS windows and fonts could be arbitrarily scaled and still use all resolution you have, i.e. on printers.
They even built a nice event model as PS widget libraries, where stacked dictionaries were an elegant inheritance mechanism.
When NeWS failed as a distributed window system (I think because Adobe destroyed that clone of PS with anti-Sun politics and their own inferior and competing DisplayPS), Gosling became soft for complaints about non-conventionality of PS stack syntax. He threw away the PS syntax and ran away from the GUI wars dropping the graphics part, but kept the idea of distributing interpretable system modules as NeWS intermediate code. NeWS did PS -> pseudocode, now his new language, first called Oak and then Java, compiled to a similar pseudocode.
So sad. NeWS lost so much possibilities and elegance when it became Java, and gained nothing excpet a new language syntax (that I hate, like I hate C++).
Note that NeWS server application were language neutral so that no matter what language you wanted to use on the server, you just wrote your widgets as PS text (or precompiled pseudocode) to the clients at initialization and later on demand by the client when first needed.
Anssi Porttikivi / app@iki.fi
would these be the same beziers that the Win32 GDI has supported since NT3.1 shipped in 1993?
I am not sure of the actual requirements of X, that is just what I seem to remember.