Last week, the SVG Working Group held our annual Sydney face-to-face meeting hosted by CiSRA. This was the first F2F with a representative from Mozilla attending. It’s encouraging to have a second major browser implementor actively participating now!
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.