SVG and Browser Support Part 2

Now that I’ve determined the time to use SVGs in the online version of my Inkscape has come (see previous post), the question becomes what is the best way to do it? The primary concern is to provide a graceful fallback for browsers that don’t natively support SVGs or are missing some required SVG feature (e.g. lack of filter support in IE9 and Safari 5). There are some criteria for choosing which method to use. Since I do my illustrations in Inkscape, Javascript libraries like Dojo, Raphael, and JSXGraph that create SVG or VML content depending on the browser can immediately be ruled out. Another Javascript solution: SVGweb uses Flash to display content in browsers that don’t support SVG. I don’t like this solution for a number of reasons. I don’t want to require my readers to install Flash, I would like to avoid using Javascript, and I don’t want to pepper my HTML with [if IE] conditionals necessary to get the <object> tag to work in IE. There are a number of plug-ins that support SVG such as the original Adobe SVG viewer (ASV). I don’t want to require my readers to install plug-ins and none of the plug-ins are very good solutions (ASV, for example, is no longer supported in addition to having other problems like not supporting the <object> tag). Actually, there is one interesting plug-in, Google Chrome Frame (GCF). This plug-in can replace the renderer in IE6, IE7, or IE8 with the renderer from Chrome. By adding one <meta> tag to a web page (or making a small change to the server configuration) you can suggest that the page be rendered using GCF. No other changes to the HTML need to be made. If GCF is installed, it is used; if not, no harm done. Having eliminated the above options, we are left with using standard HTML or XHTML. There are five ways to include SVGs in HTML and XHTML, four of which we can easily dismiss:
  • Inline SVG: Requires XHTML or HTML5, neither which are supported by IE prior to IE9. In addition, as all my figures are in separate files, it makes no sense to inline them.
  • <img> tag: Doesn’t support interactive SVG. No fallback method.
  • <iframe> tag: On its way out in HTML4 and XHTML, but resurrected in HTML5. Intended in HTML5 to sandbox content from other sources. Again no fallback method.
  • <embed> tag: Never in any HTML or XHTML standard but widely supported. As a matter of practicality, included in HTML5. Intended for content that needs a plug-in (this was the method used by ASV). Again no fallback method.
  • <object> tag: In both HTML and XHTML standards. If the content referenced in the tag cannot be displayed, the content between the opening and closing <object> tags is exposed providing a simple fallback method. This is our obvious choice for including SVG content.
So, how does one use the <object> tag to provide fallback? Here is an example: <object type=”image/svg+xml” data=”svg_button.svg”> <img src=”svg_button.png” alt=”SVG Button”/> </object> SVG Button But this has one problem: it displays with scroll bars in Chrome 6. The scroll bars can be avoided by adding width and height to the <object> tag: <object type=”image/svg+xml” data=”svg_button.svg” width=”300px” height=”100px”> <img src=”svg_button.png” alt=”SVG Button”/> </object> SVG Button In fact, things get quite tricky with getting the SVG displayed correctly. All the browsers treat SVG included by the various tags differently as can be seen by this handy test page by Jeff Schiller. This is a known problem by the SVG working group and work is being done to clarify the correct behaviors. I am working on my own test pages to investigate SVG integration issues. There is an HTML version and an XHTML version. So we are almost there. The one things missing is what to do about the lack of SVG filter support in IE9 and Safari 5. That will be the topic of a future post.

SVG and Browser Support

My Inkscape book has hundreds of figures, all drawn with Inkscape and stored as SVGs (except screen shots, of course). In the online version of the book, all of the figures are presented as PNGs (with just a few exceptions). Wouldn’t it be great if they were presented as SVGs? When I started the book this wasn’t practical, SVG support in browsers was rather limited. But times have changed and with the imminent release of IE9 which includes native SVG support it is time to reevaluate if SVGs can be used. So what is the current market share for browsers that support SVGs? According to Jeff Schiller, the market share in July was 43%. But market share is strongly dependent on the type of content. It is interesting to see that the usage of both IE6 and IE7 drops by around 4% each during the weekend (while IE8 gains a little). This demonstrates IE6 and IE7 entrenchment in the workplace. Of course the most important data is for the actual users of the online Inkscape manual. Here are some statistics for the book users from last month:
Firefox 3.642.32 %
Internet Explorer 7.011.17 %
Internet Explorer 8.010.77 %
Safari 533.410.77 %
Safari 533.16.16 %
Firefox 3.54.66 %
Opera 9.83.25 %
Internet Explorer 6.02.94 %
Firefox 3.02.06 %
Safari 534.30.86 %
Safari 531.20.83 %
So about 70% of my book’s readers already can view SVG without using a plug-in. It seems that this is the time to start using SVGs. How to do this while still supporting non-SVG capable browsers is a topic for a later post.

Optimizing Inkscape SVG size for the Web

