[webkit-gtk] Print preview in WebKit2

[Carlos Garcia Campos]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120227/be6f2ea0/attachment.bin>