As every year many ideas came up during the WebKitGTK+ hackfest presentation, but this time there was one we all were very excited about, the multiple web processes support. Apple developers already implemented the support for multiple web processes in WebKit, which is mostly cross platform, but it requires the network process support to properly work (we need a common network process where cookies, HTTP cache, etc are shared for all web processes in the same web context). Soup based WebKit ports don’t implement the network process yet, so the goal of the hackfest became to complete the network process implementation previously started by EFL and Nix guys, as a first step to enable the multiple web processes support. Around 10 people were working on this goal during the whole hackfest, meeting from time to time to track the status of the tasks and assigning new ones.

• Andy updated some of the patches already waiting for a review and set up github repo with all those patches so that we all could work without dealing with individual patches.
• Sergio updated the patch proposed by Balazs to implement the bits required to connect the network process with the web process using UNIX domain sockets.
  
• Brian added the option to build with the network process enabled (disabled by default).
• Martin updated the soup backend to use WebKit buffers when reading network data instead of char pointers because the network process only accepts WebKit buffers.
• Kwang and Brian fixed the SSL errors policy handling when using the network process.
• Berto fixed the way the network process was enabled, by moving it to the right place and enabling it by default when WebKit is build with network process support.
• Kwang fixed a method in the web context to send messages to the current networking process to allow sending messages to the network process even when using the single shared process model.
• Berto added support to run the network process with an arbitrary prefix command in debug builds for easily debugging crashes or leaks.
• Gustavo fixed the original encoded data size calculation, since we were using the decoded data size instead.
• Kwang updated the patch he started and Csaba continued to add support for cache model in the network process.

After all this awesome work we managed to have the basic support, with MiniBrowser perfectly rendering pages and allowing navigation using the network process. But as expected, there were some bugs and missing features, so I ran the WebKit2 unit tests and we took failing tests to investigate why they were failing and how to fix them.

• Berto is working on loader client tests failing due to missing notifications in the network process.
• Adrian submitted a patch to add new API to select the process model that will be used when the network process support is finished. He is also working on the problems of having multiple instances of the web extensions.
• Kwang is working on fixing the cookies handling in the network process.
• I submitted a patch to implement the initiating page support in the remote networking context used by the network process. I’m working on adding support for custom URI schemes to the network process as well.

So, we are actually far from having a complete and stable network process support, but it’s a huge step forward. The good news is that once we have network process implemented, the multiple web processes support will work automatically just by selecting the multiple web process model.

All this sounds like a lot of work done, but that’s only a small part of what has happened this week in Coruña:

• Martin and Gustavo made more parts of WebKit actually build with the cmake build.
• Jon made several improvements in Epiphany UI.
• Gustavo fixed the default charset encoding used by Epiphany.
• Iago, Edu made some progress in the wayland support for WebKit2.
• Dan was working on HTTP2 implementation for libsoup.
• Zan was finalizing his GSoC work under Martin’s mentorship to bring WebGL support under Wayland
• Gustavo added support for right-side docking of the web inspector in WebKitGTK+.
• Javi, Rego and Minhea were focused on a new implementation for the selections in CSS regions.
• Calvaris began to rewrite the GTK media controls once more, this time in JavaScript.
• Zan finished the patches to add battery support in WebKitGTK+ using upower.
• Martin, Gustavo and Zan worked on support for testing WebGL and accelerated compositing layout tests in WebKitGTK+.
• Brian, Alex and Zan were working on the parsing of the valgrind xml output used when running the tests under valgrind to detect memory leaks.
• Brendan added a setting to both WebKit1 and WebKit2 APIs to enable media source and fixed a crash in several video layout tests.
• Claudio went back to his work on the notifications support for WebKitGTK+ and was reviewing patches like crazy.
• Philippe worked on the WebRTC implementation for the GStreamer WebKit media backend.
• Mario, Joanie and API were focused on accessibility, also making sure that the multiple web processes doesn’t affect the accessibility support.
• Brendan also worked on MediaSource, investigating how to handle video resolution changes.
• I removed all the WebKit1 unused code from Epiphany, and moved the GNOME shell search provider to its own binary.

And I’m sure I’m missing more great stuff done that I could not follow closely. It’s definitely been a very productive hackfest that it would haven’t been possible without the sponsors, Igalia and the GNOME Foundation. Thanks!

So for the 5th time I attended the WebKitGTK+ hackfest and as usual I spent most of the time working on Multimedia-related tasks, well just one this year actually, WebRTC.

I think WebRTC is quite an important HTML5 specification, we all want to get rid of Skype and embrace the world of open web video-conferencing, right?

To reach this goal we have mainly two big milestones. The first one is about letting the browser access the audio/video device if the user allows it and use <audio>/<video> elements to display the live feed. This part of the spec is called getUserMedia, I got it working in a branch, the patches are being upstreamed and hopefully we will turn this feature on soon in WebKitGTK+!

The second, and biggest, milestone is about actually establishing a peer-to-peer connection between multiple browsers over the internets. Based on some work done by Ericsson 3 years ago I started working on a PeerConnectionHandler for WebKitGTK+. The ICE agent it embeds is using libnice to handle the gathering of Candidates and NAT traversal. The backend is not yet functional, ICE negotiation is quite buggy, but I will keep working on the backend.

Once this is done there will be new features from the spec to support, like the Data channel, DTMF, Statistics gathering and it would also be cool to investigate on the screen sharing that's not (yet?) in the spec but supported in Chrome. Exciting times ahead!

Once more the event wouldn't have been possible and successful without sponsors, so big thank you to the GNOME Foundation and Igalia!

So this was my first participation in the WebKitGTK+ hackfest. It was great to have some time to focus on WebKitGTK+ hacking for a few days as well as meeting other colleagues face to face to discuss various related topics, specifically the one I am most interested in: Wayland support in WebKit2.

A few months back I was reviewing the status of WebKitGTK+ in Wayland and mentioned that one of the main challenges was the multi-process architecture introduced with WebKit2, the one that Web/Epiphany is currently using.

The problem is simple enough to explain: In WebKit2, scene composition is done entirely in the Web Process and then painted on the screen in the UI Process, so we need to share a graphics surface between these two processes. In X11 we do this by having the UI Process create an offscreen XWindow and sharing the window ID with the Web Process, but in Wayland there is no direct means to share a graphics surface between two Wayland clients.

The solution for this is to use the same means that a Wayland compositor uses to share graphics with its clients. The meaning of this in the context of WebKitGTK+ is that we need to implement a small Wayland compositor that we can use to share the rendering surface. The way this would work in is like this: the UI Process would play the role of Wayland compositor and the WebProcess would ask it for  a surface using regular Wayland APIs. Since the UI Process implements a Wayland compositor it will have access to the graphics buffers rendered by the client (the Web Process) and we have our problem solved. This is quite a bit more of work than simply sharing a Xwindow ID though.

