The Problem

Manipulating SVG paths is not easy. To help us in this task we have developed a transformation system called path_ology based on XSLT to help us. This section gives an overview of what transformations are available. For those new to SVG, it is probably worth reading the SVG Primer first.

The current set of transformations is included here in the directory path_ology/library. Examples of how to use it are available in path_ology/examples together with some implementation notes.

An Example

The definition of a path in SVG is not designed to be human readable. For example:

<path  d="M200 200c40 48 120-32 160-6 0 0 5 4 10-3 
10-103 50-83 90-42 0 0 20 12 30 7-2 12-18 17-40 17-55-2-40 25-20 35
 30 20 35 65-30 71-50 4-170 4-200-79z"/>

It is not immediately obvious that this is the outline of a duck:

No SVG Support

Figure 1.1: Duck

The author has kept the size of the d attribute small by using a number of abbreviations allowed in SVG.

Coordinate values do not have spaces between them if their meaning can be deduced. For example, 17-55-2-40 defines four coordinate values 17, -55, -2, -40. Immediately after the Move command appears a cubic command indicating that the next six coordinate values define a cubic bezier with control points (240,248) and (320,168) with its end-point at (360,194). The six coordinates are all relative to the current position, which is (200,200) at the start of the cubic as the c is lower case. Then follows a stream of coordinates. The syntax for SVG path expression states that these are multiples of six coordinates defining subsequent cubic beziers until another command is detected, in our case the final z command that declares it is a closed curve.

The Solution

When developing SVG animations, it is quite often easier if this can be done using absolute rather than relative coordinates. In consequence, being able to switch easily between absolute and relative coordinates is important as is reducing the size of the d attribute using the other allowed optimisations.

Frequently, the starting point for an animation is some graphics imported from another system. If you are lucky, the import into SVG is straightforward. If you are unlucky, the following problems may occur:

  • The accuracy is much greater than required
  • The number of segments is more than required
  • Closed paths are made up of segments that are not defined together, particularly true for map outlines
  • The direction of traversal of a path is not the one required

These all lead to the need for a library of useful functions to make life easier.