The problem with printer drivers is you have to create them individually once per operating system, which takes long. I did something like that once, leveraging existing PostScript drivers, for a personal research project called Duplex Printer, which can be found here: GitHub - Cuperino/Duplex-Printer: Virtual printer adds ecological features to physical printers. Such as multiple pages per sheet, monochromatic, and duplex printing.
Duplex Printer was a virtual printer that made duplex printing and more possible on nearly all printers, including old printers (from the early 90s through the 2000s) that lack modern features. If you or anyone likes this idea, consider using Boomaga which, although it only comes for Linux, offers most of what I was doing with Duplex Printer, and does it better: http://www.boomaga.org/
Back to topic, a printer driver wouldn’t work because it would limit you to glyphs, which would be lacking in flexibility or performance depending on how the driver is made. An export plugin on the other hand would mean programming such plugin for each word processor where it’s meant to be used. Since today we live in a world where open standards are dominant, there’s rarely a need for export plugins.
We just need to incorporate or create a create that converts ODT and DOCX to HTML, and that would work for: Google Docs, Office 365, LibreOffice, WPS Office, and OnlyOffice to start. The challenge so far has been in finding an open source library that can read DOCX, that isn’t tightly coupled with a full office suite.
As a workaround to not being able to find such a library last year, I implemented a feature that allows QPrompt to call LibreOffice, have it perform those and various other conversions transparently, and then load the resulting HTML. I haven’t enabled the feature yet because parts are hard coded and untested on Windows and Mac. The disadvantage in this approach is conversions are subject to bugs in LibreOffice, and since exporting to HTML is not a feature people use often, bugs such as this one I reported can go without fixing for a long time: https://bugs.documentfoundation.org/show_bug.cgi?id=143522
I wouldn’t worry much about the effort that it takes to decouple the editor because I plan on re-using the existing Prompter component, meaning that it shouldn’t take too long complete. Maintenance wise, it would require more tests to ensure changes in one place don’t break the other, but as long as good coding practices are followed (particularly separation of concerns and DRY practices), maintenance costs should increase much, and can be reduced by incorporating automated testing.