SVG 2 Fallbacks
As browser support for SVG 2 features is slow in coming, I've been working on ways to allow Inkscape users to benefit from SVG 2 features yet still be able to have their work display properly on the web. This is done using fallbacks which are all based on post-processing an SVG 2 file on saving. Processing of features is individually turned on or off by a set of preferences.

There are a number of variations on this theme depending on the particular feature.

Converting SVG 2 to SVG 1.1

This variation requires converting an SVG 2 file to an SVG 1.1 file. Unfortunately, at the moment, this is a one way conversion. One could imagine in the future adding Inkscape name-spaced attributes that would allow back conversion.

I've implemented two conversion of this type:

  • The marker attribute 'orient' value 'auto-start-reverse'
The 'auto-start-reverse' value allows a marker to rotate 180 degrees automatically at the start of a path. This means, for example, that one needs just one defined marker to create double headed arrows. This value is actually well supported by browsers so probably isn't really necessary, but it was the the first "proof-of-principle" conversion I implemented.
  • The 'fill' and 'stroke' values 'context-fill' and 'context-stroke'.
These values allow one, for example, one to match the fill of a marker (e.g. arrowhead) to the color of the path by setting the marker 'fill' to 'context-stroke'. The SVG renderer will look at the stroke color of the path to determine the fill color. This allows one to avoid having to hand set the arrowhead fill color and to avoid needing to define a new marker for each color used. 
Inkscape currently has code to automatically create new markers every time a new marker color is needed but this code is complicated and prone to bugs.

With the above two fallbacks, we will be able to clean up our set of canned markers as well as simplify our editing code.

Inserting JavaScript Polyfills

Some SVG 2 features can be handled by polyfills. A polyfill is a piece of JavaScript code that simulated some piece of missing functionality in a browser. We can automatically insert polyfills when needed. So far I've implemented one, a mesh gradient polyfill.

I wrote the mesh gradient polyfill some time ago. It's not perfect in that it doesn't (yet) handle meshes on strokes or bi-cubic meshes. It can now be inserted automatically when mesh gradients are used.

SVG 2 Text with SVG 1.1 Fallback

When I designed SVG 2 auto-wrapped text, I was careful to allow a native way to embed an SVG 1.1 fallback method. The fallback method requires breaking the text up into pieces and supplying 'x' and 'y' attributes for each piece. An SVG 1.1 renderer will ignore the SVG 2 text wrapping properties and use the 'x' and 'y' attributes for positioning the pieces of text while an SVG 2 renderer will ignore the 'x' and 'y' attributes and flow the text itself. In principle, the two methods should yield the same visual result but in some cases, for example if a font is missing and a font with different metrics is substituted, the SVG 1.1 rendering will be inferior.

Currently, Inkscape uses the abandoned SVG 1.2 flowed text method for putting text in a shape (supported only by Inkscape and Batik). I plan on replacing this with SVG 2 text in the near future. This will avoid having to manually convert flowed text to normal text for use outside of Inkscape.

Changes to File Dialog

I've proposed some changes to how we save and export files. The biggest problem that I see in the current system is the multiplication of options for saving in the SVG format. We have

  • Inkscape SVG
  • Plain SVG
  • Compressed Inkscape SVG
  • Compressed plain SVG
  • Optimized SVG
  • Compressed Inkscape SVG with media
  • Layers as Separate SVG

Now we add in the fallback options... What if one wants optimized compressed SVG with SVG 1.1 fallback?

The solution I am proposing follows the Gimp model. Save and Save As becomes saving as normal Inkscape SVG 2. The other options become exports (as they are lossy or have special features). On exporting to SVG, a dialogue pops offering a number of options, much like the PDF dialogue. One can the select to compress, optimize, or include fallbacks.

The main criticism of this "export" focussed method in Gimp was the extra steps that were needed to export to a non-native file format, especially if one just want to tweak a PNG or JPEG. This was remedied by adding an Overwrite menu entry which saves the drawing in the same format as was used in opening the file. Inkscape could do the same.

Hackfest in Kiel

I'll be attending the Inkscape hackfest in Kiel, Germany that starts this Sunday and runs through Thursday. I'm really looking forward to meeting other Inkscape developers and community members!