Bug 212814
| Summary: | [GTK] Cannot 'Export to PDF' | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Milan Crha <mcrha> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | REOPENED | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, dev-webkit |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Milan Crha
Coming from https://gitlab.gnome.org/GNOME/evolution/-/issues/974
The GTK_PRINT_OPERATION_ACTION_EXPORT action seems to be ignored by WebKitGTK (2.28.2), it always shows a print dialog, instead of exporting to the given file name. That can lead to a lot of print dialogs when dragging mouse above a Nautilus window.
It's also bad that WebKitGTK needs the main GMainContext to operate, because when it is hidden below another main context (see the upstream bug), then it just freezes the application in an indefinite wait for a request completion , which is piled in a GMainContext, which is not iterated. I do not think you can do much about this, the idea of EAsync has some caveats and this is only one of them. I only mention it here to provide a reason why the application is frozen.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Carlos Garcia Campos
I'm not sure I understand. Where is WebKit expected to handle the GTK_PRINT_OPERATION_ACTION_EXPORT? We don't use gtk_print_operation_run(). webkit_print_operation_run_dialog() always shows the dialog and webkit_print_operation_print() doesn't show the dialog.
Milan Crha
Oh, I see, that's some misunderstanding on the Evolution side. After looking around the code with the pointers you gave me I see the action is not even used, which is a shame. I'm sorry for a false bug report.
Milan Crha
I'm reopening this. I tried to use webkit_print_operation_print(), but it fails with "Printer not found". Remember, I only want to Export to PDF file, not to print anything on a real printer hardware.
I chose "Print to File" printer (I found that name in the WebKit tests). That failed due to sandbox (bug #202363), thus I worked around it by using WEBKIT_FORCE_SANDBOX=0. When I run the application in other than English-like locale the printer cannot be found again (because it's not named "Print to File" in that locale). I'm pretty sure your internal tests will also fail when you run them in other than the English-like locale.
That being said, is there a way to just pass a file name to the WebKit and it'll populate the file content with the PDF data? The gtk+ itself uses GTK_PRINT_OPERATION_ACTION_EXPORT and uses the file name set by the gtk_print_operation_set_export_filename(). It does not need any printer set, it's just for the "Export to PDF" action.
dev-webkit
WebKitGtk is used as a webview for Tauri, a light application framework, an alternative to electron. Currently it is missing a print API but this bug is going to prevent it from having a complete print API with PDF generation.
See: https://github.com/tauri-apps/tauri/issues/4917#issuecomment-2232928109
dev-webkit
It seems printing to file is already implemented, it's just a matter of providing an API for it.
In WebKitPrintOperation.cpp there is the function findFilePrinter that selects the proper printer for file printing and the function webkitPrintOperationSendPagesToPrintPortal that uses it to create a printed file.