Some months ago I was prototyping a proof of concept for how this would work taking WebKit out of the equation to keep things easy as a first step. During the hackfest I had the opportunity to complete the work and bring it up to date with the current status of Wayland together with the help of my colleague Eduardo Lima This small prototype has two parts: a GTK+ application with a custom GtkContainer widget (which would play the role of the UIProcess in WebKitGTK+) and a separate Wayland client that renders a simple GL scene. The GTK program spawns another process to run the Wayland client when started and also implements the required bits of the Wayland compositor interface to serve Wayland requests as required by the client.

The point of the experiment was to get the GTK program to use the rendering results of the client to paint its own widget contents. This is basically what we need in WebKitGTK+, where the GtkWidget would be the WebView running in the UI Process and the client process would be the Web Process rendering the results of the scene composition to a GL texture.

The next step is to implement this solution in WebKitGTK+, which is a work in progress at the moment. It is still quite a bit of work since the WebKit code base is quite large and complex, but at this point I think it is only a matter of time to get a basic solution to work. Then of course we will have to deal with a lot of other details that this initial proof of concept did not care about, like  resizing, managing surfaces for multiple windows and probably a lot more stuff that will pop up along the way.

Finally, there is another interesting consideration to make. Even if the UI Process can share a graphics surface with Web Process, it still has to render it on the GTK widget’s surface. The problem here is that GTK on Wayland uses a cairo image surface as backing or the window surface, so this process involves a copy that results in bad performance. I guess this should be fixed at some point in GTK+ so we can have the same performance we currently have on X11. In the past I tried to go around this by creating accelerated Wayland subsurfaces for the widget and render to that instead. This worked well for performance but it had to be done completely outside GTK+ , and hence it breaks a number of things (for example you have to position the surface manually within the window surface, events are not managed properly, etc), so it was a no go. I suppose that if GTK+ can provide means to manage Wayland subsurfaces for a widget natively, this would also be another option to fix the performance  problem.

In a nutshell, CSS Regions are a new W3C specification that allows next generation responsive design in the web platform (you can read this article for a nice introduction). Adobe WebPlatform team is doing a great job leading the implementation of this standard and we at Igalia are joining efforts to contribute to the challenge.

Selection’s performance plays an important role in the collaboration between Adobe and Igalia around CSS Regions. This is the first of a series of articles on how to fix performance issues in WebKit/Blink using the selection in regions use case as example.

We’ve been checking the performance of selection in regular pages compared to pages using CSS Regions. We created some examples (that you can try by yourselves) and they clearly show that the selection with regions is pretty slower as you can see in the picture. On the one hand this was expected due to complexity of CSS Regions, on the other hand we wanted to take a deeper look and see how it can be improved.

First of all we need objective numbers in order to show that the new patches improve (or not) the performance. For this purpose WebKit and Blink provide a mechanism called Performance Tests (perftests). Perftests measure the time required to run them and also the memory they consume. The idea is to create a baseline with these values and spot performance regressions in new revisions (see some nice charts generated from them).

On a low level note, perftests are simply HTML files which generally use a JavaScript object called PerfTestRunner which provides different utility functions, you can find them under PerformanceTests/ folder (both in WebKit and Blink). In addition you can run them using Tools/Scripts/run-perf-tests script.

There were already some CSS Regions perftests (see PerfTestRunner/Layout/ directory) but none of them about selection. So we decided to create a new perftest for selection in CSS Regions. The new test has 100 regions and it selects text from the first region to the last one passing through the rest of regions. That way we’re somehow simulating the interaction of a selection done by a real user. The test is called RegionsSelection.html and it’s available in WebKit and Blink.

Note: CSS Regions perftests are still skipped by default because of the fact that regions performance is an ongoing development. They’ll be enabled in the future once it’s possible to create a baseline.

Just to let you know how it looks like when you use the script, below you can see the results of running the perftest in WebKitGTK+ (using r160082):
$ Tools/Scripts/run-perf-tests --platform=gtk -2 Layout/RegionsSelection.html
Running 1 tests
Running Layout/RegionsSelection.html (1 of 1)
DESCRIPTION: Testing selection with 100 regions. Select text from first region to last one passing through all the regions.
RESULT Layout: RegionsSelection: Time= 987.760100001 ms
median= 990.745000017 ms, stdev= 8.95593764346 ms, min= 978.406000009 ms, max= 1013.26800004 ms
RESULT Layout: RegionsSelection: JSHeap= 173468.6 bytes
median= 173957.0 bytes, stdev= 1973.74275506 bytes, min= 169707.0 bytes, max= 174869.0 bytes
RESULT Layout: RegionsSelection: Malloc= 1593350.4 bytes
median= 1591104.0 bytes, stdev= 15450.5740939 bytes, min= 1567544.0 bytes, max= 1622624.0 bytes
Finished: 31.423325 s

Finally, once we have a perftest that provides objective numbers, we can start using a profiler and extract some data that helps us modify the code in order to improve the performance. We’ll talk about that in the next post. Stay tuned if you don’t want to miss what Igalia is doing related to CSS Regions.

And here we are, victims of our love and commitment with the web, GNOME, and WebKit, gathered in the most beautiful city of A Coruña, for what is the fifth edition of the always productive and joyful WebKitGTK+ hackfest.

This year the crowd has reached the unprecedent number of 30 people, which makes it for the largest hackfest to date. Not everyone has arrived yet, but day one has already seen some fruitful discussions on what should be tackled, and I hear that tortillas and tapas are on the way. Since I am a gossiper, I will advance you that it is very likely that we will see progress towards multiple web processes in WebKitGTK+/GNOME Web and even a network process; as well as pretty neat improvements to the UI of our cherished browser; and very possibly many more things of which I hope my dear hackmates will write about.

Given that I don't intend to allow an extensive account of the happenings in northern Galicia to become a distraction to what should actually be an extensive and exhaustive patch review session, I will instead close this post by thanking the GNOME Foundation and Igalia for making, once again, this hackfest possible. For further updates, stay tuned to Planet GNOME and the @WebKitGTK twitter account.

It’s been almost a year since my previous post in this blog, I think this deserves an explanation. This year I’ve been working intensively in web internals as part of Igalia’s browsers team. Besides other stuff, I’ve been working in WebKitGTK+ port and its new WebKit2 API, contributing some patches into Epiphany (GNOME Web Browser) and lately working in the CSS Regions implementation in WebKit (where I’m already a committer ) and Blink as part of the collaboration between Adobe and Igalia.

Inside this collaboration, our main goal is to fix the selection issues in documents using CSS Regions. You can read more information about it on Javi Fernández’s post. As explained there we have cooked some examples highlighting different issues with selection in CSS Regions.

