4,399 karma · joined August 31, 2011
Anyway, we'd been doing morning, noon, and night debugging sessions together for a number of days. On maybe the 3rd morning, I arrived at his office and was speaking with his secretary of many years, Phyllis Winkler, when Knuth came in. He handed her a stack of maybe a dozen or two pages, saying "Here's a paper I wrote; please type it in." When? When did he write it? It's still a mystery to me.
This was true for the original TeX78 written in Sail, as well as the ultimate TeX82 written in Knuth's WEB macro language on top of Pascal (that nowadays typically gets transpiled to C). Other programs did similar stuff; the feature was in the OS way before TeX started.
(Gory detail: Actually, TeX went a little further, to free up all possible address space for the final executable: The version that could initialize various hash tables and hyphenation trie tables could dump (nee serialize) a binary file of the resulting data structures; then a slimmed-down version that didn't have that code would read the binary info back in to recreate the initial data structure state, and that's what you'd SAVE the production executable from.)
For the unix-y versions of TeX, there was effort made to mimic this sort of thing in user-land with "undump", but admirable as it was, it was a hack, I'm told. These days, everything is so fast, it's not clear that this feature would be worth it anyway.
Source: me; I was there.
Metafont users can specify point size, boldness, slant, and whatever other parameters they choose (plus device-specific info like resolution) that can then be used in the simultaneous equations that determine the coordinates of critical points and shapes of pens used to draw the characters. So, for the smaller-font issue, the width of the pen may be a non-linear function of the font point size; ditto for the x-height, etc. In Metafont, it's the responsibility of the font designer / coder to handle it all; there's no automated algorithmic monkeying with the pixels other than what you write. This all becomes much clearer with a perusal of The METAFONTbook.
One point concerning Metafont and Computer Modern (and TeX): A key overall goal of the whole kit and caboodle is that a document written in TeX and using the default fonts would produce exactly the same output on all capable computers and output devices, indefinitely into the future, with the same line breaks, page breaks, character shapes, etc. And in fact TeX files from over half a century ago still produce pixel-perfect results.
This requirement meant that the default fonts had to be portable between printers and typesetters with various resolutions (and other optical filtering attributes). There was simply no other way at the time to accomplish this than using a tool like Metafont to author a home-grown font family like Computer Modern (and even then it was a bit of a hope and a prayer).
And don't even get me started on how 5pt super-super-scripts aren't just 10pt characters scaled down by half, contrary to how post-hot-lead typesetters operated, and not fully addressed commercially until decades later.
But it's not a lot of space for documents of hundreds of pages, so typical customers who were using FrameMaker to write user manuals for their products had to use "book" files to tie together individually edited chapter files. Then, once in a while you'd have to push the "generate" button on the book to get all the page numbers consistent between chapters, all the cross-references updated, and generate the updated Table Of Contents, Index, etc. You're welcome.
But there's a potential degenerate case where Chapter 1 might have a forward reference to Chapter 2 ("see page 209"), but due to some editing in Chapter 2, the referenced material now on page 210. Well, in some fonts, "209" is wider than "210" (since "1" can be skinny). So, during the Generate operation, the reference becomes "see page 210". But there's some tiny chance that this skinnier text changes the including paragraph to have one less line, so there's some tinier chance that Chapter 1 takes one less page, so Chapter 2 starts one page earlier, and now the referenced material is back on page 209. So now we're in a loop.
This was such an unlikely edge case that nobody else noticed that it even existed, much less that it was detected. I didn't bother with a fancy error message; it would just give a little one-word popup: "Degenerate". Years later, mild panic ensues when a customer calls in, irate that the software is calling them a degenerate. (And it wasn't even a real example, just some other bug that triggered it.)
On the other hand, it seems that you are, in fact, correct. Oh, well.