Hacker News new | past | comments | ask | show | jobs | submit login
PostScript Language Reference (1999) [pdf] (adobe.com)
94 points by DevilMadeMeDoIT 26 days ago | hide | past | favorite | 65 comments

IIRC, for PostScript development, you got two Adobe books -- the "red book" reference, and the "blue book" tutorial and cookbook.

(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

There's also a green book, on program design. Still have all three, mostly because of an inability to throw books away. They were so clear, as software documentation was before everyone created hyperlinked docs.

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.

> a green book

Available at site above or via: https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF

Anyone interested in learning postscript should also consider Glenn Reid's Thinking in PostScript. I think it is a better introduction than the blue book.

Reid is also listed on the title page as the author of the green book.

Glenn Reid's Green Book is to PostScript as Leo Brodie's Thinking Forth is to FORTH! Both classic excellent books on how to think like a native in the language.


I had the same reaction after doing some PostScript last year, I wanted to go learn Forth.

Leo Brodie's book Starting Forth's good tutorial


You're very welcome.

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.

Mitch Bradley (who's a Forth guru who wrote OpenFirmware) wrote a subset of Forth in PostScript:




I get a chuckle out of a URL pathname of "offline". I wonder if everyone who acceses that is causing a tape robot to fire up

Indeed - and believe a green book existed documenting writing a PS printer driver.

Can't find it now but it's not the GREENBK.PDF available in link above, though might peruse that version

Here’s an unpopular opinion:

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.

Actually, the original web browser, WorldWideWeb (circa 92) could display postscript files. As browsers were created for other operating systems, support for all the media that a NeXT could display was lost... NeXT's GUI was unique in that it was built on Display PostScript...

This also tells us that Tim Berners-Lee was familiar with postscript and its power, but still decided to base the hypertext on a SGML-derived declarative document format without embedded rendering instructions.

TBL knew what he was doing.

I don't agree; it violates the principle of least power (Berners-Lee).

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).

I think Alan Kay would disagree with that (and I do too, having written a lot of responsive layout code in PostScript, including a user interface toolkit (The NeWS Toolkit), a hypermedia browser (HyperTIES), and a HyperCard-like PostScript extensible interface builder (HyperLook), and various apps (PizzaTool, SimCity, etc), all that handle window resizing, dynamic responsive layout, and high resolution printing).

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.


>Should web browsers have stuck to being document viewers?


>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.)

I've heard this before, and I responded to it here:

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)

Alan Kay is opposed to the "principle of least power" and instead believes the web should consist of turing-complete "objects" which manage their own rendering.

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.

Then how do you explain the success of JavaScript and WebAssembly in the browser?

Repeating what I said in the original comment: the web should HAVE a VM; it shouldn't BE a VM.

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)

Kays vision is like if we only had JavaScript drawing directly to the screen, and no HTML or any of the other web standards. In such a web we wouldn't have search engines, probably not even links.

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.

Yes exactly; I think of the web as a modest and humble (and thus brilliant) extension of Unix. It adds simple networking and hyperlinks to hierarchical namespaces (and extends hierarchical names as URLs).

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:


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.

I agree completely.

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.

