Not so about the Linotype. Back in 1980, I personally ran the Alphatype CRS phototypesetter (bought by DEK for the purpose), in the basement of Margaret Jacks Hall, that produced the entire camera-ready copy of The Art Of Computer Programming, Volume II, Second Edition. The DVI files and Computer Modern fonts were created by the early, Sail-language, 36-bit versions of TeX and Metafont that were later redesigned and implemented to be more cross-platform. Knuth rewrote the firmware that resided on the Alphatype (in 8080 assembly language), and I wrote the code that translated from DVI and drove it from the DEC20 mainframe over a serial line (trickier than it sounds; see our joint paper "Optimal prepaging and font caching" ACM TOPLAS Vol 7 Issue 1).
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.
thanks for the pointer, were you one of the two students tasked with writing the program during DEK's stay in China? As you mention the problem of smaller fonts it seems font hinting was an invention of the nineties, how did you solve it?
Nope, that would be Michael Plass (thesis title: "Optimal pagination techniques for automatic typesetting systems," though his line-breaking work is what showed up in TeX) and Frank Liang ("Word Hy-phen-a-tion by Com-put-er"). I wasn't there yet.
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.
Kind of astonishing that they managed to retain the institutional / folk knowledge to be able to create a new vacuum tube product, never mind the machinery and inputs to manufacture them.
There have been multiple companies coming back to try to make small batches of vacuum tubes.
It’s not a mysterious process that depends on arcane knowledge. It does require some tooling and process refinement, but the only real obstacle is getting enough demand to pay off the investment in tooling and process refinement.
It's basically the same process as making an incandescent lightbulb. Which is why vacuum tubes took off in the first place. It's more parts and more metal working, for sure. But really it's shaping and dealing with thin films and a vacuum chamber.
In the 90s China bought the whole Mullard factory and shipped it over from England.
If you buy cheap Chinese valves, you're buying Mullard ones which seem to be made to a higher standard than they ever managed in the 80s. Any two random EL34s out of the box will be a closer match than the crazy expensive "super matched pairs" that we used to buy.
Do you have some more info on this? Background, do they still exist? Where is the factory? I visited one older tube factory in China but it was converted to an art/consumption district.
I did some assembly programming on the Fairchild F8 mentioned in the prequel article. Quaintest feature: Doing a “long” jump (more than 127 bytes away) would cause the accumulator register to be clobbered. Presumably, there was nowhere else to store the high (low?) order address byte routing things around to the PC register. This was also a problem for the debugger (in ROM on the development system), since continuing from a breakpoint necessitated a long jump, so it couldn’t restore the accumulator. So, the debugger would just simulate instructions until it hit a jump, which it could then jump to. Or something like that. Fairchild provided a listing of the source to the debugger / emulator, and the line that simulated messing up the accumulator during single-stepping was commented “The F8 Touch!” It made an impression 50 years ago.
Burbank Airport used to get recognizable celebrities to record the canned public announcements in their own style. I seem to recall Joan Rivers, Henny Youngman, Jerry Seinfeld, etc. It took some of the edge off while you waited around, at least for a bit. Don't know if this continues.
Relatedly, there's a steganographic opportunity to hide info in machine code by using "XOR rax,rax" for a "zero" and "SUB rax,rax" for a "one" in your executable. Shouldn't be too hard to add a compiler feature to allow you to specify the string you want encoded into its output.
You can do better. X86 has both "op [mem], reg" and "op reg, [mem]" variants of most instructions, where "[mem]" can be a register too. So you have two ways to encode "xor eax, eax", differing by which of the operands is in the "possible memory operand" slot, the source or the destination.
This one would be a fun challenge in a ctf, or maybe more appropriate for a puzzle hunt – most people would look at the dissassembly and not at the actual bytes and completely miss the binary encoding
That could be a style metric, too. Time spent reversing MS-DOS viruses in my youth showed me assembler programmers very clearly have styles to their code. It's too weak for definitive attribution but it was interesting to see "rhymes" between, for example, the viruses written by The Dark Avenger.
But they left S, X, and Z rotationally symmetric, so if you choose a non-palindrome vanity plate with only those characters, you can mount it upside-down and fool plate-readers.
Well, ackchyually, the first releases of FrameMaker were created on Sun 3/50 workstations with 4MB of (unexpandable, soldered-in) RAM on a 16Mhz 68020. Most customers had the same model, and could work on modestly-sized documents with ease.
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.)
You are saying that because the word processing and publishing software hasn't moved forward since those days, in fact it has moved backward. You can thank Microsoft's monopoly for this.
