It could have been JavaScript 10 years before we had JavaScript. It demanded more dedication to use.

Turns out round window with stroke path text alpha and reimplemented xeyes was not compelling.

People should have shown NeWS doing complex client side form field checks.

Sun also didn't go downmarket. Windows PCs happened with hummingbird xceed X not decent in Microsoft X

Every day that I program in JavaScript I wish we had Display Postscript or NeWS in the web browser. Imagine if browsers had evolved with Postscript instead of JavaScript.

It's not PostScript instead of JavaScript. It's PostScript instead of HTML, JavaScript and CSS. That's (IMHO) the more important point. One programming language to write and structure everything instead of a bastardized SGML plus a bastardized Java plus an ad-hoc config add-on.

I'd much rather have (a slightly saner) JS for everything than PostScript plus HTML plus CSS, if I would have to choose.

Netscape 4 actually had JavaScript-based stylesheets, before everyone settled on the CSS standard: https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

It may have been a mistake but it did add an important innovation: Postscript in the display system. This would be an innovation even now, having an interpreter for an embedded language right in the windowing system.

AFAICT Apple does something similar in Quartz…?

https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer)

NeWS (developed at Sun) and Display Postscript (developed at NeXT) were each adaptations of Postscript to the screen. Apple (after the NeXT takeover) developed Quartz to avoid paying licensing fees to Adobe for Display Postscript. So yes, Quartz does something similar to NeWS.

I believe X Windows owes much of its incredible longevity to the "provide mechanism not policy" mantra that its designers took very seriously.

Having the toolkit in the server would necessarily force it to define and enforce lots of policy. This increases complexity, increases dependency (coupling) on part of the clients, and after all that you still have the problem that policy simply doesn't age well.

It still boggles my mind a bit that a display stack designed in the 1980s has remained viable to this day. Sure, it's a patchwork, and it's finally being replaced, but it works.

The WinForms API also survives from the mid 80s, and is interestingly different. I believe the classic controls were originally drawn in the kernel?

You probably mean Win16/Win32, not WinForms. But it only survives in the sense that it’s still there, not in the sense that it’s still useful. How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

I think that you're in a bubble for that one. Many business domain-specific applications are still directly written against Win32 even today. UWP didn't manage to catch up for now either.

Electron usage is mostly only in startup-y apps and some IDEs.

No experience is universal, so I'm curious in what industry you encounter Win32. Or do you mean WinForms? I often work with industrial manufacturing companies in Europe, with a mindset about as far from that of Silicon Valley startups as you can imagine. You usually won't find Electron there. Many "legacy" projects are in WinForms. But for newer stuff, I see lots of WPF and Qt projects, both of which don't use native controls.

How many Windows applications have been created in the last five years at all?

Not much of a PC gamer, are you? :)

Sorry for the pedantry, but you're thinking of the Windows API, specifically the user interface bit (user32.dll as of Windows 95 and NT but it existed before) which is based on GDI which is hardware accelerated. It still exists but it rarely used for new applications today, but it was certainly in use for a very long time.

WinForms was briefly promoted as a successor, based on GDI+. It was quickly abandoned, as was GDI+ which never got hardware acceleration, in favour of WPF which is based on DirectX which is obviously hardware accelerated. But in that small time it caught on and continues to be used for new projects because it's a simpler programming model than WPF and it's not obvious in Visual Studio that it's been abandoned (it's not quite deprecated).

MS Windows is definitely a good counterpoint to this blog post. Whatever the kernel/userspace split (which has changed over time), the basic Windows model is that the logic & code of the windowing system is all in the 'server' (i.e. the OS libraries, sometimes including kernel-space code).

The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.

Actually the logic and windowing happens in each client in user space, which is why you can’t build alternative window managers, and Microsofts policy of compatibility ‘shims’ and hacks that allow chosen old software (and they choose a lot of software) to work on modern systems has nothing to do with it.

Have a quick search online, and you'll find plenty of alternative window managers for Windows. But it's besides the point, because both styles of graphical windowing systems can support alternative window managers.

its incredible longevity

I get your point, but see it completely differently as GUI programmer. X was steaming pile of s*t. Its "longlevity" was spend cleaning up the mess.

Designers had this stupid idea to do drawing over remote connection, and produced broken design around that. Direct memory access, DRI, OpenGL, screen buffers... Non of that was part of X, but is vitally necessary for GUI.

There is no compatibility in X server design. Good luck running remote X session today. Everyone uses VNC.

Apart from thin clients, X remote display has historically been used for combining applications from multiple systems on a single display. Those systems could be computers, lab hardware, or anything else.

Or the other way around: multiplexing one X11 application across multiple displays.

On the Usenix trade show floor one year, somebody made a horse racing client that opened connections on multiple X11 servers, and animated horses racing from screen to screen. Many different companies with X11 workstations or terminals were running it at the same time, and horses were running between different brands of computers on the trade show floor, which made a nice point! (About network race conditions ;) It was just black and white, and the graphics were dead simple, so it worked great on everybody's hardware.

Multi Player SimCityNet was implemented in TCL/Tk on X11, which supported opening multiple X11 servers at the same time, even with different kinds of displays, and using shared memory if running locally. Of course there was a limit to how many people could play at once, and it required a reasonably fast network, and every player had to grant full access to their server to the client. And anyone could type TCL expressions into the chat window and hit escape to execute them, so it probably wasn't very secure, and certainly was easy to cheat: "sim Funds 9999999<esc>"

https://www.youtube.com/watch?v=_fVl4dGwUrA

https://www.donhopkins.com/home/catalog/simcity/simcity-anno...

https://www.donhopkins.com/home/catalog/simcity/simcitynet.h...

SimCityNet: a Cooperative Multi User City Simulation

SimCityNet is an animated interactive system simulation game, providing a set of rules and tools for planning and building a complex dynamic simulated city. Several people on different workstations can participate in the same game, cooperating and coordinating their actions over the net. Working together, you can zone land use, hook up the power grid, build roads, bridges, parks and stadiums, raise taxes, and even summon disasters, causing the city to grow and thrive, or crumble and die. SimCityNet features multiple city views and maps with overlays, simultaneous editing and user interface interaction, "voting panels" for group decision making, and multimedia communication and annotation features ("bridges between players").

The multi user interface supports communication via three media in parallel: text, sound, and graphics. It includes a scrolling text log for telegram messages, a networked audio server for sound effects and voice intercom, and shared cursors and graphical overlays for pointing, gesturing, annotating and editing the map.

Although I admire and frequently agree with this blog, I think this article exhibits some common misconceptions about NeWS. NeWS had what amounted to uploadable toolkits, and therefore could and did have multiple toolkits. A client could decide how it wanted to separate processing between the client and server, which seems truly more flexible and allows for much more efficient communication. Also NeWS had threads which if done today would certainly use multiple processors. Clients could, but didn't have to, use a separate address space and language even. But the graphics API was so much better, it's ridiculous, and is basically the same as now in SVG, html canvas, and most other decent things.

The big drawbacks of NeWS in my opinion are not having an MIT license, and being quite difficult to implement well. Also PostScript isn't the nicest language to program in, which I say from years of programming in it. But it's far from the worst, and if one changed the to postfix syntax to prefix, it would be mostly a Lisp.

What do you not like about PostScript? It's basically a worse Forth, which, when compared to most languages, is comparatively wonderful to write in.

How is PostScript a "worse Forth"? I find PostScript great fun to program in, and I think the type errors one gets from the system to indicate mistakes are a great help when writing PostScript code.

It's much higher level, chooses the worst bits of high-level languages to throw in, NeWS's spin of it was object-oriented which has since been shown to be a mistake, it's not as extensible, has too many stacks, introduces significant complexity for dubious benefit, so forth.

Of course, whether or not PostScript is like Forth at all is a matter of debate, some religiously disagree. I'm somewhere in the middle on that. Old flamewar topic:

http://wiki.c2.com/?ForthPostscriptRelationship

The syntax is also slightly less nice, which is relevant for their question, but less quantifiable.

