PostScript Language Reference (1999) [pdf]
adobe.com
adobe.com
(I vaguely recall getting both of these Adobe PS books bundled by Sun for NeWS or OpenWindows development, maybe together with the traditional white&green Sun binders and/or the O'Reilly X books.)
I learned enough from the Adobe blue book to do some snazzy printing. (HP PCL for non-PS LaserJets, which I also did, wasn't as cool.) IMHO, PS was a lot of fun, and a good way to be exposed to stack-based programming. (Forth also looks like it'd be fun, but PS had the visual construction aspect.)
Looks like the blue book is available at: http://www-cdf.fnal.gov/offline/PostScript/BLUEBOOK.PDF
For later exploration, JonesForth <https://github.com/phf/forth/tree/master/x86> is excellent exploration of Forth's internals.
There were quite a few Forth stories a month or so ago if want more resources.
https://donhopkins.com/home/archive/forth/forth.ps
Can't find it now but it's not the GREENBK.PDF available in link above, though might peruse that version
Surprisingly though, they came in handy somewhat recently (2017?) when I was tasked with re-writing some legacy publication software. A lot was boilerplate, but buried in the .ps output were some answers that no one could find anywhere else.
Available at site above or via: https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF
Reid is also listed on the title page as the author of the green book.
A language like PostScript would have been a much better foundation for the web than HTML+CSS+JS.
Browser engines would be much simpler. The platform would have had rich design capabilities much earlier and easier. A simple Forth-style language would have been a much better compilation target for high-level app development languages than JS. And having programmability built in from the start would have forced browser developers to think about security models as an integral part of the platform.
At the very least, embedded PostScript should have been supported for scalable graphics from the beginning. We now have this "sort of" available with the HTML <canvas> element, which uses essentially PostScript primitives for drawing with JavaScript. However, this format is not amenable to easy automated processing within the language, because in contrast to PostScript, JavaScript is not a homoiconic language.
A useful compromise between simplicity, security and flexibility could have been Encapsulated PostScript (EPS), a subset of PostScript with certain restrictions.
Also PDFs can embed font glyphs. That doesn't mean they have to. Common fonts like Helvetica are even guaranteed to be available in any PDF viewer.
Of course there are some pdf’s that is so full of multilayered vector graphics that it may take a short while, but goddamn facebook starts up the fans in my laptop, so it is hardly fair comparison.
You would inhibit accessibility, including the transition the web made from desktop to mobile -- e.g. consider how <select> is rendered on a phone. The browser needs semantic knowledge of elements on the page; it can't just be code.
You may also inhibit web crawlers and search engines, which are essential to the popularity of the web. You can't write an infinite loop in HTML, but you can in PostScript.
It's also not clear to me that PostScript can handle responsive layouts better than CSS (and a sibling comment hints at that, e.g. adding JS to do layout). CSS handles this at great cost, but it's also a hard problem.
In other words, it's reasonable for the web to HAVE vector graphics, but it can't BE vector graphics. Just like it has WebAssembly, but it isn't WebAssembly (nor would have that been a good idea from the start).
See his answer to the question "Should web browsers have stuck to being document viewers?" (And the ensuing discussion.)
You have to log in to see the replies to his reply, which includes a discussion about JAM and NeWS and PostScript based browsers and rendering.
https://www.quora.com/Should-web-browsers-have-stuck-to-bein...
>Should web browsers have stuck to being document viewers?
https://twitter.com/kocienda/status/1355344814166876163?s=21
>Alan Kay, Still trying to learn how to think better
>Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
>It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
>It’s both surprisingly and dismayingly difficult to get people — especially computerists — to criticize the web and the web browsers — even more so perhaps today.
>This is despite the glaring fact that the interactive media provided by the web and browsers has always been a hefty and qualitative subset of the media on the very personal computers that run the web browsers.
>[...]
>This led to a “sad realization” that sending a data structure to a server is a terrible idea if the degrees of freedom needed on the sending side are large.
>And eventually, this led to a “happy realization”, that sending a program to a server is a very good idea if the degrees of freedom needed on the sending side are large.
>John Warnock and Martin Newell were experimenting with a simple flexible language that could express arbitrary resolution independent images — called “JAM” (for “John And Martin” — and it was realized that sending JAM programs — i.e. “real objects” to the printer was a much better idea than sending a data structure.
>This is because a universal interpreter can both be quite small and also can have more degrees of freedom than any data structure (that is not a program). The program has to be run in a protected address space in the printer computer, but it can be granted access to a bit-buffer, and whatever it does to it can then be printed out “blindly”.
>This provides a much better match up between a desktop publishing system (which will want to print on any of the printers available, and shouldn’t have to know about their resolutions and other properties), and a printer (which shouldn’t have to know anything about the app that made the document).
>“JAM” eventually became Postscript (but that’s another story).
>Key Point: “sending a program, not a data structure” is a very big idea (and also scales really well if some thought is put into just how the program is set up).
>[...]
(Log in to Quora to see the entire discussion.)
Basically he wants a web consisting purely of "black box" Java Applets rather than of web pages. I think this vision have failed multiple times for obvious reasons.
The object oriented paradigm (with data and behavior encapsulated in black-box objects) works fine for software systems, but it absolutely fails for large decentralized communication systems. TBL understood that and instead based the web on declarative data formats, and eliminated the behavior to a few verbs (GET, POST etc.) with constrained semantics.
OOP is great when appropriate but it seems Kay doesn't recognize the limitations of the paradigm. Even Java have abandoned the strict object-dogmatism and embrace more data-oriented patterns.
Those principles scale. GET/POST is basically the Unix/Plan 9 principle of read() / write() of declarative formats.
On a small scale you can avoid that and use more tightly coupled RPC (and maybe you should), and you can design more elaborate VMs.
On a large scale it all becomes REST (e.g. what do you talk to Github with, what does a Debian repo look like, etc.). It's less about the technical design and more about the social issues -- who owns each end of the wire? If you own both ends of the wire, you have a much different problem, but that's not the problem the web is solving.
Previous comment on this: https://news.ycombinator.com/item?id=6131335
---
Funny thing about objects, I went back to my comment from 8 years ago and also noted that Kay was obsessed with "objects" in a way that's not useful:
https://news.ycombinator.com/item?id=5516960
When watching the Kay talk, I was struck that he seems to be lumping every "good" in software engineering under the term "object oriented". Virtual machines are objects. Servers are objects. Numbers should be objects. All abstraction is objects. It was not really a useful or enlightening way of thinking about the world.
The web is hyperlinked DATA that optionally leads you to CODE. The VM-centric design is mistaken and broken, and it's a moot point because it won't ever be deployed in at a large scale in practice.
Like Kay's other designs, it's OK for a small scale and clean slate, but not for a large scale.
Importantly, the web can have and has had MULTIPLE VMs -- Java (via NSAPI), Flash, JavaScript, WebAssembly, and I would say PDF since all browsers now have readers built-in. The design of languages for code is more difficult and ephemeral than the design of languages for data.
The web scales with TIME (decades), not just users (billions of people). Kay's designs don't scale in either direction.
(Somewhat related comments on the Lindy effect, i.e. what techologies last: https://news.ycombinator.com/item?id=26772565)
https://news.ycombinator.com/item?id=5513147 (2013)
Anyway, as I recall, Kay is making essentially the exact same argument as the Adobe guy, and the way he said it in that talk (Programming and Scaling, thanks below) displays astonishing ignorance for such a brilliant guy.
If Kay is right, then he should just create a web that is based on a VM. And then he can see how far it goes. It will never go anywhere because it will be broken by design.
And I'll elaborate on that and say that Kay's designs are probably brilliant for small scales, but not for large scales and heterogeneous problems.
It's easier to design something for a small scale. You can get a more coherent result that feels nicer locally.
But the whole point of the web is large scale -- WORLD WIDE was in fact TBL's original vision (e.g. see original proposals linked below). That's a much more constrained and thus harder design problem.
Also related:
https://news.ycombinator.com/item?id=10644076 (2015)
https://news.ycombinator.com/item?id=6131335 (2013)
https://news.ycombinator.com/item?id=14035411 (2017)
(I might make a blog post out of this)
TBL knew what he was doing.
PostScript is like PDF, it assumes a canvas of fixed dimensions. This is fine if everyone has screens of the same dimensions or only prints to read on paper (and nobody have bad eyesight). But on the web there is a wide variety of viewport dimensions, so a PDF-like layout would either make text to small or require incessant scrolling back and forth and up and down.
CSS is more complex than PostScript because it tackles a much harder problem.
OK, since PS has an embedded programming language I guess you could program the layout to adapt to different viewport dimensions. This would force you to embed the complexity of CSS/browser layout engine in each page.
Actually, the most important way PostScript is unlike PDF is that it's a Turing complete programming language, which is useful for implementing responsive layout.
>CSS is more complex than PostScript because it tackles a much harder problem.
No, CSS is more complex than PostScript because it was designed by a bickering committee and competing companies over a long period of time, and nailed onto the side on HTML as an afterthought of a shotgun wedding.
>This would force you to embed the complexity of CSS/browser layout engine in each page.
Or implement a shared library or user interface toolkit or browser platform or scriptable Hypercard-like environment that makes it easy to implement responsive layout. See my comments above about The NeWS Toolkit, HyperTIES, HyperLook, PizzaTool, etc.
That is not really an argument, that is just en emotional outpouring. I haven't seen anyone propose a simpler solution which solves the same real-world problems. But you can easily create a simpler solution if you ignore the problems of different device dimensions, accessibility etc.
Anyway, CSS itself is not the issue. Even before CSS, the browsers used a layout model which was adaptive to different viewport dimensions and text scalings. This layout model is formalized in CSS as "normal flow", but the model itself predates the CSS spec. CSS now allows you to override these defaults in various ways so you can create a layout with fixed dimensions. But by default it is adaptive.
In PostScript you need to explicitly write code to make the layout adaptive. If you want it to be as adaptive as HTML is by default, you will end up implementing something of similar complexity to a HTML rendering engine in each page (never mind issues with search engine indexing, accessibility and so on) - or you will bundle an adaptive rending library, in which case we are back to square one - a browser rending engine.
HTML + CSS may be "bad" and "ugly" but have the great advantage that it actually works in the real world. Ugly things that work is always going to beat elegant things that doesn't work.
Just look up the example on this page on the Z-Machine v3 interpreter written from a great hacker and Gopher user I admire.
See the heavily commented PizzaTool source code, which renders a color preview of your pizza in a resizable pizza shaped window (which you can spin) as well as faxing a hires black and white picture of the pizza with your order:
The Story of Sun Microsystems PizzaTool: How I accidentally ordered my first pizza over the internet.
https://donhopkins.medium.com/the-story-of-sun-microsystems-...
PizzaTool PostScript source code:
https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt
PizzaTool demo:
https://www.youtube.com/watch?v=avJnpDKHxPY&ab_channel=DonHo...
(Hmm, the video is stuck on that one, but it used to work. Is youtube broken for me or for everyone?)
https://donhopkins.medium.com/designing-to-facilitate-browsi...
>Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser (1991)
>Abstract
>Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
>an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
>application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
>multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.
>[... here's what the kids these days call "responsive layout", but implemented in the late 1980's for NeWS HyperTIES:]
>Figure 2 shows many HML features that allow authors to create visually appealing pages while maintaining a consistent database format. First, many commands (.style, .size, .para, etc.) control the formatting of text and its position on the screen. Second the HML is a full programming language, allowing the creation of nested blocks, with local variables and macros. Although variables created inside a block are usually local, it is possible to create and make changes to global variables. Blocks are very useful in creating structural formatting, e.g. section headings are tagged, rather than having explicit commands for larger font, boldface, and line spacing. In Figure 2 the macro .indent makes use of blocks to obtain the desired formatting. Blocks together with macros are very useful to create style files, a set of macro definitions that can be used in any article in the database. In Figure 2, chap_name, sec_title and indent could have been defined in a style file. The use of any of them in any article would then guarantee consistency throughout the database.
>Style files guarantee consistency, thereby reducing the burden for authors and browsers. Also thoughtful use of style files could give further cues to lessen disorientation, e.g. major articles would be in larger fonts, while secondary articles might be in smaller fonts.
>[...]
>Each selection of a highlighted link can set a variable. Predicates on these variables can be tested to decide on whether one string or another is displayed. This permits optional text to be suppressed, selection of national languages, Ted Nelson’s “stretch text”, an outliner, and other features. Figure 3 gives an example of conditional text for a software installation manual (in our example, “Magic Paint”). This software package can be installed either on a Macintosh or an IBM PC. It provides for different configurations on each machine, different floppy disk sizes, one or two floppies, and hard disk options. When this storyboard is interpreted, users should already have indicated what configuration they possess, thereby setting the proper variables. Suppose the user has a Macintosh with two floppy drives, then the variables .macintosh and .dual_floppy would be set to true while the other variables would be set to false. This will cause the storyboard interpreter to generate a screen with information relevant to this user’s task.
And NeWS PostScript uses "Magic Dictionaries" that look and feel like dictionaries, but are wrappers around built-in objects implemented in C, like canvases, processes, events, fonts, etc. Sort of like getters and setters that invoke native code. They make it much easier to extend PostScript and implement APIs without adding a lot of operators to the language.
And NeWS had an object oriented programming system called "class.ps", designed by Owen Densmore, that represented objects with dictionaries (and magic dictionaries too, with OpenWindows NeWS 2.0 but not the original NeWS 1.x). We used it to write all kinds of user interface toolkits, widgets, applications, and it worked very well.
See the Pizzatool source code for a well commented example:
https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt
Tom Stambaugh described how Smalltalk inspired Owen Densmore's PostScript object oriented system in NeWS. A point he didn't mention is that PostScript is directly descendent from Interpress, which was developed at Xerox PARC and reincarnated as PostScript at Adobe by Chuck Geschke and John Warnock:
https://en.wikipedia.org/wiki/Interpress
Brian Reid's deep detailed historic dive "PostScript and Interpress: a comparison":
https://tech-insider.org/unix/research/1985/0301.html
I also think PostScript owes a lot to Lisp (it's dynamic, homoiconic, polymorphic, symbolic), even more so than Forth.
http://wiki.c2.com/?ForthPostscriptRelationship
Tom Stambaugh wrote:
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...
It would require some modification to run in other postscript environments, but not much, I think. It was developed after the 1st Edition Postscript manual but before the second, so it's considered a Level 1.5 Postscript environment. It uses dictionaries freely, but the << /Level-2 (syntax) >> had not yet been invented. So it uses a number of nonstandard operators for dictionary construct. These would need to be simulated or the routines rewritten to use Level 2 syntax. -- luserdroog
comp.lang.forth discussion on "Why is Postscript not Forth?":
https://donhopkins.com/home/archive/forth/ps-vs-forth.txt
Forth/PostScript discussion with Mitch Bradley:
https://donhopkins.com/home/archive/forth/forth-postscript.t...
One of the few mistakes I found is on page 700, where the snippet (apparently accidentally copied from the documentation of fill on page 589):
gsave
fill
grestore
gsave
stroke
grestore
Also check out Display Postscript for inspiration:
https://en.wikipedia.org/wiki/Display_PostScript
Rest in peace Charles Geschke, and thank you and your colleagues for PostScript!
It is available on several platforms and can show the graphical output using windowing systems such as X11. Please see the project's documentation for more information, and consider filing an issue if it behaves in unexpected ways.
The IRC channel #ghostscript on Freenode, and the newsgroup comp.lang.postscript are also good resources to learn more about PostScript and to ask questions.
One interesting fact about PostScript fonts is that fonts are encoded in the same language as entire documents! This shows how versatile and general PostScript is. Here is more information about PostScript fonts:
https://en.wikipedia.org/wiki/PostScript_fonts
PostScript defines a set of fonts that must be supported by conforming interpreters, the so called Core Font Set:
I wrote the code that outputs PostScript for a FrameMaker document; plus that which handles automatically generating the index, table of contents, list of figures, etc. Tricky back in the day that each chapter was a separate file, since large books could be too big to fit comfortably in memory all at once.
https://www-cdf.fnal.gov/offline/PostScript/BLUEBOOK.PDF#pag...
https://en.wikipedia.org/wiki/Adobe_FrameMaker
>Sun Microsystems and AT&T were promoting the OPEN LOOK GUI standard to win over Motif, so Sun contracted Frame Technology to implement a version of FrameMaker on their PostScript-based NeWS windowing system. The NeWS version of FrameMaker was successfully released to those customers adopting the OPEN LOOK standards.
We used to call it "PainMaker", because it was "riddled with features".
I used NeWS FrameMaker to write the SimCity and HyperLook manuals. That was using a desktoptop publishing app with a PostScript user interface to write PostScript documents about a PostScript programmable and rendered hypercard-like user interface system used to implement an interactive resizable zoomable multiple view PostScript user interface to a game that lets you print your cities annotated with a PostScript graphics editor on a PostScript printer! (See pages 10-12 of the SimCity manual for a summary of features and screen snapshots.)
https://donhopkins.com/home/HyperLook-SimCity-Manual.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-1-of-6.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-2-of-6.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-3-of-6.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-4-of-6.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-5-of-6.pdf
https://donhopkins.com/home/HyperLook-Manual-Part-6-of-6.pdf
I was asked to prepare employee cards and I found doing thousands of these manually was a waste of time. So I wrote a script in Perl to download employee data from database, write it to file and then merge it with a PostScript program.
The PostScript program would read the list of employees and format cards, 8 cards per A4 page. The names would be automatically scaled in PostScript so that they fit the predefined space nicely and the background would include nice procedurally generated pattern that would otherwise be very difficult to get.
It is fun when your application actually runs on the printer!
This post prompted me to put some of my old math notes up on GitHub [1]. The final chapter on coupled differential equations sends the DE's parameters to the PostScript printer, where my PS code would execute the different equations and directly draw the resulting phase portrait.
My PS code is in that repo's README [1]. The final results are in the notes.pdf file [2]. The best examples are in the last few pages.
[1] https://github.com/stevesimmons/maths132-notes
[2] https://github.com/stevesimmons/maths132-notes/blob/main/not...
http://zzo38computer.org/zmachine/interp/zmachine.ps
Also, Curses!. (curses.r10.z3).
I've been spoiled at university with business-class printers everywhere, but I had trouble recently with a consumer printer that would print out plaintext when I sent postscript to its AppSocket port.
After poking around a bit I noticed ps2pdf supports a "CompressPages" option (https://web.mit.edu/ghostscript/www/Ps2pdf.htm), which might be what you're looking for.
Alternatively you might use something like `qpdf --stream-data=uncompress input.pdf output.pdf`.
qpdf (http://qpdf.sourceforge.net/) seems to be a good recommendation to add to the "mentally index the entire man page to know what it can do" list for anyone interested in PDF in general.
With the shift to PDFs though, it's way harder. Your simplest course to 'remove' data for printing is often drawing a white box on top of it but that but it won't reflow anything. It's more of an append-only format, core editing is possible but annoying, you need to use an actual PDF reader tool for text extraction and parsing rather than a Perl regex, you can't just reorder pages by cutting/pasting around the DSC %%Page: comments, etc.