Despite of having more than 35,000 tests in WebKit, there were almost no tests checking the selection in CSS Regions. Thus, we’ve been creating different layout tests that you can find under LayoutTests/fast/regions/selection/ folder in WebKit‘s and Blink‘s source trees.

Most of them are reftests, which means that we have two HTML files that should render the very same result. Specifically in this case we usually compare the result of the selection content and highlighted text in CSS Regions with the result of a crafted HTML page using absolute positions. Moreover, we try to do the tests in a way that you can check them manually directly opening the HTML file a browser. Besides, we’ve created tests for different writing modes like horizontal-bt, vertical-lr and vertical-rl.

At this point we have a good tests coverage that should be enough as base to prevent breakages in the selection with CSS Regions. Anyway, it’s clear that more tests will come in the future as soon as implementation advances and some issues get fixed. You can follow the work we’ve been doing on this meta-bug.

Just for the record, here you have the full list of WebKit bugs and Blink issues related to this task:

• WebKit:
  • Bug 121501 – [CSS Regions] Layout Test for selection direction
  • Bug 121841 – [CSS Regions] Layout Test for selecting text in 2 regions
  • Bug 122099 – [CSS Regions] Selection layout tests moved to specific folder
  • Bug 122128 – [CSS Regions] Helper functions for selection layout tests
  • Bug 122327 – [CSS Regions] Layout Tests for selecting text in 2 regions for other writing modes
  • Bug 122353 – [CSS Regions] Layout Test for selecting text ignoring region content
  • Bug 123327 – [CSS Regions] Rename CSS classes and JS methods in vertical layout tests about selection
• Blink:
  • Issue 25220002 – [CSS Regions] Layout Test for selection direction
  • Issue 25761004 – [CSS Regions] Helper functions for selection layout tests
  • Issue 25868002 – [CSS Regions] Selection layout tests moved to specific folder
  • Issue 25890007 – [CSS Regions] Layout Test for selecting text in 2 regions
  • Issue 34863002 – [CSS Regions] Layout Test for selecting text ignoring region content

Finally, I’d like to thank Igalia for giving me the chance to get involved in browsers development, working in the implementation of last specifications is a challenging but very heartwarming task. Let’s keep working hard to improve the web experience!

3.10 is out, what’s new about accessibility?

As you probably already know, GNOME 3.10 was released several weeks ago, with lots of new accessibility goodness:

• Magnifier focus and caret tracking: Finally, the focus and caret tracking feature of GNOME Shell’s magnifier has landed. Now the magnified view automatically follows the writing caret and changes in focus so you can always see where you are without having to move the mouse. You can read more about this work in this post written by Magdalen Berns, the GSoC student that implemented this feature.
• GNOME Shell improvements: One of the new features of GNOME 3.10 is the new System Status Menu. This menu includes several new visual elements which were reviewed and enhanced in order to ensure they would be fully keyboard navigable and accessible through accessibility tools like Orca. Keyboard navigability was also added to the calendar pop-down in the shell panel, though admittedly there is some room for improvement which we hope to address in GNOME 3.12.
• PDF accessibility: Evince keyboard support has landed. Now users can press F7 to activate a caret for navigation and selection within the document being read. This new support was also made to work with Orca, so that PDF content can be accessed by users who are blind directly in Evince. Support for tagged PDFs is currently being added to Poppler and will be used to further improve accessibility support in Evince. This work is being done by Igalia, having been funded by the Friends of GNOME accessibility campaign. You can read more about this work on Antía Puentes’s “Accessibility in Evince” and Adrián Pérez’s “Tagged-PDF: Coming to a Poppler near you” blog posts.
• A new global keyboard shortcut for Orca: Now the screen reader can be easily turned on/off at any time by just pressing Super+Alt+S. This might seem like a small change, but it is in fact a really big step that allows more distros to be more accessible out of the box.
• ATK deprecations (a lot): While this does not directly affect the user experience, over time it will make developers’ lives easier, and will also lead to cleaner and more easily maintainable code. The first one is the simplification of what used to be extremely confusing and hard-to-implement methods to get a substring from a text related object. We had been talking about this problem for a long time, and finally agreed upon the new API at this year’s GUADEC. Mario Sánchez then added the new method to ATK and AT-SPI2 and also implemented it in WebKitGTK. The other major change is related to focus handling. One signal and six methods were deprecated, simplifying the situation *a lot* in that regard.

What’s next?

Captain Obvious to the rescue: 3.12. Although 3.10 was better than 3.8, our plan is making 3.12 even better. Like a lot of other teams, we started the new cycle listing, analyzing and prioritizing everything we need to do, using the Montreal Summit as a kickoff for 3.12 and making the most of being able to talk face-to-face with other GNOME developers. There are always changes to keep up with: new applications, new widgets, and new deprecations. But right now, the more important change in progress is Wayland. A lot of work was done for 3.10, so that we have the possibility to run GNOME 3 using a Wayland session. It is still not production ready (in my humble opinion, it is alpha status), but the plan is filling the gaps for 3.12, and that includes accessibility.

But Wayland is not the only topic for 3.12. During the weekly Accessibility Team meeting after the summit, we discussed all the improvements planned for 3.12:

• Complete Wayland support
• Create a new asynchronous API for AT-SPI2
• Add configuration UI for some already-implemented magnifier features (focus/caret tracking and tinting)
• Homogenize keyboard navigation within GNOME (to be proposed)
• Update ATK implementations (e.g. GTK, Clutter) for deprecations and new API
• Implement tagged PDF support in Evince

Finally, I would like to thank my employer Igalia for its continued support of my work on GNOME accessibility as part of my job duties, and the GNOME Foundation for sponsoring my trip to the Montreal Summit.

Back in early June, Adobe and Igalia announced a collaboration to work on the CSS Regions and CSS Shapes W3C standards. Our first challenge has been to improve the Selection use cases when using complex layout models, like CSS Regions.

The CSS Regions model allows content to flow across multiple areas called Regions. This new approach offers web content designers a way to build richer and more complex layouts, mapping content with specific visual areas of a document. Defining different Flow Threads with multiple Regions, associating them to specific content, and applying different styles to a set of Regions is very powerful in terms of design and user experience. If you are interested, here you can find some examples of what is possible with CSS Regions.

But having this flexibility in web design requires overcoming quite a few technical challenges. The current implementation of CSS Regions in WebKit changes the way the Render Tree is created from the DOM Tree. This poses the challenge of making selection work with regions since selection is DOM based. Given its importance and frequent use, improving the interaction of selection and CSS Regions has been the main goal of our collaboration.

The W3C selection specification, which has not been updated since the last year, does not address the complexities introduced by new layout modules, like CSS Regions, CSS FlexBox and CSS Grid Layout module . We found out very quickly that selection had many issues, with respect to both visual appearance and selected content. We have created a tests suite to evaluate the different use cases of selection with CSS Regions.

