I worked at Adobe in the early days; my first job was embedding PostScript into various manufacturer's printers.
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 ;-).
It was hard to understand from the inside, too. The programming staff for the Mac port of FrameMaker was two guys, plus their manager who also contributed code. To be fair, it also needed separate testing, slightly modified manuals, box, and media, but still…
I was there, too, from a few months after the founding of Frame, to a year after the acquisition by Adobe nine years later. From the Frame side, it seemed like Adobe figured they were doing a kind of mix of an acqui-hire and putting a place-holder on the FrameMaker customer base, with the notion that in short order they'd be able to move them all over to InDesign by just adding a couple of features (kind of like they managed to do with the PageMaker acquisition).
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.
My high school had a computer lab with a networked LaserWriter (this might have been 1987). It outclassed any screen in the room, so far as display resolution. And with its 68000 processor and PostScript interpreter, it was the fastest and most capable graphics machine I'd ever seen. Indeed, a 300dpi laser printer driven by PostScript was a wonder.
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 have to ask: did you truly print some beautiful typeset piece?
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'd have to disagree with "anything beyond 'does the job' is gravy", because people use these printers for different jobs and some people definitely do care about the quality. Good quality printing is easier to read; the images and diagrams are clearer and easier to understand; etc.
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.
I remember clearly how postscript changed things for scientific work. Of course, it improved upon the daisy printers that we used for text. But the same language could also draw graphs, so it was a sort of all-in-one solution.
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'm glad Warnock and Geschke didn't already have the ideas of the modern Adobe in their heads. If they had, the LaserWriter would have required a monthly cloud subscription, and if the customer cancelled, both the printer and everything they had already printed would vanish.
I also think that Illustrator 88 was a great improvement on its successors.
I stole a line from C.A.R. Hoare: `[Algol 60 was] a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.'
Funny, I think I might be one of the worlds foremost experts on PostScript security :)
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:
I worked on postscript drivers for a few years. Escaping the sandbox was a feature!
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.
Watching a LaserWriter print from a Mac for the first time after being used to dot matrix printers was mind blowing. Such a huge leap forward in print quality and speed.
I am still confused why one needs to produce a document as "program" as opposed to set of pixel to be printed. If we know the page size in advance (which we do while pressing the print button), I would expect document program rasterizes it and so "print anything" can be achieved pretty simply. Why they needed to invent a new programming language called postscript?
This is basically how a dedicated device driver for a particular printer works, but back then many operating systems like DOS didn’t have a standardised device driver architecture. Each application like Lotus 123 or Word Perfect would need its own driver for each printer.
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.
Because in the good old days you expected to share an expensive page printer with many, and it made sense to put a powerful embedded computer (for the time) to do rasterizing within it. It could save on bandwidth, RAM, and storage. The RAM requirements for rasterizing a page would be quite costly at the time.
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.
Part of the point was that it was device independent, and simple rasterization wasn’t practical for printing on both low end office printers and the highest end commercial printing imagesetters.
I regularily have to print some specific pdf files that fail to print on my Epson printer. The workaround I found was to rasterize them with ImageMagick, because then they print. But so slow.... It is not an efficient approach.
> 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.
I wrote a postscript library in late 1988 for our application. Learning Postscript enough to support everything our app could generate (charts) involved boxes and boxes of paper, since the only way to debug anything was to print debugging info on paper. Sometimes the bugs made nothing print, which was hard to figure out! Still it was a fun language, and I could learn a lot by looking at Illustrator's file format (which was basically Postscript, and I think eventually became PDF). I was even able to export everything we drew into Illustrator format, which was a popular feature.
Postscript is probably the most unusual language I ever worked with (APL comes close) but I enjoyed working with it.
PDF is just as good in the sense of being able to represent the documents people want to (arguably better, if only for transparency, compression (including JPEG), and (usually!) the ability to search for and select text). PDF does have many other additional features that people disagree on the value of, many of which are not supported by most PDF viewers. Being a full programming language, PostScript is technically much more powerful in many ways, but it turns out that's no longer very useful for most purposes (computers are much more powerful*, storage is cheap, networks are fast, most documents are viewed on screen, etc.).
* 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.
PDF/X is just a PDF with interactivity/JavaScript/forms removed and the layout instructions rationalized and colorspace for RIP fir commercial printers
Hate to be negative, but this new site design of IEEE Spectrum is just abhorrent. It's ad-ridden and there's an infinite scrolling thing. I use reader mode, but I miss the old design. Sigh
HP had been my go-to printers for the time I was still printing, maybe for a decade and a half starting around 2000. They "just work" on Linux systems with no driver downloads or other nonsense, including advanced non-printing features such as scanning. I'll admit that the build quality went down with every printer purchased, but that was an acceptable tradeoff for just plugging it in and getting to work. Not to mention that HP aftermarket ink is readily available and relatively affordable, especially if you simply refill the cartridges yourself (literally three minute job).
On that topic, I accidentally just bought b/w toner for 18k pages for 70 € yesterday (I thought it was for 6k pages). https://www.ebay.de/itm/194967229480
I bought third-party toner that came with a faulty chip, transplanted an original brother chip to it, and used the reset menu (open the printer to gain toner access, hold ← and X for 2 seconds, press ←, select which toner chip to reset as if it was full) and now it's working fine :)
To be a little fairer to HP, windows printing is an abomination. I have two HP printers that I did nothing to enable printing on the linux installations, they appear automatically and work out of the box.
The windows machines? Expect to have to reinstall or reconfigure 6 monthly, and not just for HP.
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....