GTK+ 3 Plugins in WebKitGTK+ and Evince Browser Plugin

GTK+ 3 plugins in WebKitGTK+

The WebKit2 GTK+ API has always been GTK+ 3 only, but WebKitGTK+ still had a hard dependency on GTK+ 2 because of the plugin process. Some popular browser plugins like flash or Java use GTK+ 2 unconditionally (and it seems they are not going to be ported to GTK+ 3, at least not in the short term). These plugins stopped working in Epiphany when it switched to GTK+ 3 and started to work again when Epiphany moved to WebKit2.

To support GTK+ 2 plugins we had to build the plugin process with GTK+ 2, but also some parts of WebCore and WebKit2 (the ones depending on GTK+ and used by the plugin process) were built twice. As a result we had a WebKitPluginProcess binary of ~40MB, that was always used for all the plugins. This kind of made sense, since there were no plugins using GTK+ 3, and the GTK+ 2 dependency was harmless for plugins not using GTK+ at all. However, we realized we were making a rule for the exception, since most of the plugins don’t even use GTK+, and there weren’t plugins using GTK+ 3 because they were not supported by any browser (kind of chicken-egg problem).

Since WebKitGTK+ 2.5.1 we have two binaries for the plugin process: WebKitPluginProcess2 which is exactly the same 40MB binary using GTK+ 2 that we have always had, but that now is only used to load plugins using GTK+ 2; and WebKitPluginProcess, a 7,4K binary that is now used by default for everything except loading plugins that use GTK+ 2. And since it links to GTK+ 3, it might load plugins using GTK+ 3 as well. Another side effect is that now we can make GTK+ 2 optional, WebKitPluginProcess2 wouldn’t be built and only plugins using GTK+ 2 wouldn’t be supported.

Evince Browser Plugin

For a long time, we have maintained that PDF documents shouldn’t be opened inside the browser, but downloaded and then opened by the default document viewer. But then the GNOME design team came up with new mockups for Epiphany were everything was integrated in the browser, including PDF documents. It’s something all the major browsers do nowadays, using different approaches though (Custom PDF plugin inside the web engine, JavaScript libraries, etc.).

At the WebKitGTK+ hackfest in 2012 we started to think about how to implement the integrated document reading in Epiphany based on the design mockups. We quickly discarded the idea of implementing it as a NPAPI plugin, because that would mean we had to use a very old evince version using GTK+ 2. We can’t implement it inside WebKit using libevince because it’s a GPL library, so the first approach was to implement it inside Epiphany using libevince. I wrote a first patch, it was mostly a proof of concept hack, that added a new view widget based on EvView to be used instead of a WebView when a document supported by evince was requested. This approach has a lot of limitations, since it only works when the main resource is a document, but not for documents embedded in a HTML page or an iframe, and a lot of integration problems that makes it quite difficult to maintain inside Epiphany. All of these issues would be solved by implementing it as a NPAPI plugin and it wouldn’t require any change in Epiphany. Now that WebKitGTK+ supports GTK+ 3 plugins, there’s no reason not to do so.

Epiphany Evince Plugin

Thanks to a project in Igalia I’ve been able to work on it, and today I’ve landed an initial implementation of the browser plugin to Evince git master. It’s only a first implementation (written in C++ 11) with the basic features (page navigation, view modes, zoom and printing), and a very simple UI that needs to be updated to match the mockups. It can be disabled at compile time like all other frontends inside Evince (thumbnailer, previewer, nautilus properties page).

Epiphany embedded PDF document Epiphany standalone PDF document

Another advantage of being a NPAPI plugin is that it’s scriptable so that you can control the viewer using JavaScript.

Epiphany scriptable PDF

And you can pass initial parameters (like current page, zoom level, view mode, etc.) from the HTML tag.

<object data="test.pdf" type="application/pdf" width="600" height="300" 
                currentPage="2" zoomMode="fit-page" continuous="false">
  The pdf could not be rendered.
</object>

You can even hide the default toolbar and build your own one using HTML and JavaScript.

Evince Hackfest

The Evince hackfest took place last week from 23rd to 25th July in Strasbourg. Yes, 3 days only, but very productive in my opinion, I’ll summarize all the cool stuff we worked on.

HiDPI

