The name and logo seemed familiar, but I couldn’t quite put my finger on it.

Below is a summary of the discussions surrounding the major topics that we covered over the five days.

Mapping

The Japanese chapter of the SVG Interest Group is working on a module for mapping functionality in SVG. Fujisawa-san explained that this would comprise four new features — layering, tiling, level of detail and z-index — and the question was put as to whether the WG would want to take on LoD and z-index and develop them as general SVG features. On the face of it, these seem like useful additions (and I’d be happy with LoD functionality being available to help with the creation of adaptive diagrams), but the timeframe that the SVG IG JP were looking at having these done by was probably unrealistic, just because of the limited number of active people in the WG and how much time they have to work on spec writing at the moment. However, even if the SVG IG JP were to include these features in their mapping module, we could still port them over to the main SVG spec at a later date.

3D Transforms

We spent a bit of time discussing the SVG Transforms module and requirements document, and we plan to publish a first draft of these very soon. It seems that the CSS WG will be publishing their 2D and 3D transforms modules soon, too. There was a strong desire for the SVG and CSS specs to be aligned as closely as possible, but there are some aspects of the CSS Transforms specs that seems to be incompatible with SVG (such as their ‘transform-origin’ property having an initial value of “50% 50% 0″).

CSS Transitions and Animations

Another couple of specs to come out of recent Apple proposals to the CSS WG are Transitions and Animations. Animations overlap with existing functionality in SVG, while Transitions provides some simpler ways to specify simple animations of properties between two values. The SVG WG obviously wants these to be aligned with existing SVG SMIL animation functionality as possible, so that implementations can share as much common code between the two features as possible. Currently, CSS Transitions and Animations are somewhat underdefined in terms of how the changed property values are actually effected, so it is not possible to tell how they will interact with concurrently running SVG animations. We collected some comments related to this and will be sending these in soon, too.

Compositing

The Compositing module, which provides support for using Porter-Duff compositing operators and the extended blend modes from PDF when painting SVG elements to the canvas, is just about ready for publication (as are the corresponding requirements and primer documents). This was originally part of the old SVG 1.2 Full draft.

SVG 1.1 errata

Some progress was made on the SVG 1.1 errata document. I had hoped that all actions related to the errata could be complete by the end of the meeting, but it seems there are still a few to be done. Once they are complete, the plan is to publish a second edition of SVG 1.1 that incorporates all of the changes proposed in the errata document. If I get time, I’ll look at generating the second edition spec using the same build scripts we used for SVG Tiny 1.2, which, among other things, will give us much more useful element and attribute list appendices than those in 1.1 [1] [2].

SVG in text/html

