🚀 go-pugleaf

One of the features of my alarm-monitoring MS-Windows app I am currently
developing is to process messages from hardware devices connected to COMM
ports and output them concurrently to a window and a printer (the printed
output is a hardcopy of the sequence of events, called "Event-Log"). While
dumping messages to a window is a breeze, the same cannot be said about the
printer.

The only way I managed to rout an event immediately to the printer
(complying with MS-Windows printing procedures) was by using StartDoc(),
Escape(...PASSTHROUGH...) and EndDoc(). A single event is sent with
PASSTHROUGH and formated with CR\LF control characters. The application
knows how many lines fit on the printer and the last event that fits on
a page is terminated with a FF control character.

While this approach works, it has some nasty side effects:

- If I use another application to print documents, this document does
  not start on a new page (my app isn't aware of this and doesn't
  send a FormFeed to the printer). Furthermore, my app does no longer
  propper page advances since it has invalid information about the page
  position.

- Also, numerous events can occur simultaneously. Since each event causes
  a seperate document be sent to the printer, the print manager complains
  as soon as more than 100 documents (events) are queued. If I buffer events
  mayself (eg. if many events arive and I send as many events as possible
  within a single document to the spooler), the log prints only once the
  EndDoc() function is called. However, since the user can see all ariving
  events appearing in the event window but nothing appears on the printer,
  she/he gets the impression that something is wrong.

Does anyone know how this can be accomplished propperly? Or do I have to