SVG Working Group Meeting Report

The SVG Working Group had a three day Face-to-Face meeting in Hamburg this week. The last day was devoted to working with the CSS Working Group on joint items. I attended most of it via telephone. A lot of the discussions had to do with stategies for getting SVG2 out or with technical stuff. But there were a number of things that might be of interest to Inkscape users and others.
  • Paint Order: It was resolved that the SVG will allow the order in which fill, stroke, and markers for a single graphics element are painted to be specified. At the moment the stroke is always painted on top of the fill, and markers on top of everything. Being able to paint the fill on top of the stroke is quite important for text.
    The letter 'B' with normal fill order, fill on top, and markers underneath.

    A letter with various paint orders.

  • Marker Clipping: At the moment, in order to avoid the path from showing under the tip of an arrowhead, the arrowhead must extend past the end of the path. In Inkscape, this prevents things like snapping the arrow tip to a line since the path end is not at the same place as the arrow tip. One of the SVG group members is going to work out a way to specify a clipping region for a marker that would apply to the path below thus eliminating this problem.
    Marker clipping applied to an arrow and to a circle.

    Demonstration of the use of marker clipping. The red dotted line indicates the clipped area. Clipping only applies to the path the marker is attached to.

  • Marker positioning: The current spec only allows markers placed at the ends of a path or at nodes. The WG agreed that more complex marker placement would be supported, For example one will be able to alternate between two markers and place them every 20px along a path.
    A path with two alternating markers placed at equal intervals.

    A path with markers. The markers are placed by distance along path.

  • Masking: Masks will gain an attribute to specify whether to use alpha or luminance in the masking calculation.
  • Screening Filter Primitive: The group was supportive of my proposal to add a screening filter primitive. It would not be added to the SVG2 specification directly but to the CSS/SVG joint filters specification that has been split out from the SVG spec.
  • Gradients Along/Across Paths (and Variable Stroke Opacity): While group members were interested in this, it turns out to be quite difficult to implement so the group pushed this off to the future. (The Adobe rep said that it was a real pain to export it to other formats.) If Inkscape were to support this somehow (mesh fallback?), it would help push it into the spec.
  • New Stroke Join: Coming from Johan Engelen’s Power Stroke work inside Inkscape, I propsed that the SVG2 specification add a new stroke-join option. Currently you have the choice of beveled, rounded, or mitered. When a path contains two curved segments joined at a sharp point, the mitered option doesn’t look so good. Johan’s Power Stroke allows an “extrapolated” join where the curvature of the paths is taken into account. The SVG WG liked this idea and approved it subject to defining the math needed precisely. One factor in its adoption will be than none of the graphics libraries used by the browsers includes such a join.
    A demonstration of the different existing SVG join styles and the proposed new style.

    The existing join styles with the proposed extrapolated join style.

Animation in SVG and CSS

David White created a nice SVG background he calls “The digital river” with animated circles. Unfortunately it only works in Firefox due to incorrect handling of events inside the <use> tag (which allows cloning of objects, in this case a circle) by other browsers. The other browsers apply mouse events to the referenced object rather than just the cloned objects. David’s SVG uses SMIL for animation. Unfortunately, Microsoft has declared in no uncertain terms that it will not implement SMIL in their browers. They see CSS Transitions and CSS Animations as the proper way forward for supporting animation in SVG however no browser at the moment supports this although all the browsers do support experimental (read: prefixed) CSS transitions and animations on HTML elements. Here are two experiments inspired by David’s work. The first uses CSS with CSS Transitions, the second SVG with SMIL. Pass your cursor over the circles. The CSS version uses rounded corners on <div>s to simulate circles. It has the advantage of cross-browser support (except Firefox messes up the first row of circles). The SVG version only works properly in Firefox. It is more powerful as you can easily scale circles or use other shapes. CSS Ripples
    
    

You must be reading this via Graphics Planet. Go to my blog site to see the demos. Graphics Planet strips out the styling needed to make the demos work.

SVG Ripples

Your browser does not support SVG! Too bad.

CSS3 Transforms and Animation Experiments

I’ve been experimenting with CSS3 3D Transforms and Animations. Currently only Firefox and WebKit browers support these features. Don’t use these in production. The specs are not finalized! Note to those reading this in Graphics Planet… the feed strips out the style elements that are required for the animated image. No JavaScript used, only CSS with inlined SVG. You can see more examples including a stereo version of the dodecahedron at my SVG and CSS page.
    

     

    