We spent a whole day discussing the inclusion of SVG in text/html parsers (as is being proposed for HTML 5, but I’d say that it was a very fruitful discussion. We started with a summary of the current HTML WG’s proposal (as commented out in the HTML 5 spec currently) and discussed these point by point. Erik dutifully compiled our views and will be summarising and mailing off our comments to the HTML WG soon.

Vector Effects

Virtual Chris (who had shifted himself into UTC+11 despite remaining in France) led us through a discussion of the upcoming Vector Effects module (and primer), which is another module that has been extracted from the SVG 1.2 Full draft. This should be published soon, once Chris has made a few edits based on the group’s comments.

Layout

The requirements document for layout functionality in SVG was at a point where it was worth discussion in the group, so we spent a few hours on that. Generally, it was noted that layout is something that authors have been wanting for a long time, but we didn’t manage to get consensus on exactly what kinds of layout specification methods we want to support. Layout containers, something like what is supported in UI widget libraries, was one that had support from all the members of the group in attendance, but allowing expressions to specify lengths and depending on a length on a different object (to allow relative positioning of objects) didn’t. After filling out the terse use cases in the requirements document, and taking into account the feedback from the meeting, we’ll be publishing it as a first public working draft.

SVG Print

After having a Last Call Working Draft published a year ago, the SVG Print module has been languishing without much progress. It basically provides two features: multiple pages, and colour management. In the module, these are positioned as things that could be implemented in a printer (or print driver) to allow SVG to be used as a page description language. However, they would be useful in other contexts as well, and there has been interest from Inkscape and Scribus (I believe) in having these features mature more quickly. We decided (pending Canon’s approval, since they were the ones driving this spec mostly) to split these two features out into separate documents and to have them specified with less of a focus on being implemented in printers. This will hopefully let us advance them more quickly.

Automated testing

On Friday, Jonathan gave an overview of how reftests work in the Mozilla codebase. Reftests are rendering tests that, rather than relying on a single rendering to perform a pixel-wise comparison on to determine if a test has been passed, instead usually use another SVG document to use as the basis for generating the reference raster image. This helps to account for valid differences in rendering between platforms or implementations. Jonathan suggested that we adopt this testing methodology in the SVG test suite so that we can automate testing. His idea is that with a common format for automated reftests, vendors could allow end users to run the SVG test suite easily and quickly on a public build of their implementation.

The advantages of this would be threefold. First, everyone can easily verify test suite conformance and note how conformance is increasing, providing pressure on vendors to improve their implementations. Second, it would make it easier for members of the public to contribute tests. Third, by making it easy to write a harness that can run the automated test suite, it will help those vendors with fledgling or non-existent implementations get up to speed more quickly. As it stands, the current SVG test suite includes reference images that have been rendered with Batik. Each implementation basically needs to generate their own renderings to test against, making it non-trivial to run the SVG test suite in an automated fashion. By providing SVG reference documents instead of raster images, the reference renderings can be generated by each implementation without much manual intervention.

Speaking of thecal matters, I must congratulate Peter Sbarski (one of my officemates) and Nathan Hurst (a former officemate) on their end-of-year submissions. Nathan started his PhD a couple of years before me, so it was always comforting in a way, knowing that regardless of the time I’ve spent at Monash working on this thing, that I wasn’t breaking some sort of record. Now that he has submitted, I can really start my stopwatch and get on with it!

A couple of W3C publications were made just before Christmas that are worth mentioning from my perspective:

• SVG Tiny 1.2 was published as a Recommendation. Considering that the first draft of what was then known as SVG 1.2 was published in late 2002, it certainly is satisfying to have it finished so that progress can be made on other things within SVG working group. While not everything in SVG Tiny 1.2 will appeal to the desktop browser vendors, there is much from SVG 1.1 that has been clarified and improved upon that still deserves attention. Also, check out the delicious PDF produced using Prince!
• Web IDL had another working draft publication. Most of the changes since the last draft have been to bring the ECMAScript bindings closer into alignment with reality, and to add some more extended attribute hooks for use by other specifications, such as HTML 5. The next publication will be a last call working draft, by my estimates.

In related news, I’ve been appointed co-chair of the SVG working group from the beginning of 2009, taking over from Andrew Emmons, who has done a fine job herding us all into getting SVG Tiny 1.2 out the door. Erik Dahlström from Opera is continuing in his role as the other co-chair.

In response to implementor feedback, the Connection interface of SVG Tiny 1.2 is gone. Connection always was a controversial interface, with many commentors pointing out that it shouldn’t have been something that SVG defined. At the time it was introduced, long before I was a member of the working group, there really wasn’t another forum that was appropriate for a network interface to be specced, so I can understand why it was, especially as, despite the views of some people, SVG really was (and is) being used an application platform, and not just a static graphics language. The Network API spec in the WebApps WG isn’t really progressing, but there is some new, similar work happening in HTML 5, so I hope that these become unified.

The arrangement of the Global and SVGGlobal interfaces in the SVG Tiny 1.2 uDOM is being cleaned up to fit in better with other specs. So instead of SVGGlobal inheriting from this empty Global interface, we’re going to state that the default AbstractView object (i.e., the global ECMAScript object) also implements SVGGlobal, and not make SVGGlobal inherit from anything. This parallels the way HTML 5 defines Window.

The ’static’ property from the old SVG 1.2 Full draft will be making a comeback in 1.2 Tiny in some form, in response to requests from implementors.

We had an interesting discussion on layout functionality that we’d like to see in the new Layout module (which is the primary reason I’m here). There seems to be support in the group for some high level layout container support in conjunction with some lower level layout control specifications, such as expression-based positioning of objects.

John Daggett from Mozilla dropped in for a day and gave a presentation on the CSS3 Fonts draft, including an engaging overview of the background and technical issues surrounding web fonts. (And I must say that that spec is one of the most visually pleasing documents I’ve seen come out of W3C for a while.)

SVG Open 2008 begins tomorrow, and for a change, I’m not presenting anything. Here’s hoping attendance is up on last year!

jet:~ $ history | awk '{a[$2]++} END{for(i in a){printf "%5d\t%s\n ",a[i],i}}' | sort -rn | head
  8906  ls
  8441  cd
  5230  vi
  3902  date
  3671  fg
  1379  svn
  1236  make
  1143  ssh
  1052  mplayer
   755  cal

Looks pretty accurate to me, although I’m surprised mplayer is that high in the list.

Not that it matters who “wins”, but it is some fun, healthy competition for web standards compliance. No really, it is!

Although I do find it funny that a bug that Maciej found in my test means Opera shouldn’t really have scored 100. But anyway, congratulations to Opera and WebKit for getting full marks!