Selected content does not match the highlighted area.

Selection direction issues

Let’s start with a very simple description of the concept of Selection Direction, which consist of the following points:

• The WebCore::VisibleSelection class has two attributes called base and extent declared as dom::Position instances
• Such positions refer respectively to the anchor and focus nodes in the DOM Tree.
• Additionally, WebCore::VisibleSelection has two dom:Position attributes, start and end, which are used later during the rendering phase

Once the base and extent fields are set when instantiating a new VisibleSelection class, some adjustments and checks are performed to validate the selection. One of those checks is whether base position is before extent in the DOM Tree. Based on the result of this check, the start and end attributes will be set to either base or extent respectively.

In the first test, the selected content includes the entire region block, even when it was not selected by the user. The cause, as we will see in later, derives from the position of the source block in the DOM Tree, which in this case is defined between the two regular blocks.

The second example shows some selection direction related issues; in this case, what the user selected is precisely the content between the two highlighted areas. The problem here is that the base node of the original selection is below the extent node in the DOM Tree, so they are swapped in the selection logic. In addition, the CSS Regions implementation builds the Render Tree in a way that the source content defined by a RenderNamedFlowThread block is positioned below where it was defined in the DOM Tree. The consequence of this is that the start node is below the end node, so the highlighted area starts in the region block and continues from the root element (usually the body) until reaching the end node.

Our first approach was trying to provide a better user experience during selection with CSS Regions. We thought that adding multi-range capabilities to the DOM Selection API was the best way to go and we provided a patch. However, this approach was rejected by some Apple reviewers because multi-range selection introduces many problems, such as those detailed in the selection specification.

We have opened the debate again on the mailing list, though, because we think there might be some advantages to this approach, even without modifying the selection API. For instance, being able to handle independent Ranges and compose the expected selection will provide the flexibility needed to implement complex use cases. But, after some discussion with some of the Adobe Web Platform contributors, we have decided to focus on improving the selection following the current specification. While we feel this approach may lead to a non-optimal user experience for certain use cases, we expect implementing it will help us discover the problems inherent in the current selection specification. We have also been discussing these issues with some reviewers from Apple, Ryosuke Niwa and David Hyatt, and looking for alternatives to the multi-range approach.

We have posted additional patches, one to improve the selection behavior and another to revert the current limitation of selections related to including content from different Flow Threads. We think that this approach provides better integration of CSS Regions with HTML documents. Plus, it will allow us to properly evaluate the performance issues of selection with CSS Regions.

The other challenges we faced during this collaboration include:

• changing how the selection rendering traverses the Render Tree in order to deal with the special RenderFlowThread blocks
• adjusting the block gaps filling algorithm
• clearing the selection
• selection direction issues derived from the Render Tree and DOM Tree divergence

We detected a number of other issues,  such as how LayoutPoints are positioned in the DOM Tree when pointing to Region blocks, leading to an incorrect Selection extent node.  We are confident that we will ultimately have a fully-compliant selection specification implementation for CSS Regions, but the improvements using this approach are limited. Even after solving all the issues we have detected so far, selection might still seem weird and buggy from an end user perspective. Thus we think that the final solution, one which will provide the user with a more consistent experience, will be to complement the selection specification to consider not only the DOM Tree, but also how the Render Tree is built by the Layout Model.

As part of the work Igalia has been doing on the Friends of GNOME Accessibility project, I implemented parsing the additional information present in Tagged-PDF documents in Poppler. The state of the implementation and all related issues are being tracked in Bugzilla using metabug #64813: as of today, the first patches have been landed, and the rest are expected to be moved progressively from the tagged-pdf branch to master.

What Tagged-PDF brings to the table

The PDF specification, a huge 750 page document, includes the Tagged-PDF specification, which is part of the ISO PDF/A-1a standard. It specifies how a document can:

• Describe its structure: a tree of nodes describing each entity of the document (headings, paragraphs, images, form items, etc) is provided, optionally including additional metainformation describing how the element is styled.

• A way for non-textual content to be described. Think of it as the alt attribute of <img> elements in HTML, but in a PDF document almost any element may have an alternate text (not only images).

Having access to this information is of interest to users of assistive technologies. For instance, a screen reader can inform the user about the type of information being read, whether the text is emphasized, whether it is reading a series of data from a table, and so on. But Tagged PDF support can greatly improve the experience in additional ways:

• Document viewers can provide the user an accurate outline of the elements in the document. Note that this would not be the same as the table of contents which can also be present in PDF files: the outline can be extracted automatically from the document structure, instead of being made.

• Viewers can provide means to jump around the document more efficiently and accurately: for example moving one paragraph at-a-time, skipping to the next image or table, etc. The possibilities are endless.

• Searching in documents can be more powerful. Imagine being able to search for images which contain a certain word in their description, or search only inside a table or a paragraph.

• Text extraction can be done more accurately, in particular when dealing with documents in which the page layouts are non-linear.

Therefore, implementing support in Poppler for reading all the Tagged-PDF information from PDF files is an important first step which will enable applications to provide a better user experience.

The document structure in Poppler

The main goal for the implementation was to be able to use the Tagged-PDF information in document viewers. As a result, the implementation so far does not have editing capabilities. On the bright side, being able to focus on parsing meant that I had time to make it almost 100% complete, and the parser will try to extract as much as possible from the document structure tree before bailing out—even with corrupted files or malformed tress.

Because the document structure is read-only, the objects representing it are created the first time the structure tree is accessed, and they are all owned by the document Catalog object (i.e. you do not need to delete them after using them). Iterating over the tree structure elements is very easy:

static void
handleElement(const StructElement *element)
{
        // Do something with "element". For example, print the contained text.
        if (element->isContent()) {
                GooString *text = element->getText();
                printf("%s\n", text->getCString());
                delete text;
        }

        // Visit the child elements (if any)
        for (unsigned i = 0; i < element->getNumElements(); i++)
                handleElement(element->getElement(i));
}

// ...

const StructTreeRoot *tree = document->getCatalog()->getStructTreeRoot();
for (unsigned i = 0; i < tree->getNumElements(); i++)
        handleElement(tree->getElement(i));

In addition to adding support for parsing the document tree, the pdfinfo tool has been updated and can now be used to print out the structure tree (flag: -struct) or the tree plus the text contained in the elements (flag: -struct-text). It looks like this when used with the FW-4 US tax form (the actual output is much longer):

% pdfinfo -struct fw4.pdf | tail -n + 22
Structure:
  Document (inline)
    Part "Page 1" (inline)
      Sect (inline)
        Sect (inline)
          Div (inline)
            H1 (block)
              "Form W-4 (2013)"
          Div (inline)
            P (block)
              "Purpose. Complete Form W-4 so that your employer can withhold
              the correct federal income tax from your pay. Consider
              completing a new Form W-4 each year and when your personal or
              financial situation changes."
 (...)