During lunch one day at the latest SVG working group meeting, I had a discussion with Doug Schepers about Inkscape’s use for creating Wikipedia graphics. Doug says it stinks and pointed me to a talk at SVG Open 2009 by Brion Vibber who discussed how even gzipped SVG files were much bigger than PNGs. The worse category for “bloat” is flags where an SVG file is on average 18 times bigger than the equivalent PNG. Now this may not sound important to you and me but to somebody serving up zillions of graphics it cost real money. Today I came across a graphic of a clock escapement. In the “talk page” for the article on Robert Hooke, graphic file size is briefly discussed. The page gives the size of various versions of the graphic but it’s a bit hard to figure out what exactly they mean. Here is a short summary: I set about to see how I could reduce the SVG file size. The source shows that the SVG was created with Inkscape version 0.43. In the latest version, 0.48, there are a couple of tools to reduce file size. My first attempt at file size reduction was to save the file as “plain” SVG. This reduced the file size from 35755 bits to 28560 bits. This is done by mostly stripping out things in the Sodipodi and Inkscape namespaces. In recent versions of Inkscape, there is an “Optimized” SVG option. Trying this, with the default settings, I obtained a file size of 17481 bits. By turning on stripping out ID labels and xml prolog, reducing the precision to 3, and not using any indentation, I got a file size of 8366 bits, roughly the same size as the optimized PNG. But I can do even better. The SVG was made by tracing the original drawing from a book which means that the path preserves all the imperfections from the original. I can redraw the image using a few simple Bézier curves to reduce the number of nodes from the 571 in the original SVG to just 120 nodes. The file size is now 3333 bits. Removing the unused xmlns declarations, metadata, and defs sections yields a file size of 2999 bits. Gzipping the file reduces the file to 1528 bits. I could now even animate the file and it would still be smaller than the optimized PNG. (Animation is left as an exercise for the reader. I’ve already created an animated SVG gear clock.) The final SVG drawing:

Your browser does not support SVG! Too bad.

SVG Open 2010

SVG Open 2010 was held in Paris, and since I live nearby I offered to give a talk about Inkscape. I would like to thank the organizers for waving the conference fee and even providing a ticket for the conference dinner aboard a boat on the Seine. There were quite a few interesting talks and panels and I learned quite a bit. My overall impression can be summed up easily: SVG has finally arrived. This conclusion was easy to make after talking to the many representatives of the major web browsers, including those from Microsoft who were there in numbers. In case anybody missed the news, IE9 will include comprehensive support for SVG, only missing the filters, SMIL, and SVG fonts modules. Filters will almost certainly appear in IE10; SMIL and fonts might too depending on demand. In case anybody wants to know, it took about 15 developers 15 months to implement SVG support in IE. A good fraction of the discussion was on how SVG fits into HTML5. HTML5 is not a finished standard and there are still pieces to work out. Microsoft is implementing what it can now and has an important message for users: Download and test the IE9 previews and betas. Complain about any behavior you find wrong or undesirable. You have about three months before IE9 gets locked down. It will be hard to change behavior after that as IE9 is expected to be around for 10 years and future versions of IE will maintain backwards compatibility. I’m afraid my notes are quite poor so I will just make a list of some random observations:
  • HTML5 will be everywhere soon. Firefox 4 and IE9 already contain HTML5 parsers, Webkit (Chrome and Safari) and Opera will have them soon (you can use SVG in XHTML right now). All the browsers support some HTML5 features.
  • There is a huge desire to have CSS3 apply the same way to HTML as to SVG. This includes things like sharing filters.
  • SVG is very popular in mapping circles (and not just in OpenStreetMap).
  • Vector effects are very interesting for maps, especially the ability to share partial paths between objects and for creating complex paths for roads, et cetera.
  • Most TV set-top boxes use SVG for their displays.
  • Look for cool SVG demos at

Book update is finished.

The 2nd edition of my guide to Inkscape is finished! Yeh! It has been a busy week with many corrections from the editor and from Loïc Guégant who, while translating the book into French, is checking everything I wrote! I thought I was done Thursday, but the editor had given me some wrong information and I had to quickly change some things on the copyright page like the ISBN numbers. As it takes an hour to generate the book through xsltproc and fop, I just regenerated the beginning and then used pdftk to substitute the corrected page. pdftk is a great tool! Unfortunately it isn’t included in Fedora 8 or 9 due to some confusion about licensing. I found a note on the web that you could use the Fedora 7 src and rebuild the RPM. That worked. However, it takes forever and a day to do the regeneration.

Inkscape Printing

Printing in Inkscape is not a pretty picture. There are two main ways to produce PostScript or PDF files. The first is with the “Save As” dialog and the second is with the “Print” dialog. The two ways use different routines! Then within the “Save As” dialog, one can choose two different routines for PostScript output (via Cairo or via an internal routine) and in the “Print” dialog one can chose between Vector and Raster output. The only method that handles Patterns, Clipping, and Masking correctly is printing with rasterized output… but the quality is limited to 72 dpi (despite an entry box for setting dpi). There is support for Patterns, Clipping, and Masking in the Vector code but it doesn’t work correctly. I’ve looked at patterns briefly in the “Print” dialog Vector output. It appears that an extra transformation is being made. Removing this transformation produces correct output for simple test cases. I’ll need to come up with more complicated tests to check it fully. There is also a very confusing code that tries to align patterns to a grid. Why this is necessary with vector output (or even with raster output) is a mystery to me.