There are two transformations that change the SVG internal form back to the d attribute:

back_to_svg

This generates a d attribute consisting of M, Z, A, C and L commands only. The commands can either be absolute or relative. This is achieved by a mode parameter added to the bat file (mode=abs or mode=rel). A bug in the current Chrome implementation (May 2010) means that an m command following a Z command is not animated correctly. In consequence, a third mode is provided (relMabs) that always outputs absolute M commands.

simplify_and_back_to_svg

This is similar to back_to_svg except that it tries to simplify both L and C commands. If possible C commands are turned to S, Q or T commands while L commands are turned to H and V. A parameter toline if set to ctol will also attempt to convert C to L, H or V if appropriate. A typical command might be:

java -jar saxon.jar  -o new.svg inner.xml  simpliify_and_back_to_svg.xsl mode=relMabs toline=ctol

A third parameter is lastl=no which removes the final line command leaving the last Z to invoke the completion of the path.

When animating paths, care must be taken to ensure that the two paths are the same. The SVG standard requires the path descriptions to be essentially the same. The current situation in terms of impementations is:

  • If the sequence of curves and lines is the same, whether relative or absolute, animation succeeds in current versions of Opera, Chrome, Safari and the Adobe plugin
  • Most implementations will animate between the different curve types, that is a C path will animate to a Q path etc
  • At least one implementation will not animate an L command to a V or H
  • Lower case m commands following a Z command cause problems in one implementation
  • Two M commands following each other will not always animate to a single M command. It is unclear in the SVG specification whether this is legal or not

In consequence, it is often wise not to simplify the paths when returning to SVG from XML.