While there is some software capable of using postscript as a serialization format (eg Xcircuit, I'm not sure how it does it but my guess is that the side affect of some of the functions is to create drawing elements) that would be way harder to work with. Think about all the problems Javascript creates, now imagine dealing with them is necessary just to extract the page content. No thank you, I've written simple HTML parsers/DOMs in ~300 LoC and that would be way harder with something turing complete.

Postscript instead of JS, maybe (I wrote some Postscript programs in the 90s). But we would still create pages in HTML because fixed positioning and unpredictable window sizes never mixed well: Java applets, Flash, ActiveX in the past, embedded PDFs today. They had and have their use cases but you don't create a web site with them or it will render very badly for too many of your users.

PostScript can certainly handle resizable windows (or "responsive" rendering as the kids are calling it these days).

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.


PizzaTool PostScript source code:


PizzaTool demo:


(Hmm, the video is stuck on that one, but it used to work. Is youtube broken for me or for everyone?)


>Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser (1991)


>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.

PDF is currently adding JS engine support in some versions of it. PDF is also designed purely for absolute positioning.

PDF had support for JS at least since the late ‘90s as part of the scriptable forms system.

I disagree, I did some Postscript programming, and it was very much oriented around printing documents so I don't think it would be great for a DOM in a browser.

PostScript's native Array/Dictionary data structures are practically identical to JSON and JavaScript's polymorphic Array/Object (or Python's Array/Dict).

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:


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:


Brian Reid's deep detailed historic dive "PostScript and Interpress: a comparison":


I also think PostScript owes a lot to Lisp (it's dynamic, homoiconic, polymorphic, symbolic), even more so than Forth.


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:


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?":


Forth/PostScript discussion with Mitch Bradley:


Wouldn't that be slower? To this day, despite the continued efforts to improve the rendering speed, I hesitate a bit before opening PDF files due to their heaviness. In that alternative universe, would it be possible to optimize PS renderers to be on a par with HTML+CSS+JS renderers? I also guess such "webpages" would require more bandwidth because they need to include every font glyph used.

PDF files can be heavy or light, just like a webpage can be heavy or light. These days most PDF files are machine generated without much care for file size and you get their stereotypical heaviness. If you take a bad webpage generator (such as Word 2003) you get highly complex and redundant markups too.

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.

What, you can go to the 522’s page of a pdf and it will insta-appear. With web technology, you can’t even begin scrolling because layouting happens from top to bottom.

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.

PostScript is not flexible enough for the web.

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.

>PostScript is like PDF, it assumes a canvas of fixed dimensions.

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.

> 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.

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.

PostScript IT'S a programming language, man.

Just look up the example on this page on the Z-Machine v3 interpreter written from a great hacker and Gopher user I admire.

PostScript is an amazing programming language, and this language reference manual is one of the greatest technical documentations I have ever seen, I highly recommend it!

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):

should be replaced by:

PostScript allows very concise and elegant programs, ideal to visualize information in readable and scalable ways.

Also check out Display Postscript for inspiration:


Rest in peace Charles Geschke, and thank you and your colleagues for PostScript!

I remember Sun Solaris workstations where the Display PostScript logo was visible when the X server was starting!

PostScript was one of the first two languages I took up pretty seriously (C being the other one) and helped get me into programming in general. I quickly fell in love with the elegant syntax and intuitive graphical capabilities. Sadly, I found PostScript itself not to be very convenient for general-purpose programming just due to the limited set of primitives available in the standard library, but as a special-purpose language, I got a lot of mileage out of it.

I have a copy of the 2nd edition Red Book PostScript reference manual and the section on Display PostScript always fascinated me, I really wish there was a good way to give it a shot but by the time I really got into it, it was already falling too far behind to remain compatible with anything I could readily get my hands on.

why does the fonts looks weird on ps documents compared to pdf?

Just a guess, but you may have in mind certain PS files generated by TeX/LaTeX from the 80s and 90s, back in the day when both PS-based workflows and raster (bitmap) fonts were more common than they are today. So, although it's not really a limitation of PostScript, for purely historical reasons there may be a correlation among academic documents between PS files and raster fonts, which (because of a lack of hinting) look worse on the screen, at resolutions other than the one they were tuned for. For such documents (try this if you have one of them), there is the amazing pkfix tool by Heiko Oberdiek: I had once written a blog post about this (https://shreevatsa.wordpress.com/2011/05/05/converting-old-p...) but you can read the TeX FAQ (http://www.texfaq.org/FAQ-pkfix) or even Wikipedia (https://en.wikipedia.org/w/index.php?title=Pkfix&oldid=71250...) or see it in action in this answer by the author: https://tex.stackexchange.com/questions/120260/making-low-qu...

This highly depends on the software you use and how you generate PostScript files. To program with PostScript, and to display and print PostScript documents, I highly recommend Ghostscript, a PostScript interpreter:


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:


PostScript defines a set of fonts that must be supported by conforming interpreters, the so called Core Font Set:


Really depends on the file, the font format, and viewing program (if you aren't talking about printing). Printed PS can look fine, and is still used in some industries for essential mail. Viewing programs are usually the poorer cousin of PDF viewers, presumably because PDF is much more easily parsed. PDF files tend to use TrueType fonts more, while PS might be using Type1, but that shouldn't matter much.

Created with FrameMaker, as were many reference and user manuals in the day. The first editions of the PS and related manuals were done with FrameMaker when Frame was a separate company; Adobe liked it so much, they’d bought us by the time of this third edition.

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.

That’s true for the later editions, but the first (1985) editions of the red and blue books were produced using Scribe:


Right; Frame was still beta in 86.

Frame even implemented an OPEN LOOK version of FrameMaker for The NeWS Toolkit in PostScript!


>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.)








I remember writing an application in PS. That was my first job, in IT support, over 20 years ago.

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!

PostScript has something really beautiful to it and I'm still in awe when I "netcat" a .ps file to the local IP address of my good old and trusty HP LaserJet 4M+. Elegance from another era.

Tim Edwards of Open Circuit Design [1] created XCircuit, which allows drawing electrical circuits and the file format is PS. It’s still one of the best programs for publication quality circuit diagrams.

[1] http://opencircuitdesign.com/xcircuit/

I loved Adobe's PostScript documentation. Its all excellent. I gotta admit that I liked PostScript better than Forth. Its definitions and the little differences made it funner. I often think it would be fun to do a version of PostScript as a normal scripting language. It would be fun.

I used to love programming in PostScript, around 25 years ago. I used the red, blue and green books, plus the PS Language Reference.

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...

You can play Zork and any Infocom game with GhostScript:


Also, Curses!. (curses.r10.z3).

How is Postscript support on consumer network printers nowadays?

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.

I liked how, back in the day, when the figures for the papers were in .eps format, I could just change the line-width on the plots by just editing the file. Now they are mostly pdf which is better for the file size, but worse for tinkering, or removing bits from the plots.

I worked in a mail house and really liked the editable nature of PS files that we got. We could run them through data processing and easily add/remove/adjust data. Sometimes the clients would ask us to do it in our monthly work because engaging their internal IT was too much effort, so we simple edited the files in the same way every month automatically before printing.

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.

It's easy to convert from PDF to EPS. Are you saying the PDF conversion step mangles it beyond recognition?

I've just tried out of the interest making a plot in matplotlib, (1) save it to eps and (2) save it to pdf then convert to ps. And the original .eps is pretty readable, but the ps converted from pdf has some kind of "stream" encoding string. I.e. it's not really editable.

I think you're describing stream compression, which appears to be utterly ubiquitous to the point that the knobs to turn it off have either technically bitrotted or faded well below our collective awareness threshold.

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.

I played around with PostScript some time ago, it's actually a very approachable language. I could implement some "turtle graphics" functions and draw some fractals logo-style.

For those who are interested in playing around with printer vulnerabilities[0], a lot of them had been scanned by shodan[1].

[0] - http://hacking-printers.net/wiki/index.php/Main_Page

[1] - https://www.shodan.io/search?query=HP+printer

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact