[print] Add plugin for (silent) print API

[FabianLars]

Upstream issue: https://github.com/tauri-apps/tauri/issues/4917 / https://github.com/tauri-apps/wry/issues/707

Short term goals:

• All APIs should be available in Rust and JavaScript
• [ ] Windows support
• [ ] macOS support
• [ ] Linux support
• [ ] Print currently displayed page to a PDF file
• [ ] Print currently displayed page with the default printer
• [ ] Make printer configurable - splitting this up because the Windows APIs look a bit tricky

Mid and long term goals are optional in the sense that i don't know if all them are possible to implement.

Mid term goals:

• [ ] Print the current viewport
• [ ] Print an arbitrary area The webviews have screenshot apis that can take screenshots of the viewport and areas, in case the print apis don't support this.

Long term goals:

• [ ] Android support
• [ ] iOS support
• [ ] Print files that are not part of the frontend but can be opened by the webview
• [ ] Print arbitrary files, i'm not sure how viable this is, it also won't use the webview apis
• [ ] ESC/POS printing (thermal printers). This should probably be a different plugin but i think there will be some overlap so we'll see.

Since https://github.com/tauri-apps/wry/issues/707 is a thing we may end up upstreaming a few APIs but we'll see...

P.S. I don't want to see PRs being open for months/years so we should aim for small scoped PRs even if that means splitting it up per OS.

Resources

• Electron api docs (getPrinersAsync, print, printToPDF): https://www.electronjs.org/de/docs/latest/api/web-contents#contentsgetprintersasync
• Windows APIs:
  • Print
  • PrintToPdf / PrintToPdfStream
  • PrintSettings / PrintSettings2
  • EnumPrinters

[julianbuettner]

I could try to implement cross platform raster image printing and printer device enumeration. For raster image printing Windows has it's GDI interface, and linux/mac uses cups which implements the internet printing protocol (IPP) which supports raster image printing as well as other features like printing PDF files natively.

However, I do know nothing about rendering webview, so I would need help on that part.

[luanmm]

It seems, to me, that this API should be decoupled from the "page" or "contents" structure (in Electron it seems to be tightly coupled, which I think is a mistake because it limits a lot).

Printing is something more generic, that could be used in a lot of scenarios (the "web contents" itself, but to print documents aswell and even raw printing using languages like ZPL, EPL, etc).

For me, it seems that this API needs to provide a way to enumerate printers (and get details, as in Electron) and to send "bytes" to a printer (with options to allow some customization, like bypassing drivers or something like that).

About cross-platform implementation, I would suggest Win32 APIs for Windows and CUPS for Mac/Linux (as stated above). It should be possible to do even raw printing that way.

And, to print the "web contents", perhaps the best would be a way to transform it in PDF and then submit the bytes to the printer (this way the same API would allow basic and advanced scenarios).

[probert94]

I agree with @luanmm I am currently migrating a desktop app to the web and I think about an (optional) wrapper using Tauri to support enhanced features. One of this features is silent printing of documents that are generated out of the data on the fly. So printing should definitely not be coupled to the page or contents. The printing logic on the desktop uses "raw" print to decide which paper tray to use for each page and so on. Fortunately prining is less used nowadays and some of the complex logic might not be needed (at least not as often) anymore but still it would be great to support it.

[dev-itzarun]

@FabianLars any update on this ?

[FabianLars]

no

[oSethoum]

any updates on this?