SVG Open 2011
22 October 2011
These are my notes from the four-day SVG Open 2011 conference in Cambridge, Massachusetts. What follows are my own thoughts on selected talks. This does not attempt to be an objective record by any means.
Google Docs: Building Full Scale SVG Applications (Igor Kopylov)
Text elements (both in HTML and SVG) render at slightly different sizes on different browsers and platforms. Often these differences are just a pixel or two, but they can cause a cascade of wrapping which can result in very different layout between users. This becomes a major issue in a collaborative environment such as Google Docs when users disagree on how a document is laid out.
One solution was to render the text on the server and return SVG paths of the outline of each character to the client. This scheme provides pixel-perfect consistency since there is one authoritative renderer and the clients are not involved at all in the layout. One downside is that server interaction is required, which introduces latency. Another downside is that the DOM becomes very bloated since character outlines are orders of magnitude more complex than raw text. Yet another downside is that the text is no longer searchable client-side since the text is not text.
A compromise solution is to render the text on the server and return the x/y coordinates of the start of every word. The client can print the text as text, with each word anchored at an absolute position. There are slight inconsistencies, in that words might be a pixel or two longer or shorter on each client, but wrapping will always be consistent. Searchability is semi-restored, in that every word exists in the DOM, even though they are not logically connected.
SVG support in Adobe tools (Gaurav Jain)
A preview may currently be downloaded from http://labs.adobe.com/technologies/edge/
Even faster web mapping (Michael Neutze)
This talk raised the issue that creating a boundary between two areas can be done one of two ways. Consider the case of drawing a map of North America, with the US/Canada border displayed. One way is to draw a polygon to represent North America, then draw a line that separates the two countries. The problem with this method is that the two countries can't be filled with different colours since North America is a shape, but the US and Canada are not. The other way is to draw separate polygons for the US and Canada, with the border made up of two lines (one from each country) that are on top of each other This method does allow for different fill colours.
Drawing separate shapes for each area results in problems when the map is optimized for a particular resolution. The raw map data might be extremely detailed, with thousands of data points along the border. Optimizing this map for Internet download involves running various off-the-shelf algorithms to prune data points that make little difference at the resolution one intends to display the map at. Unfortunately, if the border is made up of two lines that are on top of each other, the optimization algorithms will often make different changes on each copy, resulting in some overlaps and some gaps between the countries.
The talk specifically did not fault the resolution-optimizing algorithms found in the existing SVG editors (such as Inkscape). Instead the fault was placed on SVG itself for not supporting shared paths. The presenter requested this feature be considered in the next version of SVG. While I agree with this in theory, I was left wondering how difficult it would be for optimization algorithms to recognize the presence of shared edges and simplifying both edges so that they stay in sync with each other. After talking with the authors of Inkscape, we were unable to conclude whether this would be easy or difficult to fix, since we were not sure exactly where the divergent optimizations were coming from. More data is needed.
SVGo: a Go library for SVG generation (Anthony Starks)
There isn't much to say about this library, it does exactly what it says on the cover and it does it really well.
Go code: svg.Rect(0, 0, 100, 50, "fill:none; stroke:black") SVG code: <rect x="0" y="0" width="100" height="50" style="fill:none; stroke:black" />
Simple, clean, intuitive. https://github.com/ajstarks/svgo
Microsoft Internet Explorer 10 (Patrick Dengler)
Despite being hosted by Microsoft, IE had a relatively low-key presence at this conference. Firefox, Chrome, and Opera dominated the demos. The only time IE was used in any SVG demo was a two-second period while the presenter said "This also works in Explorer."
The IE developers repeatedly made the point that they are driven by customer demand. For instance SMIL is not supported because (they claim) that nobody uses it. In a related question they said that they are waiting to see which animation method (CSS vs SMIL) wins before implementing one. Microsoft is not willing to invest the effort to innovate, or even to reach parity with other browsers. Direct quote: "I'm not trying to change the world, I'm trying to follow."
However, despite taking the heat from being the boat anchor that's slowing down adoption of SVG, there was genuine appreciation that IE had improved significantly in the last couple of years.
At the opposite end of the spectrum was Opera. Opera rocked the conference with the best combination of features and performance. Very impressive, especially in light of their statement that most of the SVG support is the work of one engineer.
SVG Open was an interesting conference, but I think they missed some opportunities. Attending the conference were the developers of SVG support in Firefox, Opera and IE. I would have expected deeply technical talks from these engineers about the algorithms they are using, efficiency tradeoffs, and other hard-core topics. Instead, after the first day, many of the presentations devolved into "Here's a cool-looking animated filter effect I made", or "Here's a website I wrote, and it uses SVG for the graphs". Perhaps my perspective is coloured by the DocEng conferences which are peer-reviewed academic conferences. Overall, I think SVG Open could have safely been shortened by a day.