LaserWriter seeds

Nowadays, any device that wants to send a print job has more than enough juice to just render whatever the fuck it wants. Modern connectivity trivializes bitmap transfer. And modern printer standards support things like "this engine wants 1b B/W rasters at 1200 dpi". Dealing with PostScript is very much a choice nowadays.

Suppose I say "print a line". Some program creates a line to my specifications, a driver[1] converts that into something to be shipped across the display processor divide, the display device (printer, monitor, [2]) runs the program.... oops, excuse me "print job". Sometimes the instruction granularity is something like "print a line", other times it's a bitmap, sometimes it's some of both ("print dot at"). Once upon a time "vector displays" expected "dot at" semantics, and "raster displays" did lines and fills; bear in mind, this was mostly done in hardware.

An 8.5 x 11 inch piece of paper at 300dpi is 8415000 bits (33,660,000 at 600 dpi); at 30 frames a second it's 252,450,000. That's black and white. If you do 256 color, then 2Gbps. You (still) might need to throw hardware at that problem. Or throw software at the problem (compress it) so you can get by with the existing hardware. One final note: you won't be able to save that 250MB file and later print it out on something which doesn't exactly match the shape and density of the original device[3].

On the other hand an intermediate representation, like scalable vector graphics, or Postscript, allows different devices to be targeted but the ownership of that final conversion and where it should live depends. It depends on the "big data" nature of the problem in terms of what the final device is capable of (is it capable of running a Postscript interpreter), and who wants to pay to license the Postscript interpreter (don't forget about that!); and don't forget about firmware / driver updates. By the way, the intermediate representation is likely smaller; you can always compress that to feel good about yourself.

The opacity is because the shear forces require everybody writing for one of these interfaces to take at interface value that what the other side sends / expects is blessed by the standards gods. Everybody feels like a Christian Scientist with appendicitis.

I think you've got this backwards, you state "...moving the processing from the computer to the printer had a reasonable rationale" as fact, but what I've observed over the past 40 years has been a tendency to favor sending bitmaps across the divide, even when the display device (printer specifically, I'm talking about buying printers at Office Depot here) supports a higher level of abstraction. I am more than pleasantly surprised that my Canon G3270 is supported on reasonably modern SuSE Linux with a PPD (for printing, haven't bothered with the scanner).

Mental exercise: suppose you had enough printers to dedicate one per pixel. Would you decompose the job and send every printer individualized instructions, or would you send the printer a program to allow it to pick its designated pixel out of the broadcast plan?

[0] Big Data: when it gets too expensive to keep scaling what you're doing in a presumably integrated fashion, so you optimize by smacking the problem upside the head with dedicated hardware for one or more aspects and pave over the problems with software. [1] or... a compiler. [2] drone swarm? [3] emulating turtles

One of the longest days of my life was generating a press-ready PDF using a beta of a then-new program called "pdftex" which would validate for the "Thomson Techno Task Force"'s standard... tried _every_ possible combination of printer drivers, PDF applications, and settings to learn that Adobe Acrobat would _not_ work, but Adobe Acrobat Reader would, that the printer driver had to be Apple's LaserWriter 8.6 (not the Adobe driver or some other LW version), and that the .ps file had to be PS Level 2 (not 3), but that "Generate Level 3 Page Semantics" had to be checked on.... over a quarter of a century since and that memory is still seared in my otherwise uncertain organic memory.

Naturally, this is all interwoven w/ the early history of the Macintosh and LaserWriter --- a couple of relevant stories on folklore.org

- https://www.folklore.org/Origins_of_Spline-Based_and_Anti-Al...

- https://www.folklore.org/The_End_Of_An_Era.html

It's also notable that Display PostScript was largely developed by folks at NeXT such as Mike Paquette.

Anyone who is interested in PostScript should definitely get "The Green Book" by Glenn Reid (_PostScript Language Program Design_) as well as his wonderful _Thinking in PostScript_.

That said, my wife's aunt oversaw one of the largest Xerox Alto/Star networks in the U.S. Government, and when we would chat, her stories would all be about how well things worked and how easy it was to manage (aside from getting funding), while mine were all stories about fixing weird problems...