In order to test the implementation, I have written the pdfstructutohtml tool, which uses the structure tree to convert PDFs to HTML, trying to keep the logical structure. The output for the FW-4 form has a number of flaws because the program is simple and could use some improvements, but the generated HTML source contains the structure and basic styling, properly converted from the original document: not bad for a ~500 line program!

GLib bindings

Because the ultimate goal is to improve the accessibility experience in Evince and Documents, the Poppler-GLib binding should also expose the document structure in the API. The process for this is taking more time because, while the low-level Poppler API can be changed at any time (there is no promise of stability), the GLib binding must be stable, so Carlos and I have been iterating over it to make sure that what we provide will not need to be changed in the future (ideally).

Being a higher-level API, the Poppler GLib binding eliminates the need of two different classes for the structure: where in low-level Poppler there is StructTreeRoot and StructElement, in the GLib binding there is only PopplerStructureElement, and iteration over the tree is done using an external iterator. This approach is more consistent with other parts of the binding. Traversing the structure tree can be done like this:

static void
handle_structure_element_iter (PopplerStructureElementIter *iter)
{
        PopplerStructureElementIter *child;
        PopplerStructureElement *element;

        do {
                /* Do something with "element". For example, print the contained text */
                element = poppler_structure_element_iter_get_element (iter);
                if (poppler_structure_element_is_content (element))
                        {
                                gchar *text = poppler_structure_element_get_text (element);
                                g_print ("%s\n", text);
                                g_free (text);
                        }
                g_object_unref (element);

                /* Visit the child elements (if any) */
                if ((child = poppler_structure_element_iter_get_child (iter)))
                        {
                                handle_structure_element_iter (child);
                                poppler_structure_element_iter_free (child);
                        }
        } while (poppler_structure_element_iter_next (iter));
}

/* ... */
PopplerStructureElementIter *iter;

if ((iter = poppler_structure_element_iter_new (document)))
        handle_structure_element_iter (iter);

Here you can see the new pane in the poppler-glib-demo tool, which shows the document structure tree:

FW-4 in poppler-glib-demo

Last but not least, the GLib binding has received some additional love to add proper documentation to the new functions and to make them introspection-friendly so you can use them right away in your favourite programming language.

What's next?

The next step will be to add the needed code in Evince to take advantage of the information exposed via the document structure tree, and make use of it to improve accessibility —and usability— of the document view. On top of the improvements done by Antía, once the Tagged-PDF support lands in Poppler, my colleagues at Igalia will use it in Evince to implement the following:

• Feeding more, and more accurate, information to ATK will make assistive technologies provide better access to document content. For example, being able to extract text from particular elements in the document structure allows to send text to a screen reader one paragraph (or list item, or table cell) at a time, allowing the user to better navigate the document.

• Better tab navigation, especially in forms: traversing the document structure makes it possible to identify the logical order of form fields, instead of having to guess their order from their positions in the page.

• Navigating forms across pages: a current limitation of how Poppler and Evince work is that it is not always possible to know all the page contents before rendering the page, which makes it very difficult to know whether focus should move to the previous or next page. The document structure can be inspected to determine whether there are elements in the surrounding pages eligible to receive focus, and act accordingly.

Finally, I would like to thank Carlos García-Campos for his thorough code reviews. Of course, big thanks also to the GNOME Foundation and all the Friends of GNOME supporters for making it possible to keep improving our software stack to make it more accessible.

Last week I spent some days in Lisbon attending LXJS (Lisbon JavaScript). This was the second edition of this JavaScript conference. Considering the quality and the very positive feedback of the first edition I decided not to miss it this year.

The event was hosted at Cinema São Jorge, an old-style cinema theather located at the heart of Lisbon. It was two days packaged of talks about JavaScript. The event is structured in one-single track. There’s not much detail about the specific contents of each talk until the very last day. Instead of listing each talk individually, they are organized by topic (infraestructure, gaming, robots, etc). I particularly liked this approach. First, no stress about what talk to go. Second,  although you may not be interested in a topic, attending all talks can give you a good understanding of what’s going on in JavaScript nowadays. And if you’re not interested in a particular topic anyway, you can skip the whole block.

The quality of the talks were very good in general. Some of the speakers had participated in other JavaScript events, like JSConf EU, and most of them were international speakers, which gives an idea of the global scope of the event. Without further do, here’s a brief summary of the talks I found more interesting:

• Jed Schmidts’ Thursday keynote. If you haven’t watched Jed Schmidt’s CSSConf talk you should rather stop what you’re doing right now and watch it  (it’s just 8 minutes). Clever, witty and with sense of humor. His keynote at LXJS followed the same style.

• Robert Nyman. Review of Firefox OS. Robert Nyman is a technology evangelist at Mozilla. Good review of the current state of Firefox OS.

• Estelle Weyl. Web performance considerations in a mobile world. Good advices about how to improve performance of your mobile apps. Particularly interesting for web developers.

• Laura Kalbag. Designing for accessibility. Good reminder of what to do and what not to do for improving websites design and accessibility. If you’ve read “Don’t make think” or follow some UX course like hackdesign, you maybe familiar with most of the concepts. Good review of tools at the end of the talk.

• Jonahattan Lipps. Appium. Appium is functional testing environment for webapps and mobile. Don’t miss Jonahattan’s live performance with a guitar.

• Tim Park. Nitrogen.js. Nitrogen is a framework that makes it easier to build connected real world devices and the applications that use them. Very interesting if you are keen on domotic. Park worked at Nest, so all his experience in domotic devices is built into the Nitrogen.

• Dominic Tarr – What does “scalable” mean anyway? Good review at databases written in JavaScript, with a focus on LevelDB (which I didn’t know about).

• Michal Budzynski. Gaming in JavaScript. Michal is a Firefox OS developer and JavaScript game developer. This talk, conducted like an arcade game, gives a review at his latest work on JavaScript game developing and some of his experiments. Very nice and enjoyable talk.

• Mark Boas. HyperAudio. This is an idea that’s been around for a while. First time I heard about HyperAudio was like two years ago or so, if I remember correctly. It was good to see the effort is still alive, mostly pushed by people from Mozilla. To put it briefly, HyperAudio’s goal is to make audio a first-class citizen in the web. Think of all the audio available on the internet and how little of that content is still searchable and difficult to share. Imagine you would like to share a fragment of an interview with your favourite writter broadcasted by the BBC one-year ago. Still today, impossible to do.

• Bill Mills and Angelina Fabro. JavaScript for Science. Good talk conducted by two speakers. Bill is a physicist working at Triumf and Angelina is a experienced Mozillian. This talk is about how much software engineering good practices, which are quite adopted in the developement of open-source, can help improving science software.