You must be reading this via Graphics Planet. Go to my blog site to see the animation.

Multicolor Dodecahedron

SVG 2: Now is the time to act!

The SVG working group is close to finishing a review of all the proposed new features for SVG 2. This is the time to make your voice heard if you want something added to the specification! While a final SVG 2 standard is probably two years away, things can show up in browsers earlier. SVG 2 will consist of a core standard plus modules and references to other standards, especially those from CSS 3, some of which are already approved or are close to being approved. You can now use CSS 3 Colors inside SVG in browsers. This allows, for example, describing a color in terms of HSL as I’ve done in the example below:


   

   
   HSL

Appearing relatively soon will be CSS 3 Transforms which includes both 2D and 3D transforms. All the major browsers already support 2D transforms in HTML with Firefox and Chrome supporting some 3D transforms (at the moment one must use browser specific prefixes but that should change in the next couple of months). Expect this support to extend to SVG in the near future. (Hover over the box below! All done with CSS!)
    
    
Front
Right
Back
Left
Top
Bottom
There are a number of items that Inkscape users and developers have expressed interest in seeing added to the SVG specificaition. If you have something you want to see added, leave a comment. There are some things that the SVG working group is open to adding but nobody in the group is willing to spend much time on them. If someone in the community were to step up, the likelihood that they would be added would be much greater. One item in this catagory is connectors.

Tensor Meshes Revisited

When I first proposed adding meshes to the SVG standard the SVG working group looked at the question of Coons patch vs tensor patch meshes. A tensor patch adds four additional control points to a Coons patch. These control points influence how the color is spread inside the patch. The group decided that the added complexity of the tensor patch was not worth the benefit gain. I am now revisiting this decision. In a previous blog I discussed the problems caused by a lack of smoothness across patch boundaries. At first it didn’t seem like having tensor control points would help but now I realize that in some limited cases they can be of great benefit. Consider the following four patch mesh:
A 2x2 patch mesh showing effect of lack of smoothness across boundaries.

A 2×2 Coons Patch mesh. The outer corner colors are black. The center corner is white.

The first thing that one sees is a cross pattern. This is due to a lack of smoothness across the patch boundaries. In the following figure one can see the color profile for two of the patches that clearly illustrates the sharp change in the color derivative at the patch boundary.
A diagram of the color profile for two of the patches in the above mesh.

The color profile for two of the patches in the previous figure. The height of the surface is proportional to the white level. The red line illustrates the profile along a diagonal line in one of the patches. The blue line shows the required profile if the profile is to be rotationally symmetric around the center point.

By moving the tensor mesh points it is possible to better approximate a rotationally symmetric profile around the center point, reducing the “cross” artifact.
A 2x2 patch mesh where tensor control points are used to smooth the color profile across patch boundaries.

Tensor control points have been used to smooth the color profile.

It is not possible to completely remove the cross using tensor control points. One also still has a bright spot at the center point which is not what one wants when trying to illustrate a diffuse reflection of light off a curved surface. To get a smoother profile one needs to add more patches.
A 4x4 patch mesh with a smoother color profile.

A 4×4 Coons patch mesh is used to produce a smoother color profile.

So adding tensor control points is useful but is not a complete solution to smoothness. I still haven’t made up my mind about their cost/benefit value. Feedback would be appreciated.

SVG Kaleidoscopes

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. A simple Kaleidoscope animation. A simple Kaleidoscope animation.

Warped Text in Inkscape

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.
Text warped with Envelope LPE.
Text warped with Envelope LPE.
Text warped with Envelope LPE.
Text warped with Envelope LPE.
Text warped with Envelope LPE.

SVG display in Emacs

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.

SVG Filters in CSS

You’ll probably need to go to my blog site to see this post properly. And you’ll need to be using Firefox 3.5 or later.

An SVG in CSS Filter Experiment

I’ve begun to experiment with a Firefox feature that allows SVG filters to be applied to HTML elements via CSS. There don’t seem to be many examples out on the web. This example wraps a <div> around some content to which the Inkscape Alpha Engraving B filter has been applied. Try selecting some text.

Work has begun by the W3C FX working group to standardize using SVG filters in CSS.

A London street scene.

SVG and Browser Support Part 3

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