Alp Toker

If you’re running a WebKit nightly, your browser supports two new ways of specifying custom fonts.

CSS2 ‘WebFonts’

With WebFonts you can define custom font faces by passing a URL to the font file:

@font-face {
  font-family: 'Bitstream Vera Sans';
  src: url('http://www.freedesktop.org/~alp/tmp/Vera.ttf') format(truetype);
}
 
h1 {
  font-family: 'Bitstream Vera Sans', sans-serif;
}

The font gets downloaded and used without installation. A List Apart has some fancy CSS Zen Garden examples showing off the feature:

Now that the WIP Acid3 test requires TrueType/@font-face support, I expect other browser engines will be quick to join Opera and WebKit in implementing this.

SVG fonts

Then there’s the recently added support for SVG fonts.

When #16880 lands, it’ll be possible to use SVG fonts not only in SVG content, but also as a standard WebFont format with @font-face:

@font-face {
  font-family: 'SVGraffiti';
  font-weight: normal;
  font-style: italic;
  src: url("SVGraffiti.svg") format(svg);
}

This is still under development but works remarkably well. Nice work, Nikolas!

SVG font backend for Cairo

SVG fonts aren’t just for the Web — work is under way to make it possible to use them throughout the desktop with the experimental SVG font backend for Cairo. More on this coming very soon.

Checking it out

Building WebKit/GTK+ is now easier with the newly introduced autotools build system. Try the build instructions on GNOME Live! or just use jhbuild (module ‘WebKit’).

The word is out. I’ll be coordinating with Epiphany developer Christian Persch to see how the GTK+ team can put Web functionality in or alongside the UI toolkit in the weeks leading up to the GTK+ Berlin hackfest 2008.

We’ll be studying existing toolkits featuring Web widgets and considering what changes might be necessary to support something like a GtkWebView. Some possible lines of investigation include:

• A shared HTTP stack
• A standardised GObject/C API representation of the DOM
• The provision of editing capabilities
• A generic inline search toolbar

My personal interest is in GTK+ integration, favouring native GTK+ styling and event propagation. (Let’s put an end to ‘Linux’ themes.) Our agenda will tie in with other topics to be discussed at the hackfest including vector-based UI styling which could address the needs of modern content engines like WebKit and Gecko.

Improved HTML5 canvas support

