Re: KISS
Wordstar was like most of the wordprocessors of the time, and relied on the font support in the printer itself.
To do this, there were internal device independent markers embedded in the document that selected various things like superscript, subscript, bold, underline, strikethrough and different fonts.
To implement these for a particular printer, you had a driver file that you typically loaded as part of your wordprocessor profile, typically at startup.
These driver files contained things like the escape sequences to turn on and turn off each of the features, together with a description of the fonts. For most dot-matrix fonts of the FX-80 era, printers only had fixed-width fonts so the driver only really needed to know the character width and line spacing, but contemporary daisy-wheel printers could have proportional fonts loaded. For these, the print driver also had to know the full font-metrics for the font wheel installed, so these would also be in the driver (Incidentally, nroff on UNIX, which was normally used to drive fixed-width only printers, could also drive printers with proportional fonts, not that many people used it for those).
Printers later than the FX-80 (such as the LQ-80) started adding proportionally spaced fonts, but again, the software worked within the capabilities of the printers, just turning things on and off by escape codes, although like daisy-wheel printers, the metrics for the full font would have to be included.
There were very early attempts to render a page in the computer itself, and transfer the page as a bitmap image using the printer's graphics capability. This started in very early desk-top publishing programs, but I don't know exactly when the main-stream wordprocessing packages started using these types of capabilities. When using a printer like this, there had to be a rendering engine in either the OS or the package itself. This appeared to have been incorporated into the OS in early versions of Windows with GDI in Windows 3.1. It was only when this started happening that the OS needed to know much more about fonts than their metrics.
UNIX printing pre-CUPS was a very hit and miss affair. The software (for example Troff) needed to be able to drive the printers capabilities, making the OS print system mainly a pass-through. With the advent of PostScript things became a bit easier, but the rendering was often still done in the printer (although Postscript does allow embedding fonts into a print if they were not one of the standard fonts that PostScript printers shipped with).
Just prior to CUPS, people started putting together rendering systems using GhostScript (an open source PostScript implementation) to render the image before sending it to a printer using print filters in the System V style print system (a strange beast I'm happy to forget as much as possible). This allowed different types of printer to print graphics-rich pages, and all the application had to do was generate PostScript. This happened around the time of ink-jet printers (I played with it on early Redhat systems and Epson Stylus 400 printers). This became formalised when CUPS was release into the open, and this uses either GhostPrint or GutenPrint (Formally Gnomeprint) to render the page (and now, CUPS is transitioning to prefer IPP in the printers, strangely circular as PDF is an evolution of EPS, or PostScript, moving much of the rendering back into the printer!).
With all of these client side rendering systems, there needs to be font handling in the client computer. The tools for handling scalable fonts is as vulnerable to code problems as anything else.
But getting back to the point, configuring Wordstar for an FX-80 (although why you would need to, because it was one of the standard printers that everything shipped a driver for) is as much like driving a modern priner as an ox-cart is to a Bugatti Veyron.