I’ve always loved kaleidoscopes. Here are a couple made by using Inkscape’s Tiled Clone dialog with hand animation. The animation is done with SMIL rather than JavaScript. The animations work in Chrome, Opera, and Firefox (although the performance of the latter is a bit poor). They will not work in IE as it does not (and never will according to the IE developers) support SMIL animation. (Why SMIL? It is easier to do simple animations and doesn’t get disabled by browsers due to security concerns.) Clicking on the kaleidoscopes will take you to a larger version. I’ve disabled the animation here as they eat too many CPU cycles. Click on images to go to full animated versions.

I’ve been playing with different ways that Inkscape can be used to warp text and thought I would share a few images. This was all motivated by a discussion during an SVG working group meeting a couple of weeks ago on what the proper way to stretch glyphs when placed along a path. (At the moment only Opera can do it and it uses a rather simple algorithm.) You can find a more detailed discussion of this topic at my web site. The most successful experiments were those using the Envelope Deformation Live PathEffect. Only the top and bottom control paths were used (the right and left paths were disabled). For the text within circles, the circles were drawn using the Arc/Circle tool and then pasted in using the LPE editor. Note, you need to be using a modern browser capable of displaying SVG.

I got a surprise when opening an SVG file in emacs in Fedora 15 to do a little editing. I didn’t see the expected SVG source but instead saw a rendering of the SVG. Cool…. but one problem: How DO you edit the source? A quick Internet search led to aa Emacs Wiki page where the solution could be found: Use Ctrl-c Ctrl-c to switch back between editing and rendering modes. SVG rendering only works on a fairly recent version of emacs and only, it appears, on systems using X11. It uses the rather unloved librsvg2 library so don’t expect perfect rendering. The Wiki page also shows how you can control Inkscape directly from emacs if you have a DBUS enabled version of Inkscape. Hmm.

Have you ever had a Zen moment? Like one where you finally know the sound of one hand clapping? I just had one. I now understand how SVG is suppose to be fitted into part of a web page (well almost, as you will see). This was not an easy task, and in fact I found it more difficult than understanding QCD. It took piecing together parts from nine sections in five different chapters and two versions of the SVG specification plus developing a test page. If you are a long time web developer (or standards writer) you probably already know how SVG is fitted into HTML, or could make a good guess; the problem is, I am not. The fact that the various browsers have rendering differences with SVG in HTML means that I am probably not alone. Why is this important? I have over 500 SVGs in my Inkscape book. I want the SVGs to scale to the same size as the PNG fallback images. It would be very time consuming to go through and size each one individually and DocBook doesn’t provide a way to scale them by a set factor automatically. The first step in placing SVG into HTML is determining the “viewport” (SVG1.1, 7.2). This is the region on the web page where the SVG is to be placed. The position of the viewport is determined by the HTML. The size can be specified by the HTML through “positioning properties” (SVG1.1, 7.2). For example, if a wrapping <object> tag has width and height attributes defined, they determine the viewport size. If, however, the wrapping tag does not specify a size, the width and height attributes in the SVG root are used (SVG1.1, 7.2). The SVG width and height can be in absolute units (e.g. px) in which case, that is the size of the viewport, or they can be defined in percentages, in which case things are more complicated. If width and height are both 100% (or not given), then the viewport will fill the space allocated by the wrapper. If width and height are less than 100% one would think that the viewport would be scaled down by that amount which seems consistent with SVG1.1, 6.16. However, SVG1.2Tiny, 7.14 states that if percentages are used, they correspond to the percentage of the viewport that is actually rendered and not the relative size of the viewport to the available area! This can explain why in some cases Firefox and Opera both show only a quarter of the SVG when width and height are both 50%. Firefox and Opera don’t agree when which rule should be applied. And in one case, Opera applies both rules, reducing the viewport and clipping the SVG content. The viewport has another role that may not be obvious at once. By default, the SVG is clipped by the viewport and not by the SVG width/height or viewBox (SVG1.1, 14.3.3 and 6.16). This means that if you leave an object outside the nominal area of your drawing it may show up when the SVG is embedded in HTML! Now that we have the viewport, the next step is transform the SVG to fit it. If there is no viewBox attribute, the SVG is rendered so that the origin (upper left corner) of the SVG is at the upper left corner of the viewport (SVG1.1, 7.3). One user unit in SVG space corresponds to one screen pixel (SVG1.1, 7.2). If the viewport is bigger than the allotted area, Firefox adds scroll bars, Opera does not. There is an attribute that might control the display of scrollbars, zoomAndPan (SVG1.1, 16.7), but it doesn’t appear used. If there is a viewBox, the viewBox is mapped to the viewport (SVG1.1, 7.7). How the mapping is done is determined by the preserveAspectRatio attribute. The default value is “xMidYMid meet” (SVG1.1, 5.1.2) which means that the center of the viewBox is at the center of the viewport and that the SVG is scaled uniformly so that one pair of sides (top/bottom or left/right) of the viewBox coincide with the viewport while the other pair of sides is inside the viewport (SVG1.1, 7.8). Now recall that if the SVG attributes width and height have percentage values less than 100% there may be some clipping involved. The most important thing to take away is that the SVG attributes width and height are not what a naive person might think. They are rather suggestions to the HTML layout engine about the area that should be allocated for the SVG and in which the SVG will be scaled to fit (using the viewPort and scaleAspectRatio attributes).

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> 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> 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.

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.6	42.32 %
Internet Explorer 7.0	11.17 %
Internet Explorer 8.0	10.77 %
Safari 533.4	10.77 %
Safari 533.1	6.16 %
Firefox 3.5	4.66 %
Opera 9.8	3.25 %
Internet Explorer 6.0	2.94 %
Firefox 3.0	2.06 %
Safari 534.3	0.86 %
Safari 531.2	0.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.