My retirement project is a PostScript interpreter. I've done about 260 of the 286 operators in the original Apple LaserWriter. I'm about half way through the last tricky bit, Type 1 fonts.
The internals are quite interesting, I always assumed the interpreter just processed the input as it arrives but it actually starts a PostScript program as soon as the printer boots and that controls the hardware and handling incoming jobs. A lot of this code is available through a console, ie:
userdict begin /start load == end
dumps the first program started by the printer.
I have an original LaserWriter which works through the console but doesn't print. Luckily someone has done the work to get the firmware running in MAME.
My interest in this came from working with a QMS distributor in the eighties. At the time I didn't really have a chance to delve that deep into the technology but I was always fascinated by it.
I’ve spent more time in pdf than ps, but they’re close.
Digging into these details is closer to digital archeology than anything else.
The glyphs inside Type3 fonts are themselves PS programs, right? Theres so much interesting history hidden inside the structure (and in some cases you find weird little edges in the codebases that define the behaviour in a way where that’s likely the only place it lives). There’s decades of legacy in how to draw things with computers.
Glad I’m not the only one who still thinks it’s fascinating enough to spend time understanding!
Probably easier to "just" emulate the LaserWriter. The firmware for some of the models is available, the 68K/68020 emulator can be downloaded from somewhere, and the rest is actually documented well enough for some models that writing an emulator is a very realistic prospect.
This brings back memories. In the very early 90s I took a graduate level graphics class and one assignment was to write ray tracer. The professor allowed any programming language in the class, so I used a language that was suited to the assignment. The results had to be printed out to turn in, and color printers were rare, so the assignment was in grey scale.
The postscript image operator in Postscript takes a procedure to return data and it was simple to encode the scene in that procedure. The Postscript image operator scaled the image data between the 500 pixels that image was required to be and the 300 dpi printer resolution and did the grey scale mapping.
The postscript program fit on two pages with comments, many classmates had C or Pascal programs over 20 pages.
The 12 MHz 68000 in the LaserWriter was faster than the 8 MHz in the early Macintoshes or the 4.77 MHz 8086 in the PC clones, so it actually ran faster than many of the other student's ray tracers.
I tried to write (in C) a PostScript byte compiler for a grad school project. It is a very appealing language to work with, with the simplicity of stack machine. And like with this post, I didn't get into the graphical elements that make PostScript useful.
Mainly I learned that Ghostscript is doing a lot to make its PostScript interpreter fast: with the non-graphical test programs I could think up, GhostScript was many times faster interpreting the program (even computationally intensive ones) than my runtime (called "egon") could execute the byte-compiled PostScript. So it was a computation fail but still a pedagogy win.
I've always been meaning to learn more about how Ghostscript is engineered.
My very first professional gig in the mid-80s was on a classified ad-taking application for what were then called penny-savers, physical newspaper-like publications that were nearly 100% classifieds. Penny-savers would be distributed in boxes around urban centres and could be very profitable. Our app ran on MP/M, a multi-user CP/M variant. And when it was time to go to print, our code generated PS directly, there was no "printer driver" or abstraction of any kind.
We sold our customers two Apple LaserWriters each, because if one went down just before going to print they'd be screwed. We would print on both in parallel for speed, but could fall back to just one. And the printed ads? Somebody over in the print shop would cut them out in strips and then paste those strips up to be photographed for the printing press. We didn't have full end-to-end digital yet.
Shameless self-promotion: I wrote a Deflate (gzip with a different header) decomressor in PostScript in the early 2000s. https://github.com/pts/pts-zcat/blob/master/zcattiny.ps . There are more readable versions of it in the same repo.
I worked a ton with PostScript back in the day. A few years ago I implemented an interpreter in Python, including graphics with PyCairo: https://github.com/nedbat/stilted
I used ps / gs quite a bit for a few years as part of work early in my career... 20 years ago. I rather enjoyed it.
I had always hoped I could work more in that area later on... like either writing printer drivers, printer firmware, work at artifex/ghostsript, etc. Unfortunately though, it seems like employers really don't hire for specific skills/domains like that, they just hire generic embedded / software developers and put them to work on postscript or whatever else they have after the fact. Oh well.
Nice page. In 2009, I wrote ('hacked together') a partial PostScript interpreter in C to debug some PostScript code I was writing to reproduce plate 13 from the Eléments de l'art arabe by Jules Bourgoin as reproduced in Arabic Geometrical Pattern & Design.
I do not know why I stopped at that point. Maybe it was because I realized that I should have used another approach to describe the geometric patterns and did not want to refactor all the PostScript I already wrote. But it might also that I got obsessed with another problem.
I still mess with PostScript once in a while. For example I generate little puzzles for my daughter/nephews (words to find in an hexagonal grid, where each hexagon contains one letter): wrote that in Clojure but it generates PostScript (nowadays I could ask a LLM to write the whole thing for me though as the potential for disaster is limited).
Then there's that one utility company who screws up my montly invoice and so, invariably, when I need to do KYC for whatever bullshit-state-surveillance reason (which, invariably, happens all the time), KYC fails for my official address doesn't match the technical address the utility company is using on my invoices.
So the PDF gets converted to PostScript, I edit the PostScript, and convert back to PDF. Nowadays I take it I could also have a LLM do it all for me but the thing is: I don't want my PDF to look like a PDF which has been tempered with (which it definitely has been, but fuck KYC and screw that utility company for not using my proper official address). So I like the PDF to PostScript to edit back to PDF cycle.
I've written more Postscript in the last year than the preceding 20, doing weird specific impositions of variable data printing jobs that InDesign just isn't flexible enough to handle.
This is a yawner, Postscript (the language) is very simple, given run of the mill interpreter machinery. An actual working Postscript implementation is about graphics and font rendering, not the language interpreter. That stuff is still not trivial.
My retirement project is a PostScript interpreter. I've done about 260 of the 286 operators in the original Apple LaserWriter. I'm about half way through the last tricky bit, Type 1 fonts.
The internals are quite interesting, I always assumed the interpreter just processed the input as it arrives but it actually starts a PostScript program as soon as the printer boots and that controls the hardware and handling incoming jobs. A lot of this code is available through a console, ie:
dumps the first program started by the printer.I have an original LaserWriter which works through the console but doesn't print. Luckily someone has done the work to get the firmware running in MAME.
My interest in this came from working with a QMS distributor in the eighties. At the time I didn't really have a chance to delve that deep into the technology but I was always fascinated by it.
I’ve spent more time in pdf than ps, but they’re close.
Digging into these details is closer to digital archeology than anything else.
The glyphs inside Type3 fonts are themselves PS programs, right? Theres so much interesting history hidden inside the structure (and in some cases you find weird little edges in the codebases that define the behaviour in a way where that’s likely the only place it lives). There’s decades of legacy in how to draw things with computers.
Glad I’m not the only one who still thinks it’s fascinating enough to spend time understanding!
Probably easier to "just" emulate the LaserWriter. The firmware for some of the models is available, the 68K/68020 emulator can be downloaded from somewhere, and the rest is actually documented well enough for some models that writing an emulator is a very realistic prospect.
This brings back memories. In the very early 90s I took a graduate level graphics class and one assignment was to write ray tracer. The professor allowed any programming language in the class, so I used a language that was suited to the assignment. The results had to be printed out to turn in, and color printers were rare, so the assignment was in grey scale.
The postscript image operator in Postscript takes a procedure to return data and it was simple to encode the scene in that procedure. The Postscript image operator scaled the image data between the 500 pixels that image was required to be and the 300 dpi printer resolution and did the grey scale mapping.
The postscript program fit on two pages with comments, many classmates had C or Pascal programs over 20 pages.
The 12 MHz 68000 in the LaserWriter was faster than the 8 MHz in the early Macintoshes or the 4.77 MHz 8086 in the PC clones, so it actually ran faster than many of the other student's ray tracers.
I tried to write (in C) a PostScript byte compiler for a grad school project. It is a very appealing language to work with, with the simplicity of stack machine. And like with this post, I didn't get into the graphical elements that make PostScript useful.
Mainly I learned that Ghostscript is doing a lot to make its PostScript interpreter fast: with the non-graphical test programs I could think up, GhostScript was many times faster interpreting the program (even computationally intensive ones) than my runtime (called "egon") could execute the byte-compiled PostScript. So it was a computation fail but still a pedagogy win.
I've always been meaning to learn more about how Ghostscript is engineered.
My very first professional gig in the mid-80s was on a classified ad-taking application for what were then called penny-savers, physical newspaper-like publications that were nearly 100% classifieds. Penny-savers would be distributed in boxes around urban centres and could be very profitable. Our app ran on MP/M, a multi-user CP/M variant. And when it was time to go to print, our code generated PS directly, there was no "printer driver" or abstraction of any kind.
We sold our customers two Apple LaserWriters each, because if one went down just before going to print they'd be screwed. We would print on both in parallel for speed, but could fall back to just one. And the printed ads? Somebody over in the print shop would cut them out in strips and then paste those strips up to be photographed for the printing press. We didn't have full end-to-end digital yet.
PS wasn't easy, but it was very grokkable.
Shameless self-promotion: I wrote a Deflate (gzip with a different header) decomressor in PostScript in the early 2000s. https://github.com/pts/pts-zcat/blob/master/zcattiny.ps . There are more readable versions of it in the same repo.
Impressive will be an understatement. Was it for fun or actually needed it?
I worked a ton with PostScript back in the day. A few years ago I implemented an interpreter in Python, including graphics with PyCairo: https://github.com/nedbat/stilted
It was a really good vacation-week project! :)
I used ps / gs quite a bit for a few years as part of work early in my career... 20 years ago. I rather enjoyed it.
I had always hoped I could work more in that area later on... like either writing printer drivers, printer firmware, work at artifex/ghostsript, etc. Unfortunately though, it seems like employers really don't hire for specific skills/domains like that, they just hire generic embedded / software developers and put them to work on postscript or whatever else they have after the fact. Oh well.
Nice page. In 2009, I wrote ('hacked together') a partial PostScript interpreter in C to debug some PostScript code I was writing to reproduce plate 13 from the Eléments de l'art arabe by Jules Bourgoin as reproduced in Arabic Geometrical Pattern & Design.
Program: https://www.iwriteiam.nl/PostScript_c.txt
PostScript file with first 31 plates: https://www.iwriteiam.nl/Bourgoin.ps
I do not know why I stopped at that point. Maybe it was because I realized that I should have used another approach to describe the geometric patterns and did not want to refactor all the PostScript I already wrote. But it might also that I got obsessed with another problem.
Writing a tiny interpreter is one of those exercises that teaches you more about programming languages than months of just using them
I still mess with PostScript once in a while. For example I generate little puzzles for my daughter/nephews (words to find in an hexagonal grid, where each hexagon contains one letter): wrote that in Clojure but it generates PostScript (nowadays I could ask a LLM to write the whole thing for me though as the potential for disaster is limited).
Then there's that one utility company who screws up my montly invoice and so, invariably, when I need to do KYC for whatever bullshit-state-surveillance reason (which, invariably, happens all the time), KYC fails for my official address doesn't match the technical address the utility company is using on my invoices.
So the PDF gets converted to PostScript, I edit the PostScript, and convert back to PDF. Nowadays I take it I could also have a LLM do it all for me but the thing is: I don't want my PDF to look like a PDF which has been tempered with (which it definitely has been, but fuck KYC and screw that utility company for not using my proper official address). So I like the PDF to PostScript to edit back to PDF cycle.
I've written more Postscript in the last year than the preceding 20, doing weird specific impositions of variable data printing jobs that InDesign just isn't flexible enough to handle.
It's been a joy to dust off those skills!
This is a yawner, Postscript (the language) is very simple, given run of the mill interpreter machinery. An actual working Postscript implementation is about graphics and font rendering, not the language interpreter. That stuff is still not trivial.
the amount of care to detail in the base language is great though. reading PLRM is a joy
Yet, it's going to be novel fun for some people. Let's celebrate today's lucky 10000. https://xkcd.com/1053/