Bug 75544 - [GTK][META] Add printing support to WebKit2
Summary: [GTK][META] Add printing support to WebKit2
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
Keywords: Gtk
Depends on: 79226 76172 76448 76536 76616 77197 78715 78793 78799 78805 78823
  Show dependency treegraph
Reported: 2012-01-04 06:58 PST by Carlos Garcia Campos
Modified: 2022-03-23 08:31 PDT (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2012-01-04 06:58:59 PST
The UI client has a callback to request printing a frame. The main problem is that printing happens in the WebProcess, but the GtkPrintOperation is created in the UI process. The GtkPrintOperation creates the cairo context we should render into (UI). A solution might be not using GtkPrintOperation and create the print dialog in the UI process with GtkPrintUnixDialog and GtkPrintJob directly.
Comment 1 Martin Robinson 2012-01-04 09:12:17 PST
Hrm. The issue with just passing a bitmap here is that we'd like to render onto a PDF surface, right?
Comment 2 Carlos Garcia Campos 2012-01-04 23:39:35 PST
Right, we can't use bitmaps, the surface created by GtkPrintOperation might be pdf or ps when using cups, ps when using papi and lpr, pdf, ps or svg when printing to a file and win32 printing surface in windows. 
Another solution might be to run the print dialog in the web process like we currently do for auth dialogs. I don't like the idea but it might work.
Comment 3 Carlos Garcia Campos 2012-01-05 02:33:27 PST
Chromium uses GtkPrintUnixDialog + GtkPrintJob in unix FWIW.
Comment 4 Gustavo Noronha (kov) 2012-01-09 08:27:09 PST
For the record, I'm pro the creation of the dialog in the UI process with the settings then piped through the IPC to the web process for the actual printing, like Carlos proposed, and with the creation of the WebKitPrintOperation object.
Comment 5 Carlos Garcia Campos 2012-01-09 08:39:27 PST
Yes, the idea is to use GtkPrintDialogUnix in the UI process, without exposing it in the API, using WebKitPrintOperation, the same way GtkPrintOperation does. This way someone could add win32 support using the window native printing dialog, using the same API. This object will run the dialog and send the print settings and page setup to the web process thought IPC. In the web process a GtkPrintJob object will be created using the print settings. GtkPrintJob creates the cairo surface using gtk printing backends. Then the frame is rendered into the printing surface and the job sent to the printer. This is the general ideal for the basic functionality.
Comment 6 Carlos Garcia Campos 2012-01-12 06:41:58 PST
Making this a meta bug since I'm going to split the work into several patches: 

 - Initial printing support in WebProcess
 - Initial API
 - Manual capabilities (copies, collate, reverse, multiple pages per sheet, scale, etc.). Maybe using a different bug per capability.