From emails with Nick (@sicklittlemonkey), Aug 2017:

...after the discussion about printing a while back I became embarrassed about the limited output from AppleWin.

So after a bit of messing around (often with a 2-year-old on my knee) I've got the attached AppleWriter command-line prototype working. It's built with VS 2017. I considered using a PDF library, but they are quite large and complicated, so decided to stick with GDI printing for now, since it's easy to print to PDF. The printer side and output side can easily be extended or replaced, so an Epson FX-80 emulation could be written to use the same output class, or PDF or HTML (etc) output classes could be written.

Just run from the command line passing one of the attached "raw" filenames, and choose Windows' PDF or XPS printer. It's very rudimentary for now, only emulating just enough for these simple examples, but more features can easily be added further down the road as samples become available.

Still better than the current "anything you like, as long as it's text-only!" There's still a bit more to tidy up in the code structure, and then I'll hand it over if you want it. Will be trivial to integrate.

Ok, well for such a small project it's taken a long time, still has a lot of holes and TODOs, but ... it basically works.

Attached is the "Ancient Printer Emulator" program, which uses the "Ancient Printer Emulation Library" (APEL, heh) which supports the simplest features of only one Printer (the AppleWriter) and two Writers (Text File and GDI Printer). Also included are some sample raw print streams and renderings of those samples using one or both of the two writers.

And "trivial to integrate" sound right up my street!

Well, it's as simple to use as:
AncientPrinterEmulationLibrary::TextFileWriter output(output_file);
or
AncientPrinterEmulationLibrary::GdiPrinterWriter output("AppleWin Printer", "Courier New");

Then:
AncientPrinterEmulationLibrary::AppleWriterPrinter printer(output);
while (input_file.get(c))
printer.Send(c);

AncientPrinterEmulatorV1.zip

Oh, and I wanted to start mentioning a few things about the code. It's late, so here are the main things.

There are lots of TODO comments in the code. The class design is mostly done, but there are a few things I'm still not happy with.

• Choosing a paper size. (Right now it defaults to Letter and doesn't scale or anything if it's changed. Just like a real ancient printer. ; - )
• Communication of paper metrics (dimensions and margins etc) between the classes doesn't do anything meaningful yet.
• Most other TODO items are just more commands or options that should be handled or added.

But this is the important one I ran into and spent a couple of weeks playing with in GdiPrinterWriter:
// TODO: Using FillRect to simulate adjacent plots results in gaps needing fudge factors above.
// It might be a scaling error in GDI printing, since both PDF and XPS virtual printers show it.
// Plotting to a bitmap then rendering that to the printer page might look better.

Search for Fudge Factor and try changing the values (e.g. to zero first) to see the problems I encountered.
There seems to be some scaling error in GDI. I'm pretty sure it's not in my code (e.g. see the PITCHTYPE macro).
I would like to port APEL to C# and see if WPF/GDI+ performs better. Also it would be easier to try the bitmap in C#.

After getting to this stage I went and had a look at GSport to see the AppleWriter II emulation there.
Though the code is horrible, it seems to use a bitmap. (I haven't tried to test it yet.)

One reason I wanted to avoid a bitmap was to draw text with GDI fonts for better quality and PDF text selection.
I suppose there are ways it could be achieved.

• Text could still be GDI based and the graphics bitmap drawn with transparency over or under it.
• Text could be bitmap based - this could offer better retro-fidelity and use the actual font data from the printer.
• For bitmap text, the GDI text drawing could be done transparently so PDF text selection is still possible.