LaserWriter seeds
inventingthefuture.ghost.ioTo put the mad profit that Xerox got from laser printers into context: Alan Kay estimated it alone paid off everything that Xerox had invested in PARC, and then a lot, lot more. (I think PARC in the 70s cost less than $10 mil annually.)
I would guess that this was close to (if not the same as) the laser printer that Richard Stallman was so frustrated by that he created the concept of free software¹, just to never have to deal with unfixable bugs again?
It seems to me that moving the processing from the computer to the printer had a reasonable rationale, but has been a huge detriment to us all ever since; printers are notoriously, almost legendarily, mysterious and opaque. The NeXT machines moved the logic back to the computer (since NeXTSTEP had PostScript as part of its operating system), and I think it’s time that we do that as well.
There existed "PostScript printers" that rendered PostScript themselves, and "raster printers" that had the host PC handle it for them. The latter being infamous as "winprinters", because they relied on Windows infrastructure for it, and often lacked the driver support outside Windows because of it.
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.
I think the free software world needs to shift its focus more to freeing all sorts of hardware that isn't computers. As you say there's a reasonable rationale for running some printing code on the printer. The problem isn't that the code runs on the printer, the problem is that the printer is a black box. If it ran Linux and we could get a root shell that'd be a very good starting point for integrating it better with the host system.
Running Linux (or another free software OS) on all your peripherals would be one way to solve it. Another way would be to not have so much CPU power in the peripherals in the first place. I sometimes suspect that the CPU in all our peripherals are present only to take control away from the computer owner; i.e. us. I instead suggest that the computer should have a device driver; that’s it. No computing should take place in peripherals at all. It may sometimes be necessary, but most often not.
I think you are underestimating just how many computing devices have CPUs of some sort in them. For example:
- Optical mice have a processor running an image processing algorithm to detect motion.
- Hard disks have a processor implementing error correction, block remapping, and SMART. SSDs and SD cards are similar.
- Pretty much any USB device has a processor to implement the USB stack - pure hardware implementations exist but are uncommon (and are little more than hard-wired CPUs).
etc, etc. Exposing all of that complexity to the CPU is not useful, and would dramatically increase the scope of software that has to be written to make anything work.
Yes, this. It's good that the mouse, by default, only returns dx/dy/buttons. It's bad that you can't reprogram it easily if you want to and it's bad you can't view the source code of how it works.
I expect reprogramming to require a JTAG board. Easily reprogrammable (via USB) peripherals will be a malware vector really quickly.
Not just that, but also - it's not as though there's a single Optical Mouse Interface which every mouse uses internally. There's probably hundreds of slightly different sensors, all of which work differently - having a single, standard interface to them (USB HID) is a lot better than having to support every single one with its own driver.
(And that's even without getting into the bandwidth issue - the camera on a modern optical mouse captures far more data than it can transfer over USB.)
But that is it's own problem too, do you remember winmodems? They did move it to the host computer and the free software world still complained
The free software world has enough on its plate already, and there are a lot of other higher-priority targets for free firmware - e.g. mobile phones, GPUs, certain NICs, etc.
It's not centralised. Everyone works on the part they find interesting.
Display / imaging as a "big data" problem[0] is turtles all the way down. If we separate "creating something to display" and "displaying something" and call that the "display processor divide" and then ask "what passes across the divide?" in terms of information density then we see that it ebbs and flows.
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
https://news.ycombinator.com/item?id=19874245
DonHopkins on May 10, 2019 | parent | context | favorite | on: Why are 2D vector graphics so much harder than 3D?
Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:
https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us...
>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.
The Definitive History of PostScript
https://github.com/SimHacker/moollm/blob/main/designs/postsc...
>Primary Source: Brian Reid's 1985 "laser-lovers" Post
>This document preserves the definitive first-person account of PostScript's origins, written by Brian Reid on March 2, 1985 — just 11 months after Adobe shipped its first PostScript manual.
>Brian Reid was uniquely positioned to write this history:
>He was there. As a consultant to Xerox PARC during the Interpress design, he worked directly with the principals.
>His thesis advisor was Bob Sproull — one of the three architects of Interpress (with Butler Lampson and John Warnock).
>He saw JAM at Stanford in 1981 — the direct predecessor to both Interpress and PostScript.
>fa.laser-lovers was the Hacker News of 1985 — this wasn't a casual post but a definitive statement to the technical community.
The Adobe philosophy on not implementing page protection would pretty regularly cause some _spectacular_ problems/bugs --- in particular, I can recall one ill-formed .eps file which somehow disabled the new page mechanism and was supposed to re-enable it, and which when placed after a different .eps which had some code which interfered w/ said re-enabling, would cause the document to stop generating new pages, instead overlaying each successive page on top of the previous one.
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...