• Alex Feyerke and Caolan McMahon. Hoodie. Presentation of the Hoodie framework, an interesting framework for rapid prototyping in JavaScript.

• Hannah Wolfe. Ghost. Review of the current state of Ghost, a new blogging platform built in node.js. The project counted with funding from Kickstater and it’s currently available for downloading. It looks promising.

• Vyacheslav Egorov. Performance and benchmarking. Review of what to do and what not to do when writing performance tests in JavaScript. Very nice and enjoyable to watch talk.

• James Halliday. Modularidade para todos. Good insight about the anarchich, but operative, structure and organization of npm. Very fun talk.

• Domenic Denicola. How to win friends and influence standars bodies. Title inspired by the classical book “How to win friends and influence people”. Denicola’s reflections and advices about how to interact with the different web communities (JS, Web) and keep moving the web forward. Denicola is the original author of the CommonJS specification about promises.

• Raquel Velez. NodeBots. Good introduction to hacking on robots with JavaScript.

• Andrew Hebbit. Nodecopter Hacks. Andrew is an organizer of many nodecopter events in the UK. In this talk gives a review of all the things he and other people have hacked on a nodecopter. Andrew also help with the NodeCopter event held the day after the conf.

There were some other interesting talks, specially on gaming, infraestructure and development but whether that may be interesting for you or not depends very much on your needs. This was just a brief selection of those I particularly enjoyed.

Lastly, I’d like to thank all the people involved in the organization of the event for their work, their time, the parties and for making that everything worked just perfectly; a big hug to all the people I met there during those two days and, last but not least, thanks to Igalia for sponsoring my attendance. I hope to be there again next year.

I have been putting off this post for long enough now and perhaps the internet has already written about this, nonetheless, I feel my duty to share with you my excitement about the latest release of GNOME Web, which, once again, we can proudly say it's the best release we've achieved so far. Let's see in detail why.

First of all, let's remember the evolution that Web, once Epiphany, has gone through since the second WebKitGTK+ hackfest in the Igalia offices, back in 2011. Back then, Jon, Bastien, Felipe, Xan and I sat together for an afternoon discussing the role that Epiphany would have in GNOME in the long-run, and how could we evolve, from what we had back then to what the design team had envisioned for the browser up to that point, in a way that would adjust to the six-month release cycle in GNOME, so that our users could already get, iteratively, the improvements we would be working on.

Since then, every single release of Epiphany, now Web, has brought to you changes that have spurred a bit of controversy, but in the long run, have pleased our users and also brought about new ones, proving that the iterative nature of our work has been working out well. With the 3.10 release, however, we've settled a bit the pace of the work and we've focused mostly in polishing and ironing out the details that, for diverse reasons, we had left pending. Work, as usual, is never complete, but I am happy with what we've done for the current release.

Another aspect of this release that's worth mentioning is that many of the cool changes coming with it are the work from contributors to the project other than the usual suspects, and it's been with pleasure that I have probably spent more time reviewing patches for Web than writing my own. It is pretty cool to see other people as motivated with Web as we are.

But now to the juice. What's new in Web 3.10?

DuckDuckGo as new default search engine: I have already written about this in a previous entry, but slightly over a month into the news, I can say that the reaction so far has been mixed, though mostly positive. We still need to see Web hitting the release of major distributions in order to judge better the reception, and I am looking forward to it.

New titlebar for normal and application mode: Following the designs from Allan and the rest of the design team, Yosef Or Boczko took on the challenge to rewrite the titlebar to use a style close to that of the new GtkHeaderBar, both for normal windows and for the application mode. The result is pretty awesome.

Normal window

Application mode

While we're not yet using GtkHeaderBar, due to some limitations that make it unsuitable for Web, we will try to solve this during the 3.12 cycle.

New search provider for GNOME Shell: This is a really cool feature. Have you noticed that when typing in the shell overview, not only applications come up as suggestion, but also files in your Home directory and, perhaps, even some other results? Wouldn't it be awesome if also results from your Web search history would come up? Or if you had the chance to perform a internet search right from the shell? Well, this is no longer a dream. Thanks to Giovanni Campagna, Web now ships a search provider for the Shell, which will take care of providing results for you. Click on the Web icon, next to the search history results, and a Web window will come up with fresh search results.

Results from Web's history in the GNOME Shell

The way this works is that Web now can run in a headless mode, so that whenever the shell requests results from Web's provider, this will query results from a running instance of Web. If Web is not running, a headless instance can be spawned. Eventually, we might want to split this to a separate binary to avoid the need for a headless browser and have a minimal search daemon instead, but that's still under discussion.

Form authentication revamped: Gustavo took on the task of fighting the DOM bindings and the web extension in order to bring our users something that was long due: the possibility of not only storing but also accessing form credentials for multiple usernames in the same site. Now, every time you try to log in a webform for which you've stored more than one username/password pair, a nice popup with autocompletion will show up, to help you select the right credentials.

Multiple usernames in Twitter

Favicons in the overview thumbnails: This is a small change but one that improves considerably discoverability in the overview. Judge by yourself.

Overview thumbnails with favicons

An improved WebKit2 engine: I'll keep this short and won't go into details, but thanks to the latest version of WebKitGTK+, you'll have a new Web Inspector, accelerated video compositing support, and a much more stable and mature engine. Carlos has written extensively about the WebKitGTK+ 2.2 release. Please go and read his post if you haven't already.

A new user manual: Even before we started rewriting Web's user interface, the user manual shipped with it was already obsolete, so our decision had been to remove it entirely. Thanks to the fantastic work of the documentation team, Web 3.10 is the first version in a long while to ship a user manual updated to the latest features.

Of course, there are a good deal of other fixes and minor improvements that it would be pointless to list here in detail. Please give GNOME Web a try and see by yourself. If you have feedback, rest assured that we're eagerly waiting for it, and that we expect you'll enjoy browsing the web with us as much as we've enjoyed the last six months of work.

With a bit of delay but we have finally released a new stable version of WebKitGTK+. This is the first stable release after the major 2.0 release. It mainly contains a lot of bug fixes and a few important new futures and API additions.

New Web Inspector

WebKitGTK+ now uses the new Web Inspector recently opensourced and upstreamed by Apple. We took advantage of the migration to improve the way inspector resources are distributed by compiling them in the WebKitGTK+ library as GResources. This means that resources are now always available without having to run make install or set environment variables.

Initial Wayland support

WebKitGTK+ 2.2 can be built with Wayland target if it’s available (it requires GTK+ 3.10 compiled with Wayland support). Not everything is fully supported yet, but the WebKit layout tests can be run under the Weston compositor and WebGL content works under Wayland displays too. There’s more detailed information in Žan Doberšek’s blog.

