Thank you for creating it! Is there some article or something which talks about the original project or motivation for the DVI format? If DEK implemented it as part of TeX in 1982, what was DVI being used for before that?
(For those unfamiliar, https://en.wikipedia.org/wiki/Device_independent_file_format)
Well, imagine you're an unaccomplished grad student, and you're going to tell Prof. Donald Knuth that he's wrong-headed, that his approach wouldn't scale, and that the right thing to do instead is to have a simple, intermediate format, so that nobody would have to muck around in TeX's internals to get a new output device going. Quite the rush when he gave the go-ahead.
So, the first DVI format was purpose-built for proto-TeX (and underwent a revamp for the final cut, just like everything else). It's really just a slightly compressed form of display-list (move to x,y; put down character c in font f; move; put down a rule; done with page) and nothing to write home about. While it was important in the early days to help us and others to get various devices going, and allow for Tom Rokicki's fabulous(ly important) DVI-to-PostScript program, given the ubiquity of PDF today, it's appropriate that we've come full circle, and PDF output is built into most TeXs that people now use, leaving DVI mostly a historical footnote.
If you are referring to the output of TeX, according to Joris van der Hoeven it is matched and surpassed by TeXmacs
Presumably without the source code, so he RE'd it too? In that case, I'd say he captured the spirit of right-to-repair/read/modify even better than Stallman (who, if I remember correctly, founded his GNU empire entirely on complaining about not getting the source code for, ironically enough, also a printer.)
The key issue was that their firmware insisted on loading proprietary font outline info from the included 5.25" floppy drives, while we needed to be able to have individual characters downloaded dynamically for caching in the machine's 64K (or less?) of RAM, intermixed with the per-line display list info, such that once you started the stepper motor that controlled the horizontal worm-screw that moved the lens over the paper, everything would be ready as it moved along; having to stop and restart a line would inevitably lead to jitter among the characters, as mechanical systems are subject to hysteresis -- you can never get back to exactly where you (thought you) were. I vaguely recall Knuth grousing that the standard firmware couldn't even be proved to be able to handle an arbitrarily complex line of text, and thus his full rewrite.
Ultimately, the output was not completely satisfactory. Tall parenthesis and integral signs are made up of multiple pieces (as that's how TeX and Metafont handle them), and because of the alignment issues mentioned above, plus the fact that the individual pieces were "flashed" onto photographic paper separately, so where they met there was a bit of multi-exposure that lead to some "spread" of the blackness. You can see this if you look closely at integrals in ACP Vol 2, 2nd Ed.; they're a little chubby right along the centerline.
I mention all this as it's yet another case of throwing away a prototype, this time software plus hardware. The Alphatype was replaced by an Autologic APS Micro-5, which didn't use a moving lens, and was generally more digital, and thus had no problem with characters made up from pieces. And no firmware needed replacing, though we did have to run it in a completely unintended mode where each character was sent in run-length format each time it was typeset (meant for occasional one-off logos); this was wildly inefficient and slow, but as the APS used long rolls of photographic paper rather than single large sheets like the Alphatype, it could run unattended for hours to produce many dozen pages at a go. At least Knuth didn't have to rewrite any firmware for it (nor software; I handled it, and avoided telling him how grossly inefficient it was, as I thought it would bother his soul).
(Six bits for each upper-case alphanumeric character means a 6-character directory name neatly fits into a 36-bit word on the DEC PDP-10. And file names were limited to 6 characters for the same reason; extensions were 3 characters, with the remaining 18 bits for file meta-data, I think.)
Though fully documented and available via anonymous FTP on the Arpanet, all of these prototypes were experimental proofs-of-concept and were completely discarded, along with the languages they implemented, with the “real” versions rewritten from scratch by Knuth (each first by hand on legal pads, then typed in and debugged as a whole.)
And you missed one more obscure but instructive example: To get the camera-ready copy for ACP Vol 2, Knuth purchased an Alphatype CRS phototypesetter. And, unhappy with the manufacturer’s firmware, he rewrote the 8080 code that drives the thing. Eight simultaneous levels of interrupts coming from various subsystem: the horizontal and vertical step-motors that you had to accelerate just right, while keeping synchronized with four S100 boards that generated slices of each character in realtime from a proprietary outline format, to be flashed into the lens just as it was passing the right spot on the photo paper. (Four identical boards, since you had to fill the second while the first one did its processing; times two for two characters that might overlap due to kerning). Oh, and you had to handle memory management of the font character data since there wasn’t enough RAM for even one job’s worth (see our joint paper).
Fun times. I did the driver on the mainframe side, so got to be there for the intense debugging sessions that used only the CRS’s 4x4 hex keypad and 12-character dot-matrix display.
Thanks for the DVI shout-out, btw.