Re: Formatter -> Reclocker?
Not in this case, since it wasn't actually in circuit. But I worked at a place once with a similar setup.
There was an imagesetter , brand long forgotten, which got its input via a parallel port. Sitting on top of it, and electrically between it and the Xenix server that hosted its queue, was an A/B switch with nothing connected to its "B" input. Why? It turns out the switch wasn't just a passive switch; it was also a print buffer. We didn't need that either, since there was a spooler upstream, so again, why? Well, we were using the thing off label. The cable run was longer than parallel was really designed to support, and unlike the imagesetter itself, that cheapo buffer's input port was robust enough to get a reliable signal off the wire(s).
Speaking of decoys, though...
We later (mid-90s) replaced that imagesetter with a new one from AGFA. This thing cost, if I recall, in the $30-50K range (which, for imagesetters, was pretty low-end, but for a smallish company it was a major purchase). The AGFA consisted of two units: the imagesetter itself and the "raster image processor" (RIP) -- the computer that contained the PostScript interpreter. (So basically, the "formatter" that the article's Calcomp box-under-the-floor was reputed to be but probably wasn't.) The RIP was a big, impressive-looking unit, as befits a device with such a price tag, which sat on the floor (as it was meant to), beside the imagesetter proper. Picture a tower computer case on steroids -- very roughly HxWxD = 3ft x 1ft x 2ft.
Well, one day the AGFA tech was in doing some work on the RIP, and so I saw it open. Inside that case was (a) a lot of empty air and (b) a bog-standard (for the day) "landscape-format" desktop PC case -- sheet metal and everything -- mounted sideways. You could have fit two of them in there, with room to spare
The big, floor-space-consuming RIP enclosure was all for show.
 Imagesetters were output devices formerly(?) used in publishing. They did the same basic job as black-and-white laser printers -- turned PostScript into a printed page -- but produced output of far higher quality. Resolution, contrast, position and size accuracy -- all things you need when the device's output is ultimately destined for a printing press, but that laser printers are merely OK at. An imagesetter had a raster-scanning laser, but used it to directly expose photographic film/paper, which you would then carry over to yet a third unit (big, noisy, smelly) to develop it.
 History lesson: back in the day, desktop machines often weren't networked, and their O/Ses didn't have built-in print-queue functionality. (I'm thinking specifically of MS-DOS here. I don't recall about MacOS Classic and early Windows versions.) That meant your computer talked directly to your printer -- synchronously. Your application fed data to the printer at the speed the printer wanted it (which could be painfully slow -- tens of characters per second for a low-end dot-matrix), and since there wasn't (reasonable) multitasking, that meant your computer was basically unusable until the print job completed. The buffer box was intended to solve that problem by gulping the print data from the computer all at once, then dribbling it out at the printer's speed -- along with, of course, letting you share one printer between two computers.