Video accelerated compositing support

When accelerated compositing is enabled, the GStreamer media player can play videos using OpenGL. You can find more details in Víctor’s blog.

Custom JavaScript injection

This was one of the major regressions in WebKit2GTK+ compared to the WebKit1 API. WebKitGTK+ 2.2 now allows to inject custom JavaScript code using the JavaScriptCore C API from a WebKit Web Process Extension. New API has been added to also allow running specific JavaScript code in isolated worlds. You can find examples about how to use this API and how to write Web Process Extensions in general in this post.

Improved accessibility support in WebKit2

Accessibility support in WebKit2 has been reworked to not depend on pango and gail, which resulted in several bugs fixed and a much better accessibility support. Check Mario’s blog for all the details.

New API

• WebKitAuthenticationRequest: This is a new object used by the new WebKitWebView::authenticate signal, that allows to implement a custom authentication mechanism (instead of the embedded dialog used by default) or simply disable HTTPS authentication entirely.
• WebKitScriptWorld: Used to inject custom JavaScript code in the main world, but also to create isolated worlds.
• webkit_uri_scheme_request_finish_error(): This new method makes it possible to finish a load of a custom URI scheme request with an error.
• New WebKitSettings: enable-accelerated-2d-canvas and enable-write-console-messages-to-stdout.

The multiprocess architecture of WebKit2 brought us a lot of advantages, but it also introduced important challenges, like how to expose some features that now live in the Web Process (DOM, JavaScript, etc.). The UI process API is fully asynchronous to make sure the UI is never blocked, but some APIs like the DOM bindings are synchronous by design. To expose those features that live in the Web Process, WebKit2GTK+ provides a Web Extensions mechanism. A Web Extension is like a plugin for the Web Process, that is loaded at start up, similar to a GTK module or gio extension, but that runs in the Web Process. WebKit2GTK+ exposes a simple low level API that at the moment provides access to three main features:

• GObject DOM bindings: The exactly same API used in WebKit1 is available in WebKit2.
• WebKitWebPage::send-request signal: It allows to change any request before it is sent to the server, or even simply prevent it from being sent.
• Custom JavaScript injection: It provides a signal, equivalent to WebKitWebView::window-object-cleared in WebKit1, to inject custom JavaScript using the JavaScriptCore API. (Since 2.2)

This simple API doesn’t provide any way of communication with the UI Process, so that the user can use any IPC mechanism without interfering with the internal WebKit IPC traffic. Epiphany currently installs a Web Extension to implement some of its features such us pre-filled forms, ads blocker or Do Not Track using D-BUS for the communication between the Web Extension and the UI Process.

How to write a Web Extension?

Web Extensions are shared libraries loaded at run time by the Web Process, so they don’t have a main function, but they have an entry point called by the WebProcess right after the extension is loaded. The initialization function must be called webkit_web_extension_initialize() and it receives a WebKitWebExtension object as parameter. It should also be public, so make sure to use the G_MODULE_EXPORT macro. This is the function to initialize the Web Extension and can be used, for example, to be notified when a web page is created.

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    g_print ("Page %d created for %s\n", 
             webkit_web_page_get_id (web_page),
             webkit_web_page_get_uri (web_page));
}

G_MODULE_EXPORT void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
    g_signal_connect (extension, "page-created", 
                      G_CALLBACK (web_page_created_callback), 
                      NULL);
}

This would be a minimal Web Extension, it does nothing yet, but it can be compiled and loaded so let’s see how to create a Makefile.am file to build the extension.

webextension_LTLIBRARIES = libmyappwebextension.la
webextensiondir = $(libdir)/MyApp/web-extension
libmyappwebextension_la_SOURCES = my-app-web-extension.c
libmyappwebextension_la_CFLAGS = $(WEB_EXTENSION_CFLAGS)
libmyappwebextension_la_LIBADD = $(WEB_EXTENSION_LIBS)
libmyappwebextension_la_LDFLAGS = -module -avoid-version -no-undefined

The extension will be installed in $(libdir)/MyApp/web-extension so we need to tell WebKit where to find web extensions before the Web Process is spawned. Call webkit_web_context_set_web_extensions_directory() as soon as possible in your application, before any other WebKit call to make sure it’s called before a Web Process is launched. You can create a preprocessor macro in the Makefile.am to pass the value of the Web Extensions directory.

myapp_CPPFLAGS = -DMYAPP_WEB_EXTENSIONS_DIR=\""$(libdir)/MyApp/web-extension"\"

And then in the code

webkit_web_context_set_web_extensions_directory (webkit_web_context_get_default (), 
                                                 MYAPP_WEB_EXTENSIONS_DIR);

The Web Extension only needs WebKit2GTK+ to build, so in the configure.ac you can define WEB_EXTENSION_CFLAGS and WEB_EXTENSION_LIBS using pkg-config macros.

PKG_CHECK_MODULES(WEB_EXTENSION, [webkit2gtk-3.0 >= 2.0.0])
AC_SUBST(WEB_EXTENSION_CFLAGS)
AC_SUBST(WEB_EXTENSION_LIBS)

This should be enough. You should be able to build and install the Web Extension with you program and see the printf message every time a page is created. But that’s a useless example, let’s see how to use the Web Extensions API to do something useful.

Accessing the DOM

The GObject DOM bindings API available in WebKit1 is also exposed in WebKit2 from the Web Extensions API. We only need to call webkit_web_page_get_dom_document() to get the WebKitDOMDocument of the given web page.

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    WebKitDOMDocument *document;
    gchar             *title;

    document = webkit_web_page_get_dom_document (web_page);
    title = webkit_dom_document_get_title (document);
    g_print ("Page %d created for %s with title %s\n", 
             webkit_web_page_get_id (web_page),
             webkit_web_page_get_uri (web_page),
             title);
    g_free (title);
}

Using WebKitWebPage::send-request signal

Using the Web Extensions API it’s possible to modify the request of any resource before it’s sent to the server, adding HTTP headers or modifying the URI. You can also make WebKit ignore a request, for example to block resources depending on the URI, by simply connecting to the signal and returning TRUE.

static gboolean
web_page_send_request (WebKitWebPage     *web_page,
                       WebKitURIRequest  *request,
                       WebKitURIResponse *redirected_response,
                       gpointer           user_data)
{
    const char *request_uri;
    const char *page_uri;

    request_uri = webkit_uri_request_get_uri (request);
    page_uri = webkit_web_page_get_uri (web_page);

    return uri_is_an_advertisement (request_uri, page_uri);
}

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    g_signal_connect_object (web_page, "send-request",
                             G_CALLBACK (web_page_send_request),
                             NULL, 0);
}

Extending JavaScript

