Thank you UNIXcoffee928 for bringing up such an important subject.
Sure, this is one of the really needed features that Atari emulators still do not have...
You're welcome; I had thought about this several years ago, and recently thought about it again, so I decided that I'd bring it up as a topic, so that others could offer their input on what features a program like this should have.
I think that the best way to go about doing it would be to first write a printer driver for a virtual printer. This way, it will work with emulators right away, without having to ask authors to make any changes to any Atari emulators. All you would do is select, say, "emuprinter" from the Atari emulator print dialog box, and the "printed" output of the Atari emulator would go straight to the driver, which, in turn would pass the data to the running printer emulator software application, which could be windowed on the same screen, or, preferably, would occupy a windowed or full-screen secondary display.
This application would display, graphically, what would normally appear on the printed page. It could be selectable to put the info on the screen sequentially, like a terminal, or all at once. If it was displayed all at once, interesting things could be done, that couldn't normally be done on a printer... meaning, it would be like having a new display device that operates with ESC codes.
I can visualize the layout, having drop-down menus that would allow you to select the make and model of printer that you would like to virtually represent. I think that the ability to load a printer-definition datafile (that can be user-created) is an important part of the program, that way anyone can add to it.
It really depends on how you want to look at the type of emulation, though. To truly emulate the actual printers would require a lot of work, including ROM dumps, and emulators of the architecture of the hardware on every printer, and that is simply too much work, and is way beyond anything that I, personally, would attempt. Maybe ROM dumps of the actual character sets, but even that opens up questions of "legal ROM usage", and such. So, I'm thinking at a more Top-Down reverse-engineering would be the way to go. It will get very tricky when it comes to implementing the graphics capabilities of the printers. I am of the opinion that a 9 pin and 24 pin "hypothetical printer" model should be used, and be modified by the datafile, in a subtractive way, to describe the individual printer models. I'm interested in tschak909 Thom's opinion, regarding the details of this post.
I also think that it would be very cool to have a whole separate mode of operation that functioned as a virtual Atari 1020 Plotter. This might be the easiest option to implement, initially.
I'm also thinking that to start out, as a separate mode of operation, something that translated Epson ESC codes into HTML equivalents would be a neat way to build the skeleton of the program, and ensure the functionality of the virtual printer driver with the emulated printer software application. I'm not sure if it eventually should use TrueType fonts as an option or if everything should be built on a dot by dot basis, (I'm leaning toward dot by dot matrices, and a Top-Down, Hypothetical Super-Dot Matrix Virtual Printer modeling scheme, that is subtracted from to achieve each model).
I'm still kind of figuring out the design requirements for the whole thing, & I'm not entirely sure if I, personally, want to commit to this program... it depends on it's complexity, and how long it will take to write it... but I am very interested in spec-ing it out, so that it can be implemented... so for anyone who is reading this, please be sure to share what you would like to see in such a program, and how you think that it should be done. Thanks.