Brent Fulgham has been merging Cairo graphics backend features from the Adobe Apollo/AIR branch of WebKit (#16558, #16577, #15382). The Adobe developers have been cooperative and their code is well-written — hopefully they’ll start merging their own work soon. This puts the graphics backend a couple of weeks ahead of schedule (the original target was GNOME 2.24):

Acid2

Luca Bruno has provided the last (#16365) in a series of fixes to get the Acid2 smiley face rendering correctly. This should help dispel rumours that the WebKit/GTK+ team is dropping acid.

Image decoder enhancements

Google engineers have contributed a handful of improvements (#15974, #16169) to WebKit’s image decoders, which will be shared between the GTK+ and Android ports.

Mobile features designed for Android can also now be easily enabled in the GTK+ port (eg. LOW_BANDWIDTH_DISPLAY support, r28960). It’s great to see cooperation on features like this.

Trunk open for Maemo/Hildon

The Maemo/Hildon mobile platform (used in Nokia internet tablets and Ubuntu Mobile) is now an official component of the GTK+ port. This means that these libraries can be used directly in WebKit instead of being maintained out of tree.

The JavaScript engine has seen recent optimizations which bring it further ahead of the stock browser shipped in OS2008 for the N800/N810 devices. Check out any of the freely available JS/AJAX benchmarks if you’re interested in performance.

GtkPrint

Initial printing support (#15576) has landed. Cairo’s paginated surface API lacks some features we need to implement this fully. I’ve posted a proposal for new API that will be useful in matching the print functionality of the Mac and Win ports.

What do you get when you take WebKit/GTK+, add GStreamer and finish off with a sprinkling of code from Clutter?

Pierre-Luc Beaudoin of Collabora has been working on a GStreamer-based media backend for WebKit.

Last week, we landed his work (#16145), which adds support for the WHATWG HTML5 video/audio specification allowing streaming media to be embedded in web pages without the need for plug-ins.

The last couple of days, I’ve been integrating this media backend with our Cairo-based graphics pipeline (#16356). The result is that streaming web video can now be CSS transformed, embedded in SVG, bounced around the page and generally manipulated with JavaScript.

And the screenshot? It’s a video (one of many GUADEC flicks rescued by Thomas Wood) of Federico talking about Sabayon, played back natively in Epiphany at an angle of 45° and with an alpha value of 0.6.

The semi-transparent user controls superimposed on the video are defined entirely in HTML/CSS complete with animated transition effects (WebKit-only right now, other browsers will fall back gracefully).

Exciting stuff!

In the last month, we’ve started to look more seriously at the WebKit public API and how it fits with GLib/GTK+ principles. Some of the fixes have been obvious:

• #16174: Use “URI” not “URL” in public API
• #15691: The main widget should be called WebView, not Page

Policy changes have been made to ensure consistency:

• Any public entry point, property or signal that does not match GTK+ conventions is now considered a Major bug alongside security issues and crashers (with some exceptions like the new portable JavaScript engine C API (#15687) — more on this in my next post.)
• Any new API contributions without corresponding GTK-Doc documentation will be rejected. Enough said.

The Hacker’s guide to WebKit/GTK+ now covers topics such as API design, patch contribution and optimisation (including Cairo/SVG/canvas performance and memory reduction).

Sources of inspiration

GtkTextView

GtkTextView has a solid design and well-understood data model thanks to its heritage, being a synthesis of the venerable Tk text widget. Some applications like Tomboy are starting to push the limits of GtkTextView as they look towards integrating rich media and Web content synchronisation.

Challenges:

• Can we provide a GtkTextIter implementation that works with the W3C DOM (and our upcoming GObject DOM binding), or is the concept of GtkTextTags too limiting to make this worthwhile?
• How faithfully can we bridge between Markup and HTML?

GtkMozEmbed

GtkMozEmbed is a thin binding around a stable and mature browser engine, Gecko. The primary consumers here are Epiphany, Devhelp and Yelp. To make serious use of the underlying engine, these applications have to resort to C++ and Gecko’s internal APIs which can be inconvenient.

GtkMozEmbed seems to be awkward on non-X backends since it just uses the Mozilla port for that platform, not a GTK+ backend. WebKit/GTK+ on the other hand supports all GTK+ backends natively including DirectFB, OS X and Windows. Looks like there is nothing much worth keeping from the GtkMozEmbed API, but we’ve gained valuable insight from the ways in which developers have struggled to use it.

Challenges:

• Accessibility: We have several accessibility features, but no formal accessibility using ATK. Contributions here are welcome, otherwise I’ll look into adding support in a few weeks.
  • #16135: We’re adding caret-based browsing support straight into WebCore.
• Patches already available but not yet integrated:
  • #15610: International/complex text rendering support using Pango. The Imendio guys are working to complete and integrate my initial work on this feature.
    
  • #14120: Input method support using GTK+ input methods
  • Inline search API (Update: Adam Roben from Apple has pointed out that this can be worked around by calling into window.search using the JS C API for now)
  • #15576: GtkPrint support using Cairo

GtkHTML

GtkHTML is used primarily in Evolution. Again, there is nothing much worth keeping from the GtkHTML API as far as I can tell. WebKit now has excellent editable content support and exposes necessary public API for basic editing. Complex modifications will soon be possible using the GObject DOM, but until then, the DOM can be easily manipulated using the JavaScript C API (more on which soon).

Challenges:

• emacs keybinding support using GtkBindingSet (see also #15911). Perhaps an emacs user can provide this?

Is your application hitting limitations in these text viewing/editing components? Any that I’ve missed? Do speak up now so we can cater for your use-case in WebKit!

In my talk at LCE 2007, I touched on the issue of proprietary branches and their effect on developer morale.

On the WebKit/GTK+ team, we’ve had to deal with this issue a few times.

• A year ago, Adobe promised great new graphics features from their AIR fork of WebKit that never materialised. We chose to redouble efforts to improve the open Cairo graphics backend instead of sitting about waiting for their contributions, a decision that has paid off.
• More recently, a company has been working on a largely proprietary fork of the browser called OWB. It is remarkable that, looking at some of their recent code drops (which cannot be easily merged back to trunk due to refactoring), they still have bugs and performance issues that we fixed in WebKit trunk several months ago. It’s sometimes unpleasant to implement features that others are working on behind closed doors, but we do it in an open forum with peer review. What’s more, we do it better.

Fast forward, November 2007

Today, Google announced that it’s developing a WebKit-based browser as part of its Linux-based Android mobile platform.

In the hours since this news came about, contributors have already started to ask whether their work is about to be obsoleted or replaced by a Google code drop. It’s inevitable that there will be some overlap.

I’d like to make it clear that we’ve already discussed this scenario, and it’s life as usual for the GTK+ port. If there are contributions to components of the GTK+ port, they will be reviewed through the same processes as any other contribution.

Furthermore, it’s likely that WebKit/GTK+ already has superior graphics capabilities to any forked browser since we’ve been tracking the very latest features including recent SVG updates, CSS transformation and CSS animation support. Another WIP feature of particular interest to mobile devices is the upcoming full page scaling support.

With current efforts to bridge Web applications and the underlying platform and research into features like bridging JavaScriptCore to D-Bus and other frameworks, it’s likely that we are also ahead of the game in the Web-as-a-platform department.

All that said, I look forward to working together with the developers of the Android platform towards a more open and flexible mobile Web!

A friend pointed out a slightly confused post by a Mozilla developer regarding WebKit/GTK+.

I don’t really care much for browser wars, but since this post touches on so many aspects of the browser that I’m working on, like Cairo graphics, native widget styling, transparency and complex script support, I thought I’d give a reply.

• WebKit/GTK+ doesn’t really attempt to compete with Mozilla or Firefox in the browser space. It instead targets application developers who want a full-featured browser engine with a fun, powerful GTK+-style API. gtkhtml and gtkmozembed have proved to be inadequate, too heavy or un-portable.
• In the mobile and embedded space, WebKit/GTK+ is mostly competitive with Opera and NetFront rather than Gecko. I can think of only once that a vendor has come along and asked how it compares to Gecko on mobile devices.
• We’re working with the developers of general purpose browsers like Epiphany and Midori, as well as domain-specific Web applications like the GNOME documentation browser Devhelp, and mobile platforms like the Maemo browser EAL and OpenMoko’s browser and feed reader to make sure WebKit can provide all the features they need. It turns out they don’t need a UI toolkit like XUL since GTK+ provides the functionality they need, so we aren’t attempting to bundle a toolkit with our browser engine.
• WebKit/GTK+ is not tied to Linux. It’s portable to OS X and Windows. Behaviour on those platforms is intended to be similar to that on Linux, and the API on all platforms is identical.
• It can render that “Hello” button correctly. It also supports a bunch of fancy features from HTML5 and CSS3 that Gecko does not and loads pages faster before optimisation work has even started, but I don’t think we need to go into a feature-for-feature debate here.

An application hosting OS X Dashboard widgets (widgets can store data locally using HTML5 client-side database storage):

An implementation of Freedesktop notifications using Growl WebKit styles (incidentally, work is ongoing to provide integration with various Freedesktop specifications where appropriate):

An example of native widget styling:

glyph-pixmaps

Carl’s glyph-pixmaps work has been merged to xserver. This provides a speedup for text rendering by hashing and caching glyph data to avoid constant re-uploads. Eric Anholt breaks it down for us.

Cairo and XShm

Shared memory has had a bad rap when it comes to X11, and it’s been found in the past that it doesn’t provide a significant performance benefit over sockets at the transport level (SMT).

However, when it comes to image data, XShm can provide a “sensible performance optimization” by avoiding gratuitous copies. To take advantage of this, you need to do a little work to ensure that the data can be shared directly with the X server. Chris Wilson has just proposed a patch to support this in Cairo.

WebKit and complex text

I’ve started work on support for complex text in WebKit/Gtk+ using Pango. This includes support for non-Western writing systems.

To continue today’s performance theme, it’s worth noting that WebKit provides two code paths for text rendering:

1. Blazing flast: Known as the CG path on OS X, this path caches glyph data and avoids expensive computations wherever possible. In the GTK+ port, this code path requires direct use of the font-system on every supported platform. Luckily, it turns out the WebKit code base already has optimised text implementations for several platforms, which we can just borrow and plug in to our own port.
2. Fast: The ATSUI path on OS X, this path is capable of complex text rendering, while still providing opportunities for caching layout information from previous text runs. Here, we use Pango, along with a few clever tricks.

A heuristic is applied to detect which code path can be used. Since the capabilities of Pango are slightly different to ATSUI, this may yet need some tweaking to avoid more fallbacks then are necessary.

WebKit/Gtk+ gets a reviewer

I am now an official WebKit reviewer. This should help speed up development of the Gtk+ port. Thanks go to Apple and the WebKit team!

Canvas support using Cairo

A few hours ago I landed support for the Canvas HTML element, rendered using Cairo (just like everything else in the browser engine, including ordinary content and SVG graphics). This feature paves the way for significant bling, with WebKit having been the originator of the Canvas standard for use in the Mac OS X Dashboard.

This screenshot demonstrates some dynamic frame/rotation/shadow effects applied to an image on the Web.

Public API refactoring

I’ve now re-factored WebKit/Gtk+’s public API so that the types are named WebKitPage, WebKitFrame etc. This looks and feels a lot better than the old naming convention, and is part of an ongoing effort to provide an elegant and seamless GObject C API for the browser engine. I’ve also updated the Epiphany browser and the EAL wrapper to track these changes so disruption to these projects should be minimal. If you are not having fun embedding WebKit/Gtk+ in your application we’ve done something wrong!

A special thanks

Mark Rowe (who works at Apple) can be considered godfather of the Gtk+ port. He has provided unfaltering enthusiasm and patch review since I started hacking on the browser over a year ago, and last night stayed up till 5AM making sure the Gtk+ port worked on the upcoming feature branch. Earlier that day, he had been hacking on GdkPixbuf image and animation loading support (which has unfortunately stalled since the GdkPixbufAnimation API is something of a black box).

Moving on

In other news, I’ve left Collabora Ltd. for something completely different. Do try to avoid sending email to my old work address. I believe they are hiring someone to continue their WebKit/Gtk+ contracting business. (Other aspiring GNOME companies that have started to contribute to WebKit/Gtk+ include Imendio and Igalia.)

P.S. I left a little treat for you guys in the office

Just about two years ago when I was living in Edinburgh, university researcher Harry Halpin and I set up a space in the basement of an old church/the Forest Cafe with the goals of promoting and supporting Free Software and independent media. Within a few weeks, I’d sat down with colleague Ronan Huggard, and after an all-night brainstorming session, came up with a name for this rapidly growing organisation: InfoSeed. The name embodied the ethos of the group, which existed to sow the seeds of information, allowing technology enthusiasts and independent journalists to work together and get things done.

Perhaps the most important aspect of InfoSeed for me was that it broke the hegemony of the university in matters of computing and opened its doors to the wider community. As former president of the Edinburgh University Computing Society, I’d seen first-hand that, while our constitution did cater for non-students, university societies were simply not set up to support local Edinburgh residents and passers-by in the same capacity as they were able to accommodate students themselves. In this way, societies were a dead end to me, kind of an in-club for those who were studying at the right place at the right time. InfoSeed was my chance to get things right, second time round.

I hope to blog in the future about the history of InfoSeed including its formation around the time of the G8 Gleneagles summit, the development of excellent IT infrastructure on a shoestring budget, the software we used and wrote, the physical restoration of a dank undercroft into a warm and welcoming walk-in centre for Free Software and Open Source enthusiasts, open six days a week with scheduled opening hours, the events we hosted, and our relations with other like-minded organisations.

Then there are the stories of how we got dozens of Linux laptops to African schools, how we weaned journalists off proprietary office suites and audio/video editing software, how we showed countless passers-by that the world of computing was not incompatible with their desires for world peace, saving the whales or whatever personal aspirations they happened to have in life; that computing, programming and technology are in fact very human and social persuasions.

Each of these is an epic tale, and would ideally only have been the first chapter of a much greater work. However, unless something changes I will have to refer to InfoSeed in the past tense since, today, I’m having to write about the imminent closure of the InfoSeed Free Software lab. If you live in Edinburgh, are studying there or have any interest in this kind of space, do drop by and check it out while you still can. Money may be most helpful (InfoSeed as an organisation is no longer able to pay the bills for the two rooms it’s based out of), but fresh blood and enthusiasm would be welcome, since with new faces and ideas there is a case for raising more funds and thus a stay of execution. The InfoSeed website and mailing list are the first points of contact if you want to get in touch.

If the doors of InfoSeed do close for the last time, it will by no means have been a failed experiment, but a great success that spread free and open computing to people who would otherwise never have heard of it, and one that has touched the lives of the volunteers who put in so much time and effort (verging on the obsessive in some cases, you know who you are!). I wonder if InfoSeed could continue function as a disembodied Internet forum, or whether its entire value — what made it a first for Scotland — was that it was a physical venue with real people willing to work together in the same place to show the world that there’s more to computing and technology than they ever imagined?