Using the JavaScriptCore API it’s possible to inject custom JavaScript code by connecting to the window-object-cleared signal of the default WebKitScriptWorld. You can get the global JavaScript execution context by calling webkit_frame_get_javascript_context_for_script_world() for the WebKitFrame passed as parameter of the window-object-cleared signal.

static void 
window_object_cleared_callback (WebKitScriptWorld *world, 
                                WebKitWebPage     *web_page, 
                                WebKitFrame       *frame, 
                                gpointer           user_data)
{
    JSGlobalContextRef jsContext;
    JSObjectRef        globalObject;

    jsContext = webkit_frame_get_javascript_context_for_script_world (frame, world);
    globalObject = JSContextGetGlobalObject (jsContext);

    /* Use JSC API to add the JavaScript code you want */
}

G_MODULE_EXPORT void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
    g_signal_connect (webkit_script_world_get_default (), 
                      "window-object-cleared", 
                      G_CALLBACK (window_object_cleared_callback), 
                      NULL);
}

The primary objective of the Friends of GNOME Accessibility project is to improve document accessibility.  As part of this effort, Igalia has been working in several areas related to PDF documents, focusing primarily on Evince and poppler .

Keyboard navigation in Evince

Caret navigation is more than just a enhancement for users who prefer it over  the mouse; it is an essential need for users who are blind or visually impaired. Orca users, for instance, interact with software and  information by moving to the thing they want to read. In the case of  accessing document content, that requires the ability to move amongst  the paragraphs, lines, words, and characters. As they do so, Orca presents the new location via synthesized speech and/or refreshable braille. Likewise, using a mouse to select regions of text is extremely difficult if you cannot see where you are on the screen.

For users with low vision, having to use the mouse frequently to move the content into the magnified view can be extremely tedious, especially at high degrees of magnification. These users will also benefit from the  addition of caret navigation to Evince — as soon as the long-awaited caret and focus tracking support is added to GNOME Shell’s magnifier.

During the last few months, Carlos and I have been working on the implementation of caret navigation. I am happy to announce that it is available starting with Evince 3.9.5.

As with other applications, caret navigation can be activated by pressing F7.

Using the following keys you can navigate through the document:

• Left/right arrow keys: to move the cursor one character to the left/right from the previous cursor position.
• Up/down arrow keys: to move the cursor up/down one line.
• Ctrl + left/right arrow keys: to move the cursor to the beginning/end of the previous/next word.
• Home/End keys: to move the cursor to the beginning/end of the current line.

To select the text you can use the keys above + press the Shift key.

The  implementation required some improvements in poppler, thanks Carlos, before the routines to navigate and select text in Evince could be developed. Some improvements are still in progress: poppler gets confused around tables and columns and users are not yet able to move the caret one page up/down using Page Up/Down keys. But we hope to have these issues fixed soon, along with finishing the implementation of Tab access to form fields and links so that all users can quickly and efficiently access these items.

Tagged PDFs

A “tagged” PDF document is one that includes structural and semantic information which, if exposed to assistive technologies, greatly improves the accessibility of the content. While tagged PDFs are not widespread, they are often found in documents which are required by law to be accessible.

For users who are blind, it is often desirable to be able to navigate amongst document elements such as headings, paragraphs, and tables, in much the same way that sighted users visually scan through headings to locate paragraphs about a desired topic. For these reasons, Orca and other screen readers typically include navigational commands to move more quickly amongst these objects than native caret navigation provides (e.g. jump to the next heading). Orca has these features in place, but because in Evince the entire document is exposed as a single accessible text object and lacks of the structural and semantical information provided by tagged PDFs, navigation amongst elements is not possible. Our plan is to fix that so that it becomes possible.

Having said that, the benefits of tagged PDF support extend far beyond Accessibility and include:

• Reflow functionality
• Export to other applications with format, layout, font data, etc.
• Copy and paste to other applications with some fundamental retention of content format.

As poppler lacks of support for tagged PDFs, and as first step, Adrián Pérez has provided the patches to implement it in poppler. His work is available in the tagged-pdf‘s branch waiting for review.

Continuing this path, during the next few months Igalia’s Accessibility team will focus on a major and needed rework of Evince’s accessibility. Upon completion of this work, Evince will be able to expose document content as discrete accessible objects with a significant amount of structural and semantic information, instead of having a single text object for the entire document. This, in turn, will make it possible for Orca and other assistive technologies to provide truly compelling access to PDF document content.

Finally, thanks to the GNOME Foundation and the Friends of GNOME supporters for their contributions towards making a more accessible GNOME.

 

Today, we have switched the default search engine in Web from Google to DuckDuckGo. This change might come up as a surprise, but there are a handful of reasons why this actually makes sense:

• Privacy: the GNOME project has decided, since that enlightening keynote by Jacob Appelbaum in GUADEC 2012, to make an extra effort towards ensuring users' privacy, and we, the Web developers, believe we need to align with this goal. Using Google's search engine by default is counterproductive to this effect, unfortunately. I assume I don't need to go into details on the many ways in which Google tracks what their users do. DuckDuckGo, on the other hand, does not collect or share personal information.

• Cooperation: It's been some time now since we were first contacted by DuckDuckGo regarding the possibility to partner with them in order to share a percentage of the revenue that they make from the traffic originated on their search engine links, should DuckDuckGo become Web's default search engine. We discussed this possibility extensively, among the Web maintainers, within Igalia, and with the GNOME Foundation Board. In the end we all agreed that Igalia was the most suitable partner for this cooperation due to its commitment not only to advancing WebKitGTK+ and Web, but also to enabling the community through events like its yearly WebKitGTK+ hackfest. We believe that whatever revenue that might result from this partnership with DuckDuckGo will surely be a contribution to these efforts. Then again, knowing the humble size of our userbase, we should let neither our expectations nor our imagination run wild on this front.

• It works: as this is something that we've been debating for pretty long, I've spent this time using DuckDuckGo as the default search engine on my own machines, and I am happy with the results it gives. It even has pretty handy keywords that you can use to directly search in Wikipedia (!w), Amazon (!a), or even Google if you still need it (!g). I do believe the Spanish translation of the website could use some love, but their community platform is probably a good starting place for anyone interested in contributing with more and improved translations.

As is usually the case with noticeable changes, I expect that not everyone will be entirely happy with it. But that is no reason to panic:

• This partnership is for a limited time, and we will evaluate whether its continuation makes sense, in the long-term. The feedback we receive from our users will naturally have an impact on whatever decision we make in this regard.

• If you can't stand this, you can always customize the search engine used, choosing whatever suits you best. Simply follow the instructions as documented in the wiki.

• If you have already customized your search engine, don't worry, this change won't affect you unless you go back to the default.

This change, already in master, will only affect Web from 3.10, to be released in September. Now I should go back to merge a few more changes and make a beta release. Enough said, happy browsing!