I did a fair bit of PostScript development in NeWS/HyperNeWS and while I really liked PostScript I've never been able to get into Forth - I actually thought that PostScript was rather like the Common Lisp that the rest of the project used (one of the things I wrote for the project being the glue code in C to link the PostScript world of NeWS to Common Lisp - which is a nice mix of approaches to syntax!).

NB: It was particularly neat that Sun shipped a set of Adobe blue/green/red(?) books with OpenWindows.

PostScript does take a lot from Lisp, too. And (kind of) Smalltalk. 'DonHopkins has posted a lot about it on here; I really love hearing him talk about it:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Object oriented programming has since been shown to be a mistake??! That's NeWS to me. Can you provide a citation please?

What do you mean that NeWS or PostScript classes are not extensible? The little "e" in NeWS stands for "extensible".

And what is the correct number of stacks, in your opinion?

Please quantify what you can, and provide examples and links to code, and citations of other people who agree with your personal opinions like the number of stacks a language is supposed to have, the meaning of extensibility, or that object oriented programming languages are a mistake.

The little "e" in NeWS stands for "extensible".

But maybe that capital N is for Non .. (kidding obviously)

I've always been curious about NeWS but the web is quite short of demos about it (not helped by newspapers called Sun either). Do you know sites with videos about it ?

Thanks for asking! ;) I've put up some old demos on youtube, and made illustrated transcriptions of some, and written some papers and articles. Sorry the compression is so terrible on some of the videos. Here are some links:

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

PSIBER Space Deck and Pseudo Scientific Visualizer Demo. Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.

https://www.youtube.com/watch?v=_fqCeuue5Ac

Pseudo Scientific Visualizer. Demo of the NeWS PseudoScientific Visualizer and the PSIBER Space Deck.

https://www.youtube.com/watch?v=GatM3s2S75Q

Mousee Demo. Demo of Mousee running in the NeWS Window System.

https://www.youtube.com/watch?v=PRP2QorRDUw

Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab. University of Maryland Human Computer Interaction Lab Pie Menu Demos.

https://www.youtube.com/watch?v=kxkfqgAkgDc

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser. By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.

https://medium.com/@donhopkins/designing-to-facilitate-brows...

HCIL Demo - HyperTIES Browsing. Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.

https://www.youtube.com/watch?v=fZi4gUjaGAM

HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS. Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab. Tabbed window management with pie menus.

https://www.youtube.com/watch?v=hhmU2B79EDU

Just the Pie Menus from All the Widgets. Pie menu demo excerpts from "All The Widgets" CHI'90 Special Issue #57 ACM SIGGRAPH Video Review, produced by and narrated by Brad Meyers.

https://www.youtube.com/watch?v=mOLS9I_tdKE

Precision Pie Demo.

https://www.youtube.com/watch?v=c0scs59va4c

Handy Pie Menu Demo.

https://www.youtube.com/watch?v=TuA_yylYwjM

How To Choose with Pie Menus. Early pie menu demo by Don Hopkins, on NeWS 1.0, running on a Sun 3 workstation. Featuring the World's Most Enormous Pie Menu, and Direct PacManipulation!

https://www.youtube.com/watch?v=MOJaY6Xu7ao

NeWS Tab Window Demo. Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0.

https://www.youtube.com/watch?v=tMcmQk-q0k4

SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS)). HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

HyperLook SimCity Demo Transcript. This is a transcript of a video taped demonstration of SimCity on HyperLook in NeWS.

https://medium.com/@donhopkins/hyperlook-simcity-demo-transc...

HyperLook Demo. Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript, running on a SPARCstation 2. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.

https://www.youtube.com/watch?v=avJnpDKHxPY

The Story of Sun Microsystems PizzaTool. How I accidentally ordered my first pizza over the internet.

https://medium.com/@donhopkins/the-story-of-sun-microsystems...

The X-Windows Disaster. This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins.

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

