Last week, I finished the patch (not landed yet, though) to add printing errors reporting API to WebKit2 GTK+ API, which means only print preview is left to finish full printing support in WebKit2.
There are two main problems to solve regarding print preview implementation: the previewer to show print preview and the API to expose the print preview functionality. In GTK+ print preview is implemented by exporting the current document to PDF using the print options selected by the user (but without using the file print backend). Then a previewer application is launched with the generated PDF. In Mac it launches Preview.app and in other platforms evince-previewer. Then, the print dialog is closed, so to print the document you need to either, open the print dialog again, select the same options and click print instead of preview, or use the previewer print option. The former is not very convenient and the latter has a small problem. The previewer knows nothing about the original document, so all it can do is to print the generated preview document. The print result might be a bit different because the preview pdf has been generated using a custom implementation for the print capabilities (multiple pages persheet, scale, etc.), that are performed by the printer drivers when printing the original document. So, I think it's important to make sure that printing from the previewer sends exactly the same document to the printer than clicking print in the print dialog. So, for the previewer there are several alternatives: 1.- Do the same than GTK+ and launch evince-previewer with the generated PDF. 2.- Try to implement our own previewer (in-process) so that we can print from the previewer as if the user clicked print in the print dialog. This would mean we need to depend on a external library to render PDF: poppler or libevince. Both are GPL, so I think we can't use them, IANAL though. There's another option that would require some more changes, but might solve all the problems. We could turn evince-previewer into a D-Bus service org.gtk.PrintPreview (or something like that) that launches evince-previewer for a given pdf file and exposes a print signal so that apps can connect to it and start the print when emitted. When we implemented this in GTK+ GDBus didn't exist so it wasn't possible to use DBus inside GTK+. This would also remove the hard dependency on evince, since any app implementing org.gtk.PrintPreview could be used as previewer. If we agree on this approach and it works for us, I will propose to use it inside GTK+ too. This will also resolve the problem of who is responsible of removing the temporary file (we currently use a command line option for evince-previewer to indicate whether it should delete the file or not). Regarding the API, we can just add a 'preview' signal to WebKitPrintOperation and a preview() method to be able to generate a preview without using the print dialog. When the user clicks on preview button in the print dialog, a message is sent to the web process, the same way it's done when printing. In the web process we create the pdf using the same code we use when printing for the manual capabilities, but using our own pdf surface instead of using GtkPrintJob (that requires a printer). Once the pdf is finished, we sent the pdf data to the ui process (the same way mac does when printing) and the preview signal is emitted giving a GInputStream to read the pdf data. WebKitPrintOperation::preview - WebKitPrintOperation *operation - GInputStream *preview_stream The default implementation if this signal is not handled would save the pdf into a temporary file and launch the previewer using the DBus interface. If the user prints the document from the previewer, a D-Bus signal is emitted and we justr call webkit_print_operation_print() to print the document without showing the print dialog again. void webkit_print_operation_preview() would be similar to webkit_print_operation_print() and it would start a print preview operation using the current print settings and page setup. When it finishes the preview signal would be emitted as if the preview had been started by the print dialog. Opinions? -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
