Best practice for cross-platform printing

There have been a few questions about this on the forum but they’re all rather old.
My app currently is macOS only and for my print export I’m currently building an HTML document and I’m printing that using Obj-C (using WebView and the Cocoa printing routines).

I’m now about to port that over to Windows and I’m doing some research on printing.
It looks like I can’t use the same HTML printing approach on Windows easily without bundling other 3rd party components.

Some users on the JUCE forum advised using PostScript (specifically the JUCE LowLevelGraphicsPostScriptRenderer) and sending the underlying data directly to the printer.
That arises some questions though:

  • do all modern printers support PostScript?
  • how do I handle the format (portrait/landscape, A4 in e.g. Germany, letter in the US)?
  • what’s the right size to pick for the context?

I’d appreciate any feedback!
If you think PostScript isn’t the best way to go, please let me know.
I’m still in the research phase.

Addendum: Handing the PostScript data to the printer directly works (on macOS at least) but the big disadvantage is that this bypasses the print preview so users can also not easily create PDFs for example.

Just in case this is useful for anyone running into the same problem.
I decided to go with the libharu framework to write PDFs natively.
It is a lot of work as libharu only supports basic drawing primitives (lines, rectangles, text) so drawing a table for example is a very manual process :wink:

I’m then opening the resulting PDF using File::startAsProcess() so the user can print or save the file.

I’ll give this a bump as it seems a pretty useful thing to have inside JUCE. Not sure I want yet another dependency so I’m avoiding PDF for now.

1 Like

Eventually, I have decided to roll back to platform-native printing on macOS. LibHaru worked but users complained that they couldn’t properly select and copy/paste text blocks due to the way the PDF was written with libHaru.

So a cross-platform printing approach would still be appreciated!
Ideally from an HTML-style representation as in macOS since this makes formatting (for different paper sizes and orientation, preventing tables from breaking on page borders, etc.) and styling very easy.