If you can find a library copy, The NeWS Book (e.g. https://www.waterstones.com/book/the-news-book/james-gosling...) might also be of interest for a static view, but I don't know how much was actually implemented, and I'm away from my copy.

I haven't had a chance to look at the videos for old time's sake, and they may make the point: a big part of it, as a developer experimenting with things, was the mode-less Smalltalk-like environment which allowed you to modify the system on the fly. (I don't know how much like, since I never used Smalltalk.)

Edit: "Scott McNealy ate my window system" :-(

Yeah, I'd say GUI development is one of the places OOP really shines. I think a lot of the OOP was a mistake opinions come from its ubiquitous use in the enterprise, even in domains for which it was not well suited.

In what way is PostScript worse than Forth? Please answer with specific details, and provide links to code if you can. I programmed a lot of Forth code before learning and moving on to programming a lot of PostScript code, so I've used each of them extensively, and much prefer PostScript, and I'm happy to show you why and explain by showing you code.

PostScript is much higher level than Forth, and a lot more like Lisp than Forth, and has much better data structures than Forth, like polymorphic arrays (that can be used as code), dictionaries (that can be used as objects), strings, floating point numbers, and NeWS "magic dictionaries" that can represent built-in objects like canvases, processes, events, fonts, etc.

Yet Forth doesn't even have dynamically allocated memory, although in a few pages of code you can implement it, but it's not standard and very few Forth libraries use it, and instead use the linear Forth dictionary memory (which is terribly limited and can't be freed without FORGETting everything defined after you allocated it):

https://donhopkins.com/home/archive/forth/alloc.f

PostScript is homoiconic. Like Lisp, PostScript code IS first class PostScript data, and you can pass functions around as first class objects and call them later.

https://en.wikipedia.org/wiki/Homoiconicity

PostScript lets you define local variables with names in dictionaries, and use stacks of those dictionaries as objects and classes, while Forth requires you to keep track of everything on the stack without giving it a name. Forth variables are effectively globals. The fact that PostScript is homoiconic means you can write PostScript functions that dynamically create and transform other PostScript functions, like Lisp macros.

In October 1986, before I ever used NeWS or learned of Owen Densmore's Smalltalk-like PostScript object system, I had just used PostScript on the LaserWriter and invented my own simple object system like Lisp Machine Flavors (which was quite easy and obvious) for drawing pie menus, I wrote the following to Mitch Bradley comparing Forth and PostScript. (Mitch was the Forth guru at Sun who developed ForthMacs / Sun Forth / CForth / Open Firmware / etc -- I worked with him at Sun on Forth as his summer intern, then later with James Gosling at Sun on NeWS as a full time employee):

https://github.com/MitchBradley

https://donhopkins.com/home/archive/forth/forth-postscript.t...

After having programmed in PostScript for some time, how do you feel about its relation to Forth? Have your feelings about Forth changed any?

They are somewhat different languages, suitable for different applications, but there is a lot of overlap, however. There are features and problems that each has that the other lacks. I have thought a lot about doing in PostScript some of the things one can do in Forth, as well as Lisp.

In writing the code for the PieMenus on the Laser Writer, I had to come up with some way to make objects, not unlike flavors. It would also be interesting to make objects in the manner of <builds and does>. Objects are obviously implemented as dictionaries. Instance variables and messages are just bindings in the dictionary. The question is how do you build the dictionaries?

You can have PostScript functions that build them by hand, or you can have it more data driven. (Not to say that PostScript functions aren't data. Weee!) But how do you represent the data? You want to specify defaults when creating a class, and values when instantiating objects.

Should the creation of classes and objects be the same operation? (As with XLisp.) The required instance variable values could be taken as arguments when instantiating an object of some class, and the optional ones

How about object instantiation consuming required values? right off the stack? How would inheritance work? By concatinating dictionaries, or by nesting them?

It sure doesn't take much code to do this stuff. This is because PostScript has a very general set of building blocks for just such things.

PostScript makes it easy to efficiently implement a flexible dynamic object oriented programming system like Smalltalk's, with multiple inheritance, and prototype objects that you can dynamically promote both methods and instance variables from classes to instances. Tom Stambaugh described how Smalltalk inspired Owen Densmore's PostScript object oriented system in NeWS:

https://news.ycombinator.com/item?id=18696116

It seems to me that Forth is to stacks what LispLanguage is to lists. Forth demonstrated the advantages of a stack-centric paradigm in which each pushed or popped item could be evaluated as an expression or a primitive. Postscript reflects the application of that paradigm to the world of typography, 2-d graphics, and page layout. My own recollection is that Postscript's primary contribution was the use of splines to describe character glyphs, allowing them to be effectively rendered at virtually any resolution desired. If anything, Postscript owes more to TexLanguage and DonaldKnuth than to Forth. I view the stack-based language paradigm as a convenient afterthought rather than a central organizing principle.

I also think we should note the contribution that OwenDensmore, at Sun, made in demonstrating how to use Postscript dictionaries to create a dynamically-bound object-oriented runtime environment. This was the fundamental premise of the Sun window server that ultimately became the NetworkExtensibleWindowSystem. Owen and I discussed his "crazy" idea at a poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him that it made sense to me, we scribbled furiously on napkins, and I helped him see how he might adopt some learnings from Smalltalk. It was one of those afternoons that could only have happened at that time in that place in that culture. -- TomStambaugh

I've extracted Owen Densmore's paper from the news.tape.tar (marked PD), "Object Oriented programming in NeWS", and uploaded it:

https://ia802600.us.archive.org/5/items/pdfy-1U9Ry1_Qj0LPSR6...

Like Lisp or Scheme, you can easily write a metacircular PostScript evaluator in a few pages of PostScript:

https://news.ycombinator.com/item?id=21968842

Also, here is a metacircular PostScript interpreter, ps.ps: a PostScript interpreter written in PostScript! Since PostScript is homoiconic and so much like Lisp, it was as easy as writing a metacircular Lisp interpreter (but quite different in how it works, since PostScript and Lisp have very different execution models).

https://www.donhopkins.com/home/code/ps.ps.txt

https://donhopkins.com/home/archive/psiber/cyber/ps.ps.reaso...

    Obvious Question:
      Why would anybody ever write a PostScript interpreter in PostScript?

    Possible Answers:
      To use as a debugging tool.
      To trace and single step through the execution of PostScript code.
      To serve as a basis for PostScript algorithm animation.
      To gain a deeper understanding of how PostScript works.
      To try out some ideas from Structure and Interpreteration.
      To experiment with extensions to the PostScript language.
      To demonstrate that PostScript isn't just for breakfast any more.
      To make PostScript run even slower (but thicker).
      To avoid programming in C (the portable assembly language of the 80's).
      To use to interpret its self.
      To have something nerdish to talk about at parties.

And you can use NeWS PostScript to implement a visual programming system and debugger to itself:

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

NeWS not only supported multiple loadable toolkits, but it had "packages" to keep them safely separated and modularized so clients could request whatever versions of whatever toolkits they needed, and the same code and data would be properly shared between all compatible clients. (See "findpackage" / "beginpackage" at the beginning of every X11/NeWS program, like this X11 window manager for NeWS implemented in PostScript:)

https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt

In case you would rather program in a Lisp-like syntax than PostScript, David Singer and Rafael Bracho at Schlumberger wrote ListScript, a Lisp to PostScript compiler:

https://donhopkins.com/home/archive/NeWS/NeScheme.txt

PostScript is often compared to Forth, but what it lacks in relation to Forth is a user-extensible compiler. You can write your own PostScript control structures and whatnot, like case and cond, to which you pass procedures as arguments on the stack, but the PostScript scanner is not smart -- but there is no preprocessing done to the PostScript text being read in, like the way immediate words in Forth can take control and manipulate the contents of the dictionary and stack while the text source is being read in and compiled, or like the way Lisp macros work. This is one of the things I would like to be able to do with something like LispScript.

And in case you are suffering from poor taste in programming languages, and you don't like Lisp but would rather program in a C- or Java-like syntax than PostScript, Arthur van Hoff at the Turing Institute wrote PdB, an object oriented C to PostScript compiler, which let you subclass PostScript classes in PdB, and also subclass PdB classes in PostScript:

https://news.ycombinator.com/item?id=21968842

And later on around 1990-1993, Arthur van Hoff wrote PdB at the Turing Institute in Glasgow, an object oriented C to PostScript compiler called PdB (for Pure dead Brilliant), which is kind of like TypeScript, conceptually. We used PdB to develop HyperLook (Networked PostScript based HyperCard for NeWS), which I used to port SimCity to NeWS on Unix. (A few years after that, Arthur wrote the Java compiler in Java at Sun in 1995, and lot of other cool stuff since then!)

Thanks for all this stuff, some of which I wish I'd been aware of at the time, like LispScript.

I don't remember the details, like how it was used, but I recall the metacircular evaluator in HyperNeWS (or do I mean HyperLook?) being called out as a (the?) major pain point in the system for speed of the interpreter.

In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several clients in parallel than it is to parallelize a single server.

There is nothing more multi-core than a modern GPU. Actually the existence of modern GPUs is an argument FOR toolkit-in-server windowing systems. All you do is writing shaders that help you to keep the communication over the PCIe bus (and potentially network, if you want network transparency) as minimal as possible.

The NeWS system failed for none of the reasons described in the article. It failed because of bad performance. There never was custom silicon out there to render Postscript. Unlike today where you have vastly underused GPUs at your disposable just waiting to be stuffed with intelligence in form of shaders. Just have a look at https://shadertoy.com to see what is possible even on low-end GPUs.

Edit: as cpach pointed out shadertoy.com and not .org

In modern graphics applications (=games) people do try to reduce CPU-GPU communication, but it is still done a lot and is frequently a bottleneck. Increasing GPGPU work means CPU and GPU code communicate in both directions. Making it slower than it already is doesn't make sense from performance engineering POV unless there are some dramatic advantages from the tradeoff.

Increasing GPGPU work means CPU and GPU code communicate in both directions.

Only if you make the wrong abstractions. Using a shader based toolkit is not about increasing the GPGPU work but to use the GPU for things that it is intended to do namely drawing. And if you make the right abstractions you can severely reduce CPU-GPU communications. In fact a toolkit is exactly the perfect type of abstraction in that scenario. Most of the input is mouse and keyboard data and a bunch of drawing commands which means extremely low bandwidth, less CPU-GPU communication, more performance and faster applications. I'm not sure what you mean by "tradeoff". Look for example at the shaders of sahdertoy. For the most part the only data they receive from the CPU is a timestamp of the current frame and occasionally mouse and keyboard data which is in the worst case literally just a bunch of bytes per frame.

To my eyes, NeWS does not look like a mistake. On the contrary, it looks beautifully engineered.

Among other advantages, I can imagine a world where PostScript would be used for building user interfaces: a document in screen and print would look the same, without need for writing conversions like, e.g. HTML+SVG -> PDF when someone needs to somehow print a web form quickly. And perhaps the old principles of typography and the experience in typesetting beautiful books with PostScript could be more easily applied to UI design.

a document in screen and print would look the same

This only works if all the screens are the same size as a sheet of paper.

And have the same dpi as whatever's used to print them!

A key advantage of PostScript is that you can scale all output using transformations, so that you internally work with the same coordinate space (called user space) on all devices, and implicitly scale — and also for example rotate — all graphics when they are actually drawn.

This extends to fonts too, since PostScript letters are drawn using the same graphic primitives as other graphs.

I worked on a project in the early 1990s where we used the utterly wonderful HyperNeWS for most things - we used to play tricks on each other by doing silly things like logging into someone else's NeWS server using psh and setting the rotation in the transforms for a terminal window to be slightly off as people were using them - eventually people would notice of course but things would just work.

Another neat trick that HyperNeWS supported was drawing a shape in its graphical editor and then pasting that shape as the shape of a window...

Well, I have some questions now:

- Is it necessary that the document should take the whole screen?

- Is it possible to render a PostScript document in different sizes and resolutions?

- Do any people today read PDFs on their screens? If some do, are all their screens the same size as a sheet of paper?

Anyway, that was not the spirit of my comment. I meant, doing design in HTML, CSS, SVG and then working out again, all from the beginning, how to convert the document to a printable version of professional quality, is more work than writing PostScript for both, even if some configuration necessarily differs between screen and print.

There are definitely a lot of difficult issues and trade-offs about implementing true "WYSIWYG" editors that let you layout text and graphics that looks exactly the same on the screen and when printed.

This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get.

https://www.youtube.com/watch?v=z_dt7NG38V4

Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical.

And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different.

NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that.

NeWS 1.1 manual, page 146:

http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801...

setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch

Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful.

Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously.

Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time.

It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements.

And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode).

Now printing text on paper is only an afterthought, something wasteful to be avoided. So fewer people actually need to edit two-column paginated text just like it will appear printed on paper in a journal, or fuss about exact text layout and worry about terrible "rivers" ruining their otherwise perfectly justified paragraphs.

https://en.wikipedia.org/wiki/River_(typography)

https://en.wikipedia.org/wiki/WYSIWYG

WYSIAWYG; what you see is almost what you get, similar to WYSIMOLWYG.

WYSIMOLWYG, what you see is more or less what you get, recognizing that most WYSIWYG implementations are imperfect.

http://foldoc.org/WYSIWYG

What You See Is What You Get <jargon>

(WYSIWYG) /wiz'ee-wig/ Describes a user interface for a document preparation system under which changes are represented by displaying a more-or-less accurate image of the way the document will finally appear, e.g. when printed. This is in contrast to one that uses more-or-less obscure commands that do not result in immediate visual feedback.

True WYSIWYG in environments supporting multiple fonts or graphics is rarely-attained; there are variants of this term to express real-world manifestations including WYSIAWYG (What You See Is Almost What You Get) and WYSIMOLWYG (What You See Is More or Less What You Get). All these can be mildly derogatory, as they are often used to refer to dumbed-down user-friendly interfaces targeted at non-programmers; a hacker has no fear of obscure commands (compare WYSIAYG). On the other hand, Emacs was one of the very first WYSIWYG editors, replacing (actually, at first overlaying) the extremely obscure, command-based TECO.

See also WIMP.

The Acorn Archimedes had anti-aliased text using 8 grey levels on a 4 or 8 bit display, on computers with 0.5MB RAM in 1990... http://telcontar.net/Misc/GUI/RISCOS/#text so in theory it could have been practical for Sun ...

If your display only has gray levels, then anti-aliasing is easy since you don't need to worry about rendering text over non-white backgrounds, and you don't need to worry about a colormap. But 8 bit displays with colormaps make it much harder to support anti-aliased text practically, especially over arbitrary backgrounds (because it would look terrible as well as being slow).

NeWS used a color cube with only a certain number of grays, and those were only useful for anti-aliasing black text against a white background (or the other way around), and you didn't have a lot of colors to choose from for antialiased color text or against colored backgrounds. It's much easier to render anti-aliased text in 24 bits, or with pure gray scale, since you aren't restricted to an 8 bit color palette, and you can efficiently mathematically blend colors together, instead of looking up rgb values in a colormap, blending to get the ideal desired color, and then searching for the nearest color to each pixel in the colormap (or indexing the color cube for the nearest color) (which won't be very near, and will look flat and washed out without dithering).

Better visually to render the whole image with antialiased text in full 24 bits, then use error diffusion dithering over the entire image at once (to avoid flat washed out regions, and distribute the error over space) to make an 8 bit palletized version, but that's quite slow and memory intensive.

Of course your application (like a monochrome PostScript previewer) could switch in an all-gray ramp colormap for efficiently rendering and beautifully displaying anti-aliased text, but then all the other windows on the screen would be shown in the wrong colormap, and the colormap would flash back and forth when you moved your focus between windows.

Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces.

This was followed by a vision of a window system built on ROFF.

Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision.

Hope something like that will never see the light of day.

Perhaps all that will be implemented is character cell windowing systems.

And Doom. Definitely Doom.

Hurray for the MGR window system!

https://hack.org/mc/mgr/

https://en.wikipedia.org/wiki/ManaGeR

ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore.

MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent.

Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software.

The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2]

MGR was the largest posting to ever appear in comp.sources.unix:

https://groups.google.com/forum/#!topic/comp.sources.unix/GG...

Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones.

https://www.donhopkins.com/home/code/display.c.txt

Maryland Windows source code:

http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar

https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/...

Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.

Even worse would be a window system or browser built on SGML or one of its mutant derivatives. Imagine a world where servers download tag soups of structured text with angled brackets and attributes to define formatted text, styles, and interactive users interfaces! It could only be worse if nobody could agree on which mutant derivative of SGML to use, so there were several different ones, and then a totally different style language that was completely syntactically unique, so you could not use the same syntax and tools to write and edit all the almost-but-not-quite-entirely-unlike-SGML syntaxes mish-mashed together.

Oh wait. That IS what we have today! Never mind.

That said imagine if the SGML working group had held their ground and used s-expressions! At least the soup would be easy to slurp. (I can’t find a reference right now so maybe I just had a fever dream once?)

You are probably thinking about DSSSL:

https://en.wikipedia.org/wiki/DSSSL

"Sometime in or before 1994, Opera Software began drafting a "DSSSL Lite" specification for the consideration of the World Wide Web Consortium"

I can imagine a world where PostScript would be used for building user interfaces

NeXT did that in 1988: https://en.wikipedia.org/wiki/Display_PostScript

What NeXT missed out on is what we now call "AJAX": the advantages of implementing the user interface toolkit and the front-end parts of the application in PostScript, so it runs right next to the user, can can implement an efficient application specific networking protocol to communicate between the client and server. NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc.

https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

Consider this. As we know, Tim Berners-Lee developed the first web browser on a NeXT computer, with Display Postscript to render HTML (and print it, too). Two years later, Marc Andreessen and Eric Bina developed the NCSA Mosaic web browser for the X Window System and Microsoft Windows. Another 2 years, and Brendan Eich made the Netscape Navigator web browser programmable with JavaScript.

What if Sun had open sourced NeWS in the early 90s? Could NCSA or Netscape have used an open source NeWS to build a web browser that renders HTML using NeWS on X11 or Windows? With no need for JavaScript or CSS, just Postscript?

Don Hopkins? Is it plausible that we’ve had 25 years of JavaScript hell because Sun management didn’t open source NeWS? Or were there insurmountable technical obstacles as well?

Netscape succeeded because they had a 16-bit implementation. 16-bit postscript would have been a significant challenge.

That's a good point. PostScript needs floating point numbers and lots of memory. At one point in history, for the typical "Desktop Publishing" setup of a Mac and a LaserWriter, the LaserWriter actually had more CPU power and memory than the Mac!

https://en.wikipedia.org/wiki/LaserWriter#Hardware

The LaserWriter used the same Canon CX printing engine as the HP LaserJet, and as a consequence early LaserWriters and LaserJets shared the same toner cartridges and paper trays. PostScript is a complete programming language that has to be run in a suitable interpreter and then sent to a software rasterizer program, all inside the printer. To support this, the LaserWriter featured a Motorola 68000 CPU running at 12 MHz, 512 kB of workspace RAM, and a 1 MB frame buffer.

At introduction, the LaserWriter had the most processing power in Apple's product line—more than the 8 MHz Macintosh. As a result, the LaserWriter was also one of Apple's most expensive offerings. For implementation purposes, the LaserWriter employed a small number of medium-scale-integration Monolithic Memories PALs, and no custom LSI, whereas the LaserJet employed a large number small-scale-integration Texas Instruments 74-Series gates, and one custom LSI. The LaserWriter was, thereby, in the same form factor (for its RIP), able to provide much greater function, and, indeed, much greater performance, all within the very same LBP-CX form factor, although the external packaging was, for marketing purposes, somewhat different.

We certainly fought hard to convince Sun to make NeWS free.

James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS:

    Date: Tue 6 Mar 1990 08:37:51 PST
    From: James Gosling <jag@Eng.Sun.COM>
    Subject: Re: Sun's response to the net
    To: Don Hopkins <don@cs.UMD.EDU>
    In-Reply-To: Don Hopkins's message of Tue, 6 Mar 90 05:03:31 -0500

    > When is the message from Sun coming out? Will it be from you, or
    > someone else who will be believed?

    It'll be from me, and it'll come out today or tomorrow.

    > Will it mention the possibility of Sun putting xnews in the public
    > domain, or is it too early to say anything about that?

    It's too early to say.  It looks good so far, but there are still some
    possible legal problems that we need to check out.

    > How are the changes at Sun related to making xnews free?  Is it a
    > central point or just a side issue?

    It's a pretty central issue.

    > I'm afraid that a renewed commitment to NeWS or internal changes at
    > Sun just won't mean that much to me or the rest of the world, unless
    > Sun does something substantial that will benefit everyone, like making
    > xnews free. As long as Sun keeps NeWS proprietary, any effort they put
    > into it will just be seen as self serving...

    We'll get it out, even if I have to spill some real blood on the floor.

    > What do you think of the theory about DEC making unlimited funds
    > available for shooting down NeWS? If there's any merit to that, would
    > they try to keep the X Consortium from accepting the donation of xnews
    > server source code?? I'm sure DEC couldn't do anything to keep Sun
    > from donating GNeWS/X11 to the Free Software Foundation, and I know
    > FSF would take it. (I suspect DEC would much rather NeWS die a slow
    > painful proprietary death, dragging Sun down with it.)

    It has been very clear for a long time that DEC explicitly targeted
    NeWS as something to be trashed.  That was probably the major reason
    for giving NeWS such a ridiculously low profile.  There were folks at
    sun who didn't want to give DEC a bigger target.  The folks running the
    show now have more guts.

                    James.

But in the end Sun redefined the meaning of the word "free" by announcing that OpenWindows source code was "Free for $1000": it cost $1000 for the tape media, and nobody was allowed to put it on an FTP server.

Here is a link to my flamey-poo on that sensitive topic, followed by the official announcement to which I was reacting. I'll include some choice excerpts, and a couple more links on the topic.

https://www.donhopkins.com/home/archive/NeWS/flame.txt

I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free".

In short: If you were a slave, what how would you feel if your master announced you could go "free", but he really meant he was selling you down the river for a media cost of only $1000?

[...] For years, we (customers, software developers, and employees) have been asking Sun to make Open Windows available for free, in such a way that it could be distributed on the X11R4 tape or through other public channels, but that has not happened yet. Our biggest concern is not that we don't have to pay money!! The most important thing is that we can make changes to the source code, and give copies of it to anyone who wants it, using any media or distribution channel. But we can't, so it doesn't matter how cheap it is.

Package Includes Window System and Toolkits

MOUNTAIN VIEW, Calif. -- November 13, 1990 -- Sun Microsystems announced today that the source code for its OpenWindows(TM) application development environment will now be available free of charge (cost of media only -- $995). This means that hardware and software developers will now have a cost-effective way to incorporate OpenWindows -- including the easy-to-use OPEN LOOK(R) graphical user interface -- into applications developed or ported to many platforms from different vendors.

The package includes code for the X11/NeWs(TM) Window System, OPEN LOOK toolkits, and OpenFonts(TM) with its TypeScaler(TM) technology. Before today, only OpenWindows binaries were available from Sun.

"Offering free source code for the industry's most advanced, comprehensive window environment demonstrates our ongoing commitment to open systems," said Ed Zander, vice president of marketing at Sun.

[bla bla bla]

Availability

OpenWindows source code will be available January 1, 1991 on magnetic tape for $995 (which includes the cost of media and documentation) through Sun distributors. The source license is included at no cost. There are no royalties for distributing applications developed with OpenWindows. Hardware vendors will pay nominal royalties for systems they resell that run the OpenWindows environment.

I left Sun because they asked us to lie to our customers that Sun was going to continue supporting NeWS, but we knew that was not true.

Here's a personal apology and explanation I wrote to one of our customers:

https://www.donhopkins.com/home/archive/NeWS/Explanation.txt

Knut, I just quit my job at Sun because Sun's managment is living a lie. Their words say they support NeWS, but their actions testify to just the opposite. There are many people in Sun who want quite badly to kill NeWS, and they have been trying to do that while at the same time giving lip service to NeWS, so they don't get fired. McNealy and other top level executives say they support NeWS, and say they will fire anyone who tries to kill it. So everyone pretends to be behind it to keep their job, while continuing to sabotage it. It is a very unpleasant and unfortunate situation.

And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm".

https://donhopkins.com/home/archive/NeWS/owm.ps.txt

https://www.donhopkins.com/home/archive/NeWS/sevans.txt

Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment."

Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run).

We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could.

Window manager flames:

https://www.donhopkins.com/home/catalog/unix-haters/x-window...

Who Should Manage the Windows, X11 or NeWS? This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.

Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.

Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager! Some notes about OWM OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!

This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!

I39L window management complicates pinned menus enormously. TNT menus pin correctly, so that when you push the pin in, the menu window simply stays up on the screen, just like you'd expect. This is not the case with XView or even OLWM. Under an I39L window manager, the Open Look pinned menu metaphor completely breaks down. When you pin an X menu, it dissappears from the screen for an instant, then comes back at a different place, at a different size, with a different look and feel. If you're not running just the right window manager, pinned menus don't even have pins! There is no need for such "ICCCM compliant" behavior with TNT menus. When they're pinned, they can just stay there and manage themselves. But were TNT windows managed by an external I39L window manager, they would have to degenerate to the level of X menus.

Under the OWM solution, pinned TNT menus work correctly, and they inherit their pinned window behavior from ClassPopupWindow, the same class managing pinned X menus. The look and feel is high quality, consistant, maintainable, and intentionally extensible.

If I39L window management has such a negative impact on pinned menus, how else will it impact other parts of the toolkit and applications?

Will it effect popup notices? Since they need keyboard input for the buttons, will they have to play the I39L window management game? How do we get the notice tail (a separate canvas) to line up, if the window manager decides to wrap a frame around the notice window?

It is impossible to know how it will effect TNT applications, because the toolkit was specifically designed to be subclassed and extended in areas that overlap with I39L window management. NeWSRoom and the TNT virtual window manager are examples of simple, interesting extensions to the window class that are in direct conflict with I39L window management. We would be giving up a lot of actual and potential functionality, that we designed the toolkit to support in the first place. We need to redesign the window class for greater flexbility and easier subclassability, but those goals are at odds with I39L window management. The result of a cross of these two opposing goals would be massivly complex and would sacrifice most of the important advantages of the TNT approach. However, the OWM approach to window management, wrapping X windows in instances of the TNT window class, synergizes with extensions to the window classes. As an extreme example, you can make OWM wrap window frames with title tabs that pop up pie menus full of handy window management functions around all your X windows.

There are several other technological advantages of managing X windows internally with NeWS, over managing them externally with X. By an external window manager, I mean one that is in a separate address space as the windows. Relative to the server, all windows are internal, all X "Xlib" and NeWS "wire service" clients are external, and NeWS canvas objects and light weight processes are internal. But an external X window manager is in a different address space must try to manage many shared resources at a distance, an intrinsicly difficult task, imposing limitations on the whole system and unavoidably restricting the user interface possibilities.

The management of arbitrarily shaped windows becomes very complicated under an I39L window manager. In contrast, PizzaTool has a popup pizza preview window, whose shape is a rectangular frame around a round (or semi-circular, depending on your appetite) pizza window, with the space between the inside of the frame and the pizza cut out. It was very easy to implement, by subclassing ClassPopupWindow and overriding the /path method to cut out the inside of the frame and ask the center pizza client to add its shape to the path. When you move or stretch the window, you see a rubber-band preview of the actual shape the window will take when you release the button. The pizza path procedure knows to maintain a 1:1 aspect ratio (no oval pizzas), that centers the round pizza in the frame as you drag the resize corner around. The shape of a TNT window is not simply defined by curves or bitmaps -- it is defined by a method of the window object, which can apply constraints and may depend on the state of other objects in the system, like the size or number of slices of the pizza inside the frame. All this nice interactive feedback is totally trivial to implement with TNT, and is completely impossible with an I39L window manager. And even if an I39L window manager could be programmed to perform such custom feedback, it would still have to grab the server and lock out all other animation in the process, instead of using nondestructive overlays like TNT.

X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.

If NeWS alone manages the input focus, it can manage it perfectly. An X window manager alone cannot, because it runs in a foreign address space, and is not in a position to synchronously block the input queue and directly effect the distribution of events the way NeWS is. But even worse is when an X window manager and NeWS both try to manage the input focus at once, which is the situation we are in today. The input focus problem could be solved in several ways: OWM solves the problem elegantly, as PSWM did in the past; OLWM could be made NeWS aware, so that when our own customers run our own external X window manager on our own server that we ship preinstalled on the disks of our own computers, OLWM could download some PostScript and let NeWS handle the focus management the way it was designed.

It's criminally negligent to ship a product that is incapable of keeping the input focus up to date with the cursor position, when you have the technology to do so. Your xtrek has paged the window manager out of core, and the console beeps and you suddenly need to move the cursor into the terminal emulator and type the command to keep the reactor from melting down, but the input focus stays in the xtrek for three seconds while the window manager pages in, but you keep on typing, and the keys slip right through to xtrek, and you accidentally fire off your last photon torpedoe and beam twelve red shirt engineers into deep space!

We certainly fought hard to convince Sun to make NeWS free.

After reading your "flamey-poo" I'm wondering how much other non-technical, meddlesome corporate baggage would have come along for a ride even if someone somehow could have convinced them to make "free" === "free".

If it was more than none, I have a hard time seeing how a strong enough "View Source" philosophy could have sprouted from it no matter how strong the tech was/is. From what I understand the web started with that philosophy, and it only partially made it out of the battle with copy/paste intact.

The fact that you were apparently already burned out once before this flame tells me that there was a lot of such baggage. Am I in the ball park here?

NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc.

Not in Display PostScript, perhaps, but NeXT definitely had OOP pervasively; where do you think the modern Apple use of Objective-C came from?

"One of the great white hopes of the part of the Unix world that never liked X Windows was Sun's NeWS."

I searched Wikipedia and found that "Great White Hope is a nickname or epithet originally applied to boxers who were the hope of the "White Race" to beat African American boxer Jack Johnson."

That seems an odd way to characterize the situation.

It makes sense when you consider that white people were wringing their hands because they were convinced of their total superiority.

While obviously more benign, there is inherent bigotry in the “X sucks and the better solution is Y or Z and why won’t they catch on?” mindset. Surely this next technology will take over from the unacceptable popular one.

(Edited because QuickPath has a long way to go before it’s as functional as Swype)

Actually, the predecessor to X was called W. And many people have proposed the next version of X should be called Y, because X12 wasn't different enough, and some even have suggested skipping Y and going directly to Z to get even more distance from X. But the one thing they all agree on is that X sucks.

https://en.wikipedia.org/wiki/NeWS

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

FTFY:

Web Browsers were a mistake, as are all toolkit-in-browser JavaScript libraries

April 1, 2020

One of the great white hopes of the part of the Web world that never liked Gopher was Netscape's web browser. Never mind all of its practical flaws, all sorts of people held web browsers up as the better way and the bright future that could have been if only things had been different (by which they mean if people had made the 'right' choice instead of settling for Gopher). One of the reasons people often give for liking web browsers is that it put much of the JavaScript libraries into the web browser instead of forcing every server to implement it separately.

Unfortunately for all of these people, history has fairly conclusively shown that web browser was a mistake. Specifically the core design of putting as much intelligence as possible into the web browser instead of the web server has turned out to be a terrible idea. There are at least two big reasons for this.

The first is parallelization. In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several web servers in parallel than it is to parallelize a single web browser. Even if you do get equal parallelization, separate web servers are inherently more resilient because the operating system intrinsically imposes a strong separation of address space and so on, something that's very hard to get in server where everything is jumbled together.

(I believe that this is one reason that modern HTML CSS rendering has been moved from the web browser to the web server. WebFont rendering is increasingly complex and CPU-consuming, so it's better to stick web servers with that burden than dump all of it on the web browser. After all, all Web Servers should have multiple GPUs for drawing and accelerating graphics and numeric computing for all their clients, but there is no rational reason anyone would ever want to program the GPU in the web browser, or push that processing off from the honking big accelerated server farms that you're renting from Amazon by the minute, to the millions of web browsers run by your users whose electricity you don't need to pay for. Plus, users enjoy waiting for their graphics to download over the internet in response to every mouse click and movement they make. It gives them time to think and reflect.)

The second is that if you put the toolkit in the web browser you make evolving the toolkit and its API much more complicated and problematic. The drawback of having everyone use the web browser toolkit is that everyone has to use the same web browser toolkit. Well, not completely. You can introduce a mechanism to have multiple toolkit versions and APIs all in the same web browser and allow web servers to select which one they want or need and so on and so forth. The mess of a situation with the current web browser and its JavaScript libraries make a very educational example of what happens if you go down this path; not very much of it is good.

(Some JavaScript libraries are in practice mandatory but still must be probed for and negotiated by the web servers, while others are basically historical relics but they still can't be dropped because some web server somewhere may ask for them.)

JavaScript libraries in the web browser push the burden of dealing with the evolution of the library into the web server. It is the CDN and web browser cache that carries around old or new versions of the library, with various different APIs, and you naturally have old library versions (and even old toolkits) go away entirely when they are no longer used by any active web servers (or even any installed web servers, when things get far enough).

(I'm ignoring potential security issues for complex reasons, but they may be a good third reason to be unhappy with browser-side libraries.)

Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard".

(This was part of a discussion with Owen about NeFS, which was a proposal for the next version of NFS to run a PostScript interpreter in the kernel. More about that here:)

https://news.ycombinator.com/item?id=17077721

Owen Densmore's discussion of John Warnock's "Linguistic Motherboard" idea for PostScript:

https://donhopkins.com/home/archive/NeWS/linguistic-motherbo...

    Date: Tue, 20 Feb 90 15:20:52 PST
    From: owen@Sun.COM (Owen Densmore)
    To: don@cs.UMD.EDU
    Subject: Re:  NeFS

    > They changed the meaning of some of the standard PostScript operators,
    > like read and write, which I don't think was a good idea, for several
    > reasons... They should have used different names, or at least made ..

    Agreed.  And I DO see reasons for the old operators.  They could
    be optimized as a local cache for NeFS to use in its own calcs.

    > Basically, NeFS is a *particular* application of an abstraction of
    > NeWS. The abstract idea is that of having a server with a dynamically
    > extensible interpreter as an interface to whatever library or resource
    > you want to make available over the network (let's call it a generic
    > Ne* server).

    Very true.  This has been particularly difficult for me to get across
    to others here at Sun.  I recently wrote it up for Steve MacKay and
    include it at the end of the message.

    > It's not clear to me if NeFS supports multiple light weight PostScript
    > processes like NeWS.

    I asked Brent about this, and he agreed that it's an issue.  Brent
    has been talking to a guy here who's interested in re-writing the
    NeWS interpreter to be much easier to program and debug.  I'd love
    to see them come up with a NeWS Core that could be used as a generic
    NetWare core.

    I think you should send  your comments off to nfs3 & see what happens!
    I agree with most of your points.

    Owen

    Here's the memo I consed up for MacKay:

======================================================================

Window System? ..NeWS ain' no stinkin' Window System!

-or-

Swiss Army NeWS: A Programmable Network Facility

======================================================================

Introduction

NeWS is difficult to understand simply because it is not just a window system. It is a "Swiss Army Knife" containing several components, some of which contribute to its use as a window system, others which provide the networking facilities for implementing the client-server model, all embedded in a programmable substrate allowing extremely flexible and creative combination of these elements.

During the initial implementation phase of the Macintosh LaserWriter software, I temporarily transfered from Apple to Adobe working closely with John Warnock and other Adobe engineers. At lunch one day, I asked: "John, what do you plan to do after LaserWriter?" His answer was interesting:

        PostScript is a linguistic "mother board", which has "slots"
        for several "cards".  The first card we (Adobe) built was a
        graphics card.  We're considering other cards.  In particular,
        we've thought about other network services, such as a file
        server card.

He went on to say how a programmable network was really his goal, and that the printing work was just the first component. His mentioning using PostScript for a file server is particularly interesting: Sun's next version of NFS is going to use PostScript with file extentions as the client-server protocol!

This paper explores NeWS in this light: as a Programmable Network Facility, a major part of Sun's future networking strategy.

NeWS Networking Components

NeWS has realized John's notion of a programmable network facility. It has populated the initial PostScript mother board with several cards vital to netwoking:

    -Device Independent Graphics Primitives: The key importance of the
     PostScript graphics model for networking is that it is device
     independent, able to represent with one file the same drawing on
     *all* the network hosts.  The Folio fonts contribute to this: they
     can be rendered at a given point size on all screens, regardless
     of resolution.

    -Host Independent Interpreter: PostScript is an interpreted language
     that runs on all Sun workstations without recompilation.  The
     significance of this for networking is that small code fragments
     can run on any host without any knowledge of the host's
     architecture.  Thus one host sending a code fragment to another
     host need not be concerned whether that host is a Sun-3, Sun-4, or
     even Macintosh!  This extends to client programming languages as
     well: all client languages have the same interface to the host.
     As an illustration of this point, both C and Lisp clients use
     the TNT toolkit with no special interfaces for each language.

    -Network Socket Primitives: NeWS has added primitives for listening
     for connection requests, for socket files, for host name and
     internet number management, and for reading and writing on the
     network connection.  In fact, the NeWS "server" code is not
     written in C, it is written in PostScript.  The initial version,
     and the one I run on my own machine today, is 10 lines of code!

    -Light Weight Processes (LWP): A network host has many independent
     activities taking place at one time.  Each of these uses a
     separate LWP.  These activities need not be window oriented,
     and in fact most are not.  Consider WUE alarms, for example.
     A LWP could be created on each WUE NetStation whose only task
     was to listen for activities on other WUE NetStations and to
     cause a WUE Alarm to occur when an interesting event occurs.

    -Garbage Collection: When data is allocated within NeWS, it is
     returned to the free memory pool when no process references it.
     This is needed in a multiprocessing network host because separate
     LWPs can reference the same shared data.  (No process can safely
     free data itself, because other processes might reference it.)
     Garbage collection manages this problem for the processes, and
     thus is an important Network facility.

    -Programmable Events: NeWS has a flexible, very easy to use
     event management scheme.  Processes fill out templates of events
     they are interested in.  When these are matched by events occuring
     within the system, they are delivered to the interested process.
     Events are *far* more useful than simple keyboard and mouse events.
     They can be artificially manufactured for any sort of inter-LWP
     communication.  For the previous WUE Alarm, for example, the WUE
     "Listening" process would communicate to WUE-Friendly applications
     by filling out a WUEAlarmEvent and sending it.  The interested
     applications would have filled out a template which would "catch"
     the event.

    -Programmable Error Handling: NeWS uses the standard PostScript
     exception handling, extended to work within the context of LWPs.
     Thus an error in one LWP is isolated to that process only.
     Network programs can "wrap" incomming code inside of the special
     "stopped" error handler which will catch errors occuring inside
     the code fragment.  This is vital to safe network programming.

What IS NeWS Anyway!

"Well, I'm glad NeWS has all these useful parts, but just what IS NeWS anyway; how do I get at and use all this stuff."

Well you may ask! It does seem confusing.

Formally, NeWS is simply a Unix command, just like "ls" and "cd". Its syntax is:

    xnews [PostScript-code]

i.e. it is a command that executes PostScript code fragment. If the xnews command is given without an explicit argument, it defaults to executing "(NeWS/init.ps) run", which simply looks for the file "init.ps" in the "$OPENWINHOME/etc/NeWS" directory. It is this file that uses the NeWS components to setup the X11/NeWS window system.

As a silly example of handing in your own commands to NeWS, we can do this:

        bigmac% xnews "1 1 add ="
        2

This simply tells xnews to add 1 & 1 and print the results. Oddly enough, I have written a somewhat more complex script to fill out my Traval Advance forms, adding up all the rows and columns and printing out a version of the form!

Now that we've gotten though the fundamentals, the rest of the paper will look at individual examples of using NeWS in novel ways. Although we present programs to illustrate how things are done, the reader may skip over them, the accompaning text will explain what the program does.

The Ten-Line Server

As mentioned above, "xnews" is simply a Unix command that executes a PostScript program, defaulting to "(NeWS/init.ps) run". Init.ps performs several initialization tasks and executes the commands in various other files. When its done with all of that, it defines and executes a small procedure called "server". This program uses the NeWS networking facilities to build a LWP which listens for connection requests from "client" programs. Whenever a request is heard, the LWP awakens and creates and initializes a new LWP just for the client's usage.

Here's the ten line version of the server. This actually works (I've run it for quite some time!), and is explained in Chapter 10, Networking NeWS, of the Unix Networking book published last year.

    /server { % - => -; create the NeWS client-server listner process
        {   clear newprocessgroup           % -;    Clean stack, init process group
            (%socketl2000) (r) file         % soc;  Open socket for listening
            {   dup acceptconnection        % soc f;Loop forever creating clients
                {   exch pop 200 dict begin % f;    Create userdict
                    initmatrix newprocessgroup % f; Init graphics & process
                    cvx exec                % -;    Execute the connection!
                    currentprocess killprocessgroup%Cleanup client & children
                } fork pop pop              % soc;  Clear process & file
            } loop                          % soc;  Loop forever creating clients
        } fork pop                          % -;    Fork server & toss process
    } def

The significance of this is that we can just as easily build other network services with NeWS, using code much the same as the above. NeWSPrint, for example, uses a similar PostScript program to provide network printing facilities. NeWSPrint does not require a special, modified version of xnews; it simply uses the standard OpenWindows product.

ps2bits: A PostScript to Rasterfile Program

A second use of running xnews as a Unix filter is illustrated by the ps2bits probram. This Bourne shell script reads a PostScript file on its "standard in", and emits the resulting Sun raster file on its "standard out". The shell script does this by having xnews:

-Read in a few standard PostScript initialization files,

-Initialize the PostScript environment (& fix a Folio bug!)

-Build an 8.5 by 11, color, 72 dpi resolution "page" canvas

-Execute the PostScript stdin file to draw that page

-Write the resulting image to stdout as a raster file

Here is the program:

    #! /bin/sh
    xnews "
        (NeWS/pack.ps)      (r) file cvx exec
        (NeWS/basics.ps)    (r) file cvx exec
        (NeWS/redbook.ps)   (r) file cvx exec
        500 dict begin false setautobind () stringwidth pop pop
        612 792 8 [1 0 0 -1 0 792] null buildimage setcanvas
        (%stdin) run clippath (%stdout) (w) file writecanvas
    "

Note: The line with the "buildimage" command may be modified to convert the program to black & white, or to change the resolution to 300 dpi, or to change the page size. See Appendix A for a more general script.

Once the image is made, it can easily be looked at in SunView, XView, or NeWS using any of their raster file viewers. Here's a trivial viewer, "bitwin", using the TNT toolkit:

    #! /bin/sh
    psh <<BITS
        /win [ClassCanvas] [] framebuffer /new OpenLookBaseFrame send def
        {   clippath pathbbox scale pop pop
            (${1}) readcanvas imagecanvas
        } /setpaintproc /client win send send
        (${1}) /setlabel win send
        100 100 425 550 /reshape win send
        /activate win send
        /map win send
    BITS

This Bourne shell script takes a single command line argument naming the raster file. It uses the NeWS "PShell" to sent a short program to the running xnews server. The program will put the file name in its header, and will fill itself with the raster file image. Stretching the window will stretch the image.

To use these on the demo file "tiger.ps" which was initially created on the Mac using Adobe Illustrator, these two steps are taken:

    bigmac% ps2bits < $XNEWSHOME/demo/PostScript/tiger.ps > /tmp/bits
    bigmac% bitwin /tmp/bits &

The first command converts the tiger drawing into a raster file. The second creates a window for viewing the raster file.

Although the complexity has been fairly minor in the previous examples, we've illustrated some powerful capabilities:

    -We can easily use NeWS to provide a simple Unix facility for
     converting PostScript drawings into Sun raster files.  The
     PostScript may come from any of the many widely available sources,
     even the Macintosh.

    -These raster files can be used by any toolkit, including SunView.
     They can even be used by other raster devices such as printers.

    -Using the networking primitives used in the 10-line server, we
     could easily build a similar server for providing raster files
     to anyone on the network.

Using these NeWS facilities in similar creative ways is exactly what NeWSPrint does. The documentation folks use a similar "filter" to strip out all the general header information in Mac PostScript files to gain an average 8-1 compression, vastly reducing their disk storage requirements. A homework assignment in our Usenix NeWS tutorial is to create a generalized Image Server for the network using these facilities.

WUE Alarms with Programmable Events

WUE has the notion of "alarms" which can be used to alert applications of changes in status of network objects. Applications can use this for anything from "hot links" to file status alarms. One of the WUE examples is on file status: I want to know when the monthy report reaches 90% completion. Hot links are similar: I want this graph to change whenever the associated spreadsheet changes.

Here is one way to implement WUE file alarms using NeWS programmable events:

    -WUE provides a Property Sheet which includes a file completion
     field holding a percentage quantity.

    -When the Property Sheet is completed, it creates and sends a
     WUEStatusEvent for the given file.  The network name of the object
     is stored in the event's Action field.  The event includes
     auxillary information about the file in the ClientData of the
     event.

    -Applications following WUE object status changes use the NeWS
     "expressinterest" primitive to catch all WUEStatusEvent's for the
     desired file.  It then looks at the ClientData to determine
     whether or not further action should be taken.

The WUE Property Sheet would build and send the event this way:

    createevent dup begin
        /Name   /WUEStatusEvent def
        /Action (/home/project/status/january) def
        /ClientData 1 dict dup begin
            /Completion .70 def
        end def
    end sendevent

The application builds an interest for its TNT event manager to handle. It does so by building a matching event template for WUEStatusEvent and the /home/project/status/january filename. It also includes a "callback" procedure which decides what to do with the completion information. In this case, we want the alarm to occur when the file is more than 90% complete:

    createevent dup begin
        /Name 1 dict dup begin
            /WUEStatusEvent { % event => -; check if complete yet
                /ClientData get /Completion get .90 ge {
                    AlertApplication
                } if
            } def
        end def
        /Action (/home/project/status/january) def
    end MyEventMgr expressinterest

This results in the AlertApplication procedure being called when the /home/project/status/january report is within 10% of completion.

Puny WOF (Workgroup Object Facility)

The above alerting works only for applications running on the same workstation. This is because the event that is sent is only visible to interests expressed on the same workstation. We can easily extend our model to include sending the event to many network workstations by using the same techniques as the 10-line server:

    -WUE friendly workstations start a WUE event listening service when
     they start up NeWS.  This uses exactly the same techniques as the
     10-line server, but using a different socket file.  They also
     regester themselves with a centralized list of WUE friendly
     workstations.

    -The WUE event listening service starts a second process which
     expresses interest in all local WUE events.  When any WUE
     event is caught, it is "forwarded" to each of the workstations
     listed in the central list.  It does this by opening a socket
     file to each workstation, and sending a small program down
     the socket which sends the WUE event on the remote machine.

    -The Property Sheet sends the WUEStatusEvent exactly as before.
     Local applications running on the same machine operate exactly as
     before.  In addition, however, the local WUE event forwarder
     causes the same event to be sent on each of the regestered
     workstations.  Applications on those machines would now catch the
     forwarded event exactly as if it were local.  The application need
     not be modifed!

This basically implements a Puny WOF (Workgroup Object Facility). And it can be done very easily indeed! Admittedly that this is quite puny and many details about robustness etc. have to be managed. On the other hand, using xnews as a WOF prototyper is extremely appealing. (I plan to prototype a versions of Puny WOF as soon as I get a second host set up and running in my office.)

Multi-Media: NeWS Device Control

Multi-media devices can be managed by NeWS, using programmable events to interface to applications. This provides a logical division between the device "driver", which may be implemented in any of several ways, and the application API to the device, which is via NeWS events.

As an example, consider a graphics tablet input device with an RS232 interface. This device emits x,y data in a well-known format to the serial device when the tablet's stylus moves. As an initial implementation, the driver half of the device was written in PostScript as a process which opens and reads the file /dev/tty. When there is no data on the device, the process blocks, pausing until data arives for the device. When the data arives, the read returns with the device data. This is packaged into an event as in the WUE Alarm example.

Typically the device data needs processing that is better suited to C programming. The solution is to rewrite the device manipulation as a NeWS client using either CPS or the TNT Wire Service. The application interface, however, continues to be the same event interface. The improved performance incurrs no change in the application interface. The notion of this variety of client "daemon" has been used in TNT for providing shared text service among applicaions. A voice interface to EMacs was also made in AD using the same technique.

Another significant advantage to this division of labor into a device layer using an event interface to applications is that it gracefully evolves into sharing the single device among multiple applications. The device is temporarily "owned" by one application, and is given to another application using an agreed upon protocol. Two common styles are used:

    -The keyboard uses a "focus" model where certain UI events not
     associated with the keyboard determine which application owns it.

    -The mouse is typically owned by the application in which it was
     last "clicked".

In the case of the graphics tablet, applications wanting to use the tablet would express interest in the tablet's button being clicked within it. From then on, that application will receive the motion change events for the tablet.

Although device ownership may seem like a trivial problem, fairly complex systems are typically needed to solve it for a given device. The VOX server from Olivetti for voice is used for just this kind of thing: negociation between applications for ownership of the voice device. Because VOX is not integrated into a more general event system, however, it cannot manage the user interface for which application currently owns it. It can only provide the regestry. When OpenLook defines the "focus" model for ownership of the voice device, a NeWS oriented voice service will much more easily integrate into the rest of the system.

Just as WUE Alarms had a network component, certain multi-media devices will be expensive enough to warrent sharing on the network. Scanners and fax machines will be attached to individual machnes, but we may want them to be temporarily owned by other workstations. The same "server" technology used by the 10-line server and the Puny WOF can also be used here.

Summary and Vision

The interesting software architectures of the next decade will leverage network technologies. We will see WUE become the Net Finder, replacing the simplistic Mac Finder in the network intensive workstation world. WUE will manage network resources among WUE-Friendly NetStations, workstations with advanced, easily configured network software platforms. NeWS is such a network tool: a programmable network facility. Another is the newly proposed NFS which uses file server extended PostScript as its client-server language.

We hear far too many NeWS vs. X arguments based on window and UI toolkit arguments alone. These, in my opinion, miss the main strengths of NeWS. It is a programmable network facility which can be used for many purposes. It can prototype new network services. It can be a universal device controler. It can be used to integrate multiple hosts. All these elements also need to be evaluated when considering NeWS.

References

[1] PostScript Language Reference Manual, Adobe Systems, Addison Wesley, 1985

[2] The NeWS Book, Gosling & Rosenthal, Springer-Verlag, 1989

[3] Unix Networking-ch 10: Networking NeWS, Owen Densmore, Hayden Books, 1989

[4] NFS-3 Design Document, Brent Calaghan, Sun internal document, 1990

Appendix A: A more general ps2bits shell script.

    #! /bin/sh
    # Parse cmd line args: ps2bits [-size W H] [-dpi X Y] [-color]
    X=72; Y=72; W=8.5; H=11; Z=1
    while [ ${#} -gt 0 ]; do
        case "${1}" in
            -dpi)   shift; X=${1}; shift; Y=${1} ;;
            -size)  shift; W=${1}; shift; H=${1} ;;
            -color) Z=8 ;;
        esac; shift
    done
    # Run NeWS as Unix filter. Note use of Bourne shell variables!
    xnews "
        (NeWS/pack.ps)      (r) file cvx exec
        (NeWS/basics.ps)    (r) file cvx exec
        (NeWS/redbook.ps)   (r) file cvx exec
        500 dict begin false setautobind () stringwidth pop pop
        $X $W mul $Y $H mul $Z [$X 72 div 0 0 $Y -72 div 0 $H] null buildimage
        setcanvas
        (%stdin) run clippath (%stdout) (w) file writecanvas
    "