Inventing PostScript, the tech that took the pain out of printing (1988)(spectrum.ieee.org) |
Inventing PostScript, the tech that took the pain out of printing (1988)(spectrum.ieee.org) |
I love the PostScript language and still play with the PostScript interpreter every now and then. Often if I need to plot something, it's fun to try to write the code in raw PostScript.
It's a shame "nobody" cares about printing anymore. In the late 80s as soon as I was able to afford a 300 dpi laser printer, I ran down to the store and plunked down $2500 or so for an HP LaserWriter. I used it with TeX (this was before Adobe) and thought I was witnessing a revolution! A real, powerful, printing press in my home! I'm old enough to have leaned how to set letterpress type in high school shop class....
You were. They were heady times indeed. My girlfriend at the time was a typesetter and did a lot of freelance using Ventura Publisher (on a 286 w/ 4MB!)
Quark XPress, Pagemaker, FrameMaker, Ventura... ahh the good old days ;-).
I ordered the Addison Wesley documentation. I figured out that sending a text file to the printer which started with "%!PS" would make the rest be processed as PostScript. Suddenly I could code vector graphics programs and send them to the LaserWriter and get beautiful prints. I was reading Douglas Hofstadter's Metamagical Themas, and my memory is that there were some great ideas for graphics in that.
The good news: I got a chance to program in a well thought-out interpreted language (a wonder, coming from the world of BASIC, Fortran, C or even Pascal). I got to produce wonderful and intricate graphics output. Reading the IEEE article makes me grateful that the Adobe designers "put functionality over speed".
The bad news: The most interesting output could still take minutes (or more) to run. Of course, this was confusing (or annoying) if someone else in the lab wanted, say, to print their term paper then run off to class. I'd like to think that I learned to run my print jobs at odd hours, and in the worst case, to power cycle the printer and lose my print, to make the device available to the room.
I don't get what you mean: most people I know, when they print something, expect it to be of some quality. Sure maybe the typesetting isn't great, but the actual ppi (I think that's the term), they definitely care for.
I would say you did witness a revolution! But let's remember what came before it, and for most consumers, even the earliest technologies "did the job". Anything beyond "does the job" is gravy, and will likely not be recognized unless you begin to commercialize your work, where people expect beyond "did the job".
I remember using dot matrix printers. The ink looks faded and uneven, there are often patches of missing ink. Consumer dot matrix printers from the 1980s and 1990s mostly just plain suck, and we knew it.
Laser printers really were a big part of the desktop publishing revolution. We take it for granted today, but that's because the revolution is over, desktop publishing won, and manual typesetting / layout is now extremely niche.
A limitation on the graph side of things was the requirement that any so-called "path" (to be drawn as a line or filled as a polygon) could hold at most 1500 elements. This limit was exceeded in a lot of work.
If the task was just to draw the line, the solution was simple: chop the path up into subpaths and draw each. (The transition point would be ugly due to line-ending issues, but the problem would be difficult to see on visual inspection).
This chopping method wasn't useful for polygons, though. So I came up with a scheme in which I examined each point with respect to it's two neighbours. If the point was within some distance of a line segment connecting the neighbours, then I omitted it. If the first pass got the number of points under 1500, I'd render them. Otherwise, I repeated the procedure, with wider tolerances. This was done in C, so it was not really too time-consuming. And it worked. The software is still in use today, many decades later.
I also think that Illustrator 88 was a great improvement on its successors.
was .. huh?
I spent a lot of time researching PostScript interpreter security, and ended up finding a bunch of really interesting bugs. There are of course the regular memory corruption, type confusion, etc, bugs, but PostScript has it's own security model that's intended to stop documents you're printing from interfering with the runtime environment or using internal operators. Those bugs can be fascinating!
The TL;DR summary is that PostScript functions are basically just arrays, so to stop documents you're printing from peeking inside and altering system routines, there is a security boundary called "executeonly". The intention is to allow documents to to call routines that might do something powerful on their behalf - e.g. open a printer specification, or run `lpr` or whatever - but not let them open any file or run any command they want.
If you could interfere with them, you can break that expectation and get access to root-equivalent operators that let you do whatever you want. Turns out, that's really hard to get right - often you can trick them into faulting and then crawl through the error state to find references to their internals you're not supposed to have!
Exploiting these bugs requires some really weird PostScript, here are fun examples:
https://www.openwall.com/lists/oss-security/2019/01/23/5 https://bugs.chromium.org/p/project-zero/issues/detail?id=16...
I found about a dozen bugs like these while working on it, fun times.
You could usually exitserver with a default password, then set global state to do annoying things. Imagine every print job being rotated five degrees, or having a weird dead spot somewhere on the page.
I really enjoyed writing postscript. Fun language
* https://en.wikipedia.org/wiki/PostScript_Printer_Description
Sort of like 'OS-neutral printer drivers'.
To get around that you would write a driver that produced output that could be ingested by as many printers as possible. That intermediate output could be an image in theory, but a 300 dpi page image, especially for a whole document, was enormous at the time, far too big to fit in the memory of most computers or even fit on disc even with compression.
A language makes for a very compact, flexible and efficient intermediate format. Back in the 90s I set up a Linux box at work as a print sever, running the Ghostscript open source postscript interpreter, to print to various printers that didn’t natively support postscript. That was my first use of Linux.
A plotter doesn't need rasterization.
If you're printing colour offset then the halftone grid would probably use a different rasterization to the one that you want to use for an inkjet or dot-matrix.
"Rasterization" if needed at all probably needs intimate knowledge of the printing hardware.
> This article was first published as "‘PostScript’ prints anything: a case history." It appeared in the May 1988 issue of IEEE Spectrum. […] The diagrams and photographs appeared in the original print version.
So the article is from 1988, except for the update at the bottom:
> Update April 2022: While most home and office printers rely on other page description languages these days, PostScript remains the choice of graphics artists and commercial printers for its ability to accurately produce complex images. And the ubiquitous Portable Document Format (PDF) is based on PostScript.
Postscript is probably the most unusual language I ever worked with (APL comes close) but I enjoyed working with it.
* I've heard of people writing programs in PostScript to take advantage of printers' fast vector processors instead of running them on (at the time) comparatively slower PC CPUs, a bit like the early days of GPGPU.
Oh, and you can run Zmachine V3 games on an interpreter written in PostScript.
Next is fixing the printers.
And then, the users. Ugh.
Adobe bought another company called "Frame" recently: frame.io
But in the meetings between the engineering teams, we Frame folks couldn't understand how InDesign's planned extensibility scheme could possibly provide for our feature set; while the InDesign folks didn't seem to grasp what we were even talking about, having never dealt with the kind of features our sorts of customer required (which was understandable, given that they were in nose-to-the-grindstone mode for getting their stuff out the door in the much delayed, and wildly more pressing, effort to compete with Quark Express).
Thus, it wasn't surprising that when Adobe management gave a heads-up to some Fortune-500 (and US Government) customers that they'd be canceling the whole Frame product in deference to InDesign, they were met with some powerful push-back. After all, you can't do the bookshelf-sized technical documentation set for a Boing 767 in a product designed to handle advertising brochures and NYT best-sellers. Bowing to customer pressure, Adobe petulantly reversed their decision, and off-shored development. Indeed, the FrameMaker product lives on until today, and as far as I'm aware, InDesign still doesn't supersede it, even a few decades later (not that it particularly ought to).
So, given that Frame Technology was a public company listed on the NASDAQ, and that Adobe bought it for a modest premium over the going market price, and that the price-to-sales ratio was an unremarkable 5 or so, what's your perspective on how Adobe didn't get a reasonable deal? Seems to me that they just failed to understand the new customer base that they hadn't previously served, and subsequently botched it.
Especially with the subsequent 'renaissance' of the Mac in recent years.
The windows machines? Expect to have to reinstall or reconfigure 6 monthly, and not just for HP.
Due to HP’s war on third-party ink and toner, I just can’t recommend them.