This work was initially started by Owen, and then Germán kept the patches up to date with evince git master. I reviewed all the pending patches and updated the thumbnails one and the result is that evince doesn’t look blurry on HiDPI screens any more.

Evince running with GDK_SCALE=2

Evince running with GDK_SCALE=2

Recent View

This was a GSoC project of 2013, but the patch provided by the student was never in an “upstreamable” state. Again Germán, who always loved this feature, took care of the patch addressing my review comments. At the beginning of the hackfest most of the work has already been done, we only needed a few more review iterations during the hackfest to finally push this feature to master. The idea is to show the list of recent documents as an icon view with thumbnails and documents metadata. This view is loaded when evince is launched without any document replacing the useless empty window we had before. It also replaces the recent documents submenu in the gear menu.

Evince Recent View

UI improvements

The move to the header bar recently made the toolbar look a bit cluttered, mainly because the title might use a lot of space. We discussed several ideas to improve the header bar and implemented some of them:

Evince header bar improvements

 

Juanjo Marín also wrote a patch to change the default zoom mode to “Automatic”, since several people commented that the current “Fit Width” mode doesn’t look good in screens with higher resolutions. The patch is still waiting review.

Annotations

Giselle and Anuj, our GSoc students this year, worked on their projects to improve the annotations support in both Evince and poppler.

    • Anuj wrote some patches to add support for Free Text annotations to poppler glib API. After a couple of review iterations and discussions about the API, the patches are now in bugzilla waiting for a final review (I hope to find the time soon)
    • Giselle was focused on adding support for highlight annotations to Evince, since poppler already has all the required API for this. The patches are not yet ready, but they look really promising.

 

Caret navigation and accessibility

Joanie and API continued improving the evince a11y support and fixing some remaining issues from the FoG project. Antía fought with the caret navigation implementation again to implement some missing key bindings and fixing other issues.

Comics backend

Juanjo Marín focused on the comics backend, working on a patch to use libarchive to uncompress the documents instead of spawning external command line tools.

Gestures

I started to review the gestures branch during the hackfest, patches looked clean and simple, but since I was not familiarized with the new GTK+ touch API and I didn’t have a touch screen to try it out either, I decided to wait after the hackfest and see it in action in garnacho’s laptop during GUADEC. Carlos explained to me how the touch API works in GTK+ and I could check it actually works great. The code doesn’t affect the normal use with the mouse, so the branch will be merged in master soon.

Evince hackfest dinner

And of course not everything was hacking

THANKS!

Many thanks to Alexandre Franke for the local organization, everything worked perfectly. Of course thanks to the GNOME Foundation for sponsoring the GSoC students, Giselle and Anuj, and Igalia for sponsoring all the Igalians attending the hackfest. Thanks also to Epitech for allowing us to do the hackfest there before the GUADEC.

Igalia S.L. GNOME FoundationEPITECH

WebKitGTK+ Hackfest 2012

This year again the WebKitGTK+ hackfest took place at the Igalia office in A Coruña, and this year again it’s been awesome.

My main goal for the hackfest was to implement an extension system for the web process in WebKit2, that would allow, among other things, to access the DOM, which is the major regression of the WebKit2 GTK+ API. The idea was to use the exactly same GObject DOM bindings API we are currently using in WebKit1, so I moved it to a convenient static library and installed the public headers in its own directory making it shareable between WebKit1 and WebKit2. Once GObject DOM bindings were accessible from WebKit2 I wrote a first patch to implement the web extension system providing a new API for extensions to access the DOM.

I also took advantage of the hackfest time, to re-take a task I had pending for some time, adding an API to WebKit2 to handle SSL errors. I didn’t have time to finish the API, but managed to write a first patch to set a policy for SSL errors. For now it only allows to ignore SSL errors and continue the load or make the load fail in case of SSL errors. The idea is to add a new policy to ask the user what to do.

Even though it was not part of my initial plans for the hackfest I ended up working on the document reading integration in Epiphany. I wrote an initial patch for Epiphany to load documents supported by Evince embedded in the window like a web view. There are still a lot of features to integrate like zooming, searching, printing, etc.

Epiphany showing a PDF document

I set a milestone to switch Epiphany to WebKit2 by default at the end of the hackfest, but I didn’t have time to fix all the regressions. We are a lot closer, though.

This event is impossible without the sponsors, thanks!

 

