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!

 

libgxps 0.2.0

More than a month ago I released libgxps 0.1.0, the first release of libgxps, but for several reasons I ended up not announcing it. I’ve just released a new version that includes a small API break and a lot of new features and improvements, see the release notes for further details. I’ll release evince 3.3.2 next week depending on this new libgxps version (when building with –enable-xps).

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

XPS Documents

I’d never heard about XPS format until someone filed a bug report asking to support it in Evince. It doesn’t seem to be commonly used, at least in the free software community, since there are just a few requests in bugzilla. However, I downloaded and read the XPS specification (thanks to Okular) just out of curiosity, and it sounded like something fun to implement. Taking advantage of the quiet summer days I started to write a library based on GLib/GObject and Cairo to render XPS documents.

Today, the library implements the minimum stuff to be able to read the XPS spec (rendering, outline and links) and I’ve added a new backend to Evince that uses it. There are still some known bugs and many things to do, but it’s possible to read quite a lot of XPS documents with Evince already.

XPS Specification in Evince
XPS Specification in Evince

Adding new annotations with Evince

I’ve finally added support for adding new annotations to Evince. At the moment only text annotations are supported and it requires poppler from current git master. There are still things to do, but the main functionality is working now. The idea is to add support for more annotation types (geometry, highlight, file attachments, …) during the next release cycle, since we are close to feature freeze. Click on the image to see a screencast showing how it currently works, you can add annotations from the side panel, change the default properties (author, color, transparency, icon, …), and save a copy that can be opened with any other document viewer that supports annotations like, of course, Acrobat Reader.

Evince annotations
(click to play back, ogg/theora, ~8,7M MBytes)

By the way

I'm attending GUADEC

Evince 2.27.1 with preliminary annotations support

I said in my previous post I was going to talk about Evince 2.26, but I haven’t managed to find time to do it. Anyway, I guess that at this time everybody has already discovered the new features of Evince 2.26, so I’ll talk about 2.27.1 now.

2.27.1 is the first unstable release leading up to Evince 2.28. It has been released a week later, because the annotations support wasn’t ready, and we wanted to include it in the first release of the development cycle. At the moment only Text Annotations (those represented by an icon in the document with a popup window associated) are supported, and only existing annotations can be modified. Poppler doesn’t support adding new annotations to the document yet, so this will be the next step. Once we have complete support of Text Annotations, adding support for other annotation types should be easier.

A PDF document with text annotations in evince
A PDF document with text annotations in evince

I have to say that this has been done thanks to the great work done by Iñigo Martínez as part of the Google Summer Of Code program. I just continued his work.

Annotations are not the only new feature of this release, see the NEWS file for a complete list of changes. And we are still at the beginning of the cycle! 🙂

Evince 2.26 without annotations

Annotations support is in our RoadMap since GNOME 2.20, and it has been the main goal since then. However, we failed in 2.22, in 2.24 and we are going to fail again in 2.26.

Lack of time is the main reason for this failure (remember that we, the Evince development team, are all volunteers), but it’s not the only one. During the 2.25/2.26 cycle we have started to work on the annotations stuff, although (as usual) a little bit late, when the feature freeze deadline approached. When we had the minimum support already implemented, we realized that poppler didn’t have support for writing annotations yet. I don’t know why, but I was quite sure it was already implemented. The thing is that there isn’t writing support for annotations in poppler right now. So we had, at least, two options: releasing evince 2.26 with annotations support in a read only mode or delaying the annotations support to the next cycle once again. Both have advantages and disadvantages, but the main reason why we decided not to release 2.26 with annots support is because we don’t think that annotations are useful if you can’t actually use them. I’m sure we were going to receive lots of bug reports about non editable popups.

So, what’s the plan? The idea is to implement writing support in poppler ASAP, and merge the evince code early in the next development cycle.

Despite the annots stuff, I’m very happy with the work done during this cycle, but I think I’ll better talk about Evince 2.26 later in another post.