Cairo 1.10

Yes, it’s true, Cairo 1.10 has been finally released. Chris already summarized two years of development in 60 lines, so I’m going to talk about how this release affects to Evince/Poppler.

Blend Modes

Cairo 1.10 has some new operators inspired by PDF blend modes, that allowed us to easily implement PDF blend modes in the poppler cairo backend

PDF Blend Modes
PDF Blend Modes

Here is an example of a PDF document combining the use of Multiply blend mode with gradients

Scooby gradient rendered with Cairo 1.8
Scooby gradient rendered by poppler with Cairo 1.8
Scooby gradient rendered by poppler with Cairo 1.10
Scooby gradient rendered by poppler with Cairo 1.10
Scooby gradient rendered by xpdf
Scooby gradient rendered by xpdf

Blend modes are also important for annotations, since highlight annotations are usually implemented by using the Multiply blend mode

Performance

There were some PDF documents where the performance of the poppler cairo backend was really bad. It seems that, with such particular documents, poppler was clipping too much. Of course, Chris fixed it, see the screenshot:

Poppler with cairo 1.8 and 1.10
Poppler with cairo 1.8 and 1.10

Output file size when printing

Thanks to cairo_surface_set_mime_data now we can attach the original uncompressed image to the ps/pdf surface that will be used when creating the resulting ps/pdf file. It drastically reduces the size of the ps/pdf output files created when printing documents that contain images

Fit to contents/Trim margins

This hasn’t been implemented in Evince yet, but using the new recording surface we can get the page bounding box and use it to implement a new fit to contents zoom mode.

Thanks!

Thank you very much to everybody involved in this release

Extracting images with Evince

Finally, the patch I wrote to allow extracting images from a PDF has been applied to poppler cvs head (thanks Albert). Evince already supports this feature since 0.7.1 version. Here is a screencast.

Evince images handling
(click to play back, ogg/theora, ~3.0 MBytes)

Images selection is not supported yet, but I’m already working on it 😉

Evince images selection
Select images

Google Summer of Code 2007

The list of approved projects has been announced!. Iñigo Martínez, a student from the Universidad del País Vasco, is going to be my student to implement annotations support in Evince. We received more than ten proposals to implement annotations support so the final decision hasn’t been easy. I’ve been talking with Iñigo and he seems to be very motivated so I’m quite sure the project is not going to fail this year. Now is time to work and enjoy hacking!

Evince attachments

Attachments support is a PDF feature that is not known by many people. However, it’s a nice feature and very useful. You can add any kind of file to a PDF document as an attachment. For example, if you are writing a programming document, you could attach the source code of your examples to the document instead of making a tgz with all of the files (the document itself and the examples).

I thought it could be a funny hack for evince, and I decided to implement it. Finally it has been a really funny hack :-). AFAIK evince is the only free PDF viewer that supports attachments right now. Here is the screenshot:

A PDF document with attachments in evince
A PDF document with attachments in evince

XGN

This weekend I will be, one year more, at XGN in Santiago de Compostela (Galicia, Spain). Personally, the best thing about this party is the opportunity to meet again with all of my friends from linups.

Evince

A few days ago, juanjo talked to me about beamer, a LaTeX class for creating presentations. It’s awesome! You can install it from ubuntu/debian repositories and it comes with a lot of useful themes. Beamer is thought to be used with pdflatex to generate the output, so it uses some pdf features like specialized links.

The other day I noticed that evince doesn’t support all of the links included in a pdf generated by beamer. Concretely the links that are called in the PDF Reference as “Named Actions”. The named actions that a document viewer is expected to support are NextPage, PrevPage, FisrtPage and LastPage, although there could be additional, nonstandard actions, like Find or GoToPage which are used by beamer.

Poppler already supports Named Actions, but poppler-glib doesn’t. I’ve added support for them in poppler-glib and then in evince too. Since we are “freezed” right now, we have to wait until branch for 2.16 to be able to check it in.

I have started a campaign in GSyC in favour of evince, since many people are still using xpdf. At the moment it seems that grex is convinced as well as acs who didn’t have to be convinced indeed. The big problem is that most of them are using old evince versions, so I’m pretty sure that, when they upgrade to dapper (at least ubuntu users) and try it out again, they all will change their opinion about evince.