W3C

SVG Paths

W3C Editor’s Draft 08 March 2023

This version:
https://svgwg.org/specs/paths/
Latest version:
http://www.w3.org/TR/svg-paths/
GitHub repository:
https://github.com/w3c/svgwg/tree/master/specs/paths
Feedback:
www-svg@w3.org with subject line “[svg-paths] … message topic” (archive)
Editors:
Cyril Concolato, Telecom ParisTech <cyril.concolato@telecom-paristech.fr>
Cameron McCormack, Mozilla Corporation <cam@mcc.id.au>
Doug Schepers, W3C <schepers@w3.org>


Abstract

This specification defines a syntax and DOM representation for paths, which are shapes that can be rendered in a document. Paths are primarily used for rendering shapes using the SVG path element, but are also used by a number of other Web platform features, such as clipping paths and rendering in an HTML ‘canvas’.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is the 08 March 2023 Editor’s Draft of SVG Paths. The purpose of this specification is to define a number of improved SVG stroking features.

This specification is an early draft that largely contains features that were dropped during the development of SVG 2. In the future, this specification will supercede the SVG 2 Paths chapter, however at this time the SVG 2 Paths chapter must be considered the normative definition for SVG Paths.

Comments on this Editor’s Draft are welcome. Comments can be sent to www-svg@w3.org, the public email list for issues related to vector graphics on the Web. This list is archived and senders must agree to have their message publicly archived from their first posting. To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

This document has been produced by the W3C SVG Working Group as part of the Graphics Activity within the W3C Interaction Domain. The goals of the W3C SVG Working Group are discussed in the W3C SVG Charter. The W3C SVG Working Group maintains a public Web page, https://www.w3.org/Graphics/SVG/, that contains further background information. The authors of this document are the SVG Working Group participants.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

A list of current W3C Recommendations and other technical documents can be found at https://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time.

This document is governed by the 1 August 2014 W3C Process Document.

1. Introduction

A path represents the outline of a shape which can be filled or stroked. A path can also be used as a clipping path, to describe animation, or position text. A path can be used for more than one of these functions at the same time. (See Filling, Stroking and Paint Servers, Clipping and Masking, Animation ('animateMotion'), and Text on a Path.)

A path is described using the concept of a current point. In an analogy with drawing on paper, the current point can be thought of as the location of the pen. The position of the pen can be changed, and the outline of a shape (open or closed) can be traced by dragging the pen in either straight lines or curves.

Paths represent the geometry of the outline of an object, defined in terms of moveto (set a new current point), bearing (set a new orientation), lineto (draw a straight line), curveto (draw a curve using a cubic Bézier), arc (elliptical or circular arc) and closepath (close the current shape by connecting to the last moveto) commands. Compound paths (i.e., a path with multiple subpaths) are possible to allow effects such as "donut holes" in objects.

This chapter describes the syntax, behavior and DOM interfaces for SVG paths. Various implementation notes for SVG paths can be found in ‘path’ element implementation Notes and Elliptical arc implementation notes.

A path is defined in SVG using the path element.

The basic shapes are all described in terms of what their equivalent path is, which is what their shape is as a path. (The equivalent path of a path element is simply the path itself.)

2. Module interactions

This specification extends SVG 2 [SVG2]. Specifically, it replaces the Paths chapter of SVG 2.

3. The SVG ‘path’ element

path
Categories:
Graphics element, renderable element, shape element
Content model:
Any number of the following elements, in any order:clipPath, marker, mask, script, style
Attributes:
Geometry properties:
DOM Interfaces:
Name Value Initial value Animatable
d svg-path [EBNF] (none) yes

The definition of the outline of a shape. See Path data. Error processing for svg-path is done according to Path Data Error Handling.

Path data animation is only possible when each path data specification within an animation specification has exactly the same list of path data commands as the d attribute. If an animation is specified and the list of path data commands is not the same, then the animation specification is in error (see Error Handling). The animation engine interpolates each parameter to each path data command separately based on the attributes to the given animation element. Flags and booleans are interpolated as fractions between zero and one, with any non-zero value considered to be a value of one/true.

The initial value, (none) indicates that the path element is valid but does not render.

Name Value Initial value Animatable
pathLength <number> (none) yes

The author's computation of the total length of the path, in user units. This value is used to calibrate the user agent's own distance-along-a-path calculations with that of the author. The user agent will scale all distance-along-a-path computations by the ratio of pathLength to the user agent's own computed value for total path length. pathLength potentially affects calculations for text on a path, motion animation and various stroke operations.

A negative value is an error (see Error handling).

4. Path data

SVG 2 Requirement: Include smooth path between points functionality.
Resolution: We will add a Catmull Rom syntax to the path syntax with a tension parameter to control the whole curve (not per-point control).
Purpose: Provide an easy way to graph data, etc.
Owner: Doug (ACTION-3085)
SVG 2 Requirement: Support turtle-graphics-like current rotation in path syntax.
Resolution: We will add a path rotation command.
Purpose: Make path rotations easier to animate and pie charts easier to draw.
Owner: Cameron (ACTION-3125)

4.1. General information about path data

A path is defined by including a path element which contains a d="(path data)" attribute, where the d attribute contains the moveto, bearing, lineto, curveto (both cubic and quadratic Béziers), arc and closepath instructions.

Example triangle01 specifies a path in the shape of a triangle. (The M indicates a moveto, the Ls indicate linetos, and the z indicates a closepath).

<?xml version="1.0" standalone="no"?>
<svg width="4cm" height="4cm" viewBox="0 0 400 400"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
  <title>Example triangle01- simple example of a 'path'</title>
  <desc>A path that draws a triangle</desc>
  <rect x="1" y="1" width="398" height="398"
        fill="none" stroke="blue" />
  <path d="M 100 100 L 300 100 L 200 300 z"
        fill="red" stroke="blue" stroke-width="3" />
</svg>
Example triangle01 — simple example of a 'path'

Example triangle01

View this example as SVG (SVG-enabled browsers only)

Path data can contain newline characters and thus can be broken up into multiple lines to improve readability. Newlines inside attributes in markup will be normalized to space characters while parsing.

The syntax of path data is concise in order to allow for minimal file size and efficient downloads, since many SVG files will be dominated by their path data. Some of the ways that SVG attempts to minimize the size of path data are as follows:

The path data syntax is a prefix notation (i.e., commands followed by parameters). The only allowable decimal point is a Unicode U+0046 FULL STOP (".") character (also referred to in Unicode as PERIOD, dot and decimal point) and no other delimiter characters are allowed [UNICODE]. (For example, the following is an invalid numeric value in a path data stream: "13,000.56". Instead, say: "13000.56".)

For the relative versions of the commands, all coordinate values are relative to the current point at the start of the command.

Relative path commands are also influenced by the current bearing, which is an angle set by the bearing commands. This allows for paths to be specified using a style of "turtle graphics", where straight line and curved path segments are placed with their starting point at a tangent (or at some other angle) to the current bearing.

In the tables below, the following notation is used to describe the syntax of a given path command:

In the description of the path commands, cpx and cpy represent the coordinates of the current point, and cb represents the current bearing.

The following sections list the commands. Those that draw straight line segments include the lineto commands (L, l, H, h, V and v) and the close path commands (Z and z). These three groups of commands draw curves:

4.2. The "moveto" commands

The "moveto" commands (M or m) establish a new current point. The effect is as if the "pen" were lifted and moved to a new location. A path data segment (if there is one) must begin with a "moveto" command. Subsequent "moveto" commands (i.e., when the "moveto" is not the first command) represent the start of a new subpath:

Command Name Parameters Description
M (absolute)
m (relative)
moveto (x y)+ Start a new sub-path at the given (x,y) coordinates. M (uppercase) indicates that absolute coordinates will follow; m (lowercase) indicates that relative coordinates will follow. If a moveto is followed by multiple pairs of coordinates, the subsequent pairs are treated as implicit lineto commands. Hence, implicit lineto commands will be relative if the moveto is relative, and absolute if the moveto is absolute. If a relative moveto (m) appears as the first element of the path, then it is treated as a pair of absolute coordinates. In this case, subsequent pairs of coordinates are treated as relative even though the initial moveto is interpreted as an absolute moveto.

When a relative m command is used, the position moved to is (cpx + x cos cb + y sin cb, cpy + x sin cb + y cos cb).

4.3. The "closepath" command

The "closepath" (Z or z) ends the current subpath by connecting it back to its initial point in either of two ways:

  1. If the previous command is complete, that is that all the required coordinate data has been supplied, then an automatic straight line is drawn from the current point to the initial point of the current subpath. This path segment may be of zero length.
  2. If the previous command is missing required coordinate data then the initial point is used to fill in the missing data (but only for the last point or points).

Examples:

SVG 2 adds the ability to fill in missing coordinate data with the Z or z command to avoid the need to add a zero length (or very short in the case of relative paths with rounding errors) path segment to close a subpath. This can effect the number of markers drawn and their orientation at the beginning/end of a closed subpath.

The use of Z or z to replace missing coordinate data with the coordinate of the initial point in a subpath was resolved at the Sydney (2015) meeting.

If a "closepath" is followed immediately by a "moveto", then the "moveto" identifies the start point of the next subpath. If a "closepath" is followed immediately by any other command, then the next subpath starts at the same initial point as the current subpath.

When a subpath ends in a "closepath," it differs in behavior from what happens when "manually" closing a subpath via a "lineto" command in how stroke-linejoin and stroke-linecap are implemented. With "closepath", the end of the final segment of the subpath is "joined" with the start of the initial segment of the subpath using the current value of stroke-linejoin. If you instead "manually" close the subpath via a "lineto" command, the start of the first segment and the end of the last segment are not joined but instead are each capped using the current value of stroke-linecap. At the end of the command, the new current point is set to the initial point of the current subpath.

The current bearing does not affect a z command.

Command Name Parameters Description
Z or
z
closepath (none) Close the current subpath by connecting it back to the current subpath's initial point (see prose above). Since the Z and z commands take no parameters, they have an identical effect.

4.4. The "lineto" commands

The various "lineto" commands draw straight lines from the current point to a new point:

Command Name Parameters Description
L (absolute)
l (relative)
lineto (x y)+ Draw a line from the current point to the given (x,y) coordinate which becomes the new current point. L (uppercase) indicates that absolute coordinates will follow; l (lowercase) indicates that relative coordinates will follow. A number of coordinates pairs may be specified to draw a polyline. At the end of the command, the new current point is set to the final set of coordinates provided.
H (absolute)
h (relative)
horizontal lineto x+ Draws a horizontal line from the current point. H (uppercase) indicates that absolute coordinates will follow; h (lowercase) indicates that relative coordinates will follow. Multiple x values can be provided (although usually this doesn't make sense). An H or h command is equivalent to an L or l command with 0 specified for the y coordinate. At the end of the command, the new current point is taken from the final coordinate value.
V (absolute)
v (relative)
vertical lineto y+ Draws a vertical line from the current point. V (uppercase) indicates that absolute coordinates will follow; v (lowercase) indicates that relative coordinates will follow. Multiple y values can be provided (although usually this doesn't make sense). A V or v command is equivalent to an L or l command with 0 specified for the x coordinate. At the end of the command, the new current point is taken from the final coordinate value.

When a relative l command is used, the end point of the line is (cpx + x cos cb + y sin cb, cpy + x sin cb + y cos cb).

When a relative h command is used, the end point of the line is (cpx + x cos cb, cpy + x sin cb). This means that an h command with a positive x value draws a line in the direction of the current bearing. When the current bearing is 0, this is a horizontal line in the direction of the positive x-axis.

When there is a non-zero bearing, a mnemonic for the h command could be "head this distance at the current bearing", rather than "draw a horizontal line".

When a relative v command is used, the end point of the line is (cpx + y sin cb, cpy + y cos cb).

4.5. The cubic Bézier curve commands

The cubic Bézier commands are as follows:

Command Name Parameters Description
C (absolute)
c (relative)
curveto (x1 y1 x2 y2 x y)+ Draws a cubic Bézier curve from the current point to (x,y) using (x1,y1) as the control point at the beginning of the curve and (x2,y2) as the control point at the end of the curve. C (uppercase) indicates that absolute coordinates will follow; c (lowercase) indicates that relative coordinates will follow. Multiple sets of coordinates may be specified to draw a polybézier. At the end of the command, the new current point becomes the final (x,y) coordinate pair used in the polybézier.
S (absolute)
s (relative)
shorthand/smooth curveto (x2 y2 x y)+ Draws a cubic Bézier curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not an C, c, S or s, assume the first control point is coincident with the current point.) (x2,y2) is the second control point (i.e., the control point at the end of the curve). S (uppercase) indicates that absolute coordinates will follow; s (lowercase) indicates that relative coordinates will follow. Multiple sets of coordinates may be specified to draw a polybézier. At the end of the command, the new current point becomes the final (x,y) coordinate pair used in the polybézier.

When a relative c or s command is used, each of the relative coordinate pairs is computed as for those in an m command. For example, the final control point of the curve of both commands is (cpx + x cos cb + y sin cb, cpy + x sin cb + y cos cb).

Example cubic01 shows some simple uses of cubic Bézier commands within a path. The example uses an internal CSS style sheet to assign styling properties. Note that the control point for the "S" command is computed automatically as the reflection of the control point for the previous "C" command relative to the start point of the "S" command.

<?xml version="1.0" standalone="no"?>
<svg width="5cm" height="4cm" viewBox="0 0 500 400"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
  <title>Example cubic01- cubic Bézier commands in path data</title>
  <desc>Picture showing a simple example of path data
        using both a "C" and an "S" command,
        along with annotations showing the control points
        and end points</desc>
  <style type="text/css"><![CDATA[
    .Border { fill:none; stroke:blue; stroke-width:1 }
    .Connect { fill:none; stroke:#888888; stroke-width:2 }
    .SamplePath { fill:none; stroke:red; stroke-width:5 }
    .EndPoint { fill:none; stroke:#888888; stroke-width:2 }
    .CtlPoint { fill:#888888; stroke:none }
    .AutoCtlPoint { fill:none; stroke:blue; stroke-width:4 }
    .Label { font-size:22; font-family:Verdana }
  ]]></style>

  <rect class="Border" x="1" y="1" width="498" height="398" />

  <polyline class="Connect" points="100,200 100,100" />
  <polyline class="Connect" points="250,100 250,200" />
  <polyline class="Connect" points="250,200 250,300" />
  <polyline class="Connect" points="400,300 400,200" />
  <path class="SamplePath" d="M100,200 C100,100 250,100 250,200
                                       S400,300 400,200" />
  <circle class="EndPoint" cx="100" cy="200" r="10" />
  <circle class="EndPoint" cx="250" cy="200" r="10" />
  <circle class="EndPoint" cx="400" cy="200" r="10" />
  <circle class="CtlPoint" cx="100" cy="100" r="10" />
  <circle class="CtlPoint" cx="250" cy="100" r="10" />
  <circle class="CtlPoint" cx="400" cy="300" r="10" />
  <circle class="AutoCtlPoint" cx="250" cy="300" r="9" />
  <text class="Label" x="25" y="70">M100,200 C100,100 250,100 250,200</text>
  <text class="Label" x="325" y="350"
        style="text-anchor:middle">S400,300 400,200</text>
</svg>
Example cubic01 — cubic Bézier comamnds in path data

Example cubic01

View this example as SVG (SVG-enabled browsers only)

The following picture shows some how cubic Bézier curves change their shape depending on the position of the control points. The first five examples illustrate a single cubic Bézier path segment. The example at the lower right shows a "C" command followed by an "S" command.

Example cubic02 - cubic Bézier commands in path data

View this example as SVG (SVG-enabled browsers only)
 

4.6. The quadratic Bézier curve commands

The quadratic Bézier commands are as follows:

Command Name Parameters Description
Q (absolute)
q (relative)
quadratic Bézier curveto (x1 y1 x y)+ Draws a quadratic Bézier curve from the current point to (x,y) using (x1,y1) as the control point. Q (uppercase) indicates that absolute coordinates will follow; q (lowercase) indicates that relative coordinates will follow. Multiple sets of coordinates may be specified to draw a polybézier. At the end of the command, the new current point becomes the final (x,y) coordinate pair used in the polybézier.
T (absolute)
t (relative)
Shorthand/smooth quadratic Bézier curveto (x y)+ Draws a quadratic Bézier curve from the current point to (x,y). The control point is assumed to be the reflection of the control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not a Q, q, T or t, assume the control point is coincident with the current point.) T (uppercase) indicates that absolute coordinates will follow; t (lowercase) indicates that relative coordinates will follow. At the end of the command, the new current point becomes the final (x,y) coordinate pair used in the polybézier.

When a relative q or t command is used, each of the relative coordinate pairs is computed as for those in an m command. For example, the final control point of the curve of both commands is (cpx + x cos cb + y sin cb, cpy + x sin cb + y cos cb).

Example quad01 shows some simple uses of quadratic Bézier commands within a path. Note that the control point for the "T" command is computed automatically as the reflection of the control point for the previous "Q" command relative to the start point of the "T" command.

<?xml version="1.0" standalone="no"?>
<svg width="12cm" height="6cm" viewBox="0 0 1200 600"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
  <title>Example quad01 - quadratic Bézier commands in path data</title>
  <desc>Picture showing a "Q" a "T" command,
        along with annotations showing the control points
        and end points</desc>
  <rect x="1" y="1" width="1198" height="598"
        fill="none" stroke="blue" stroke-width="1" />

  <path d="M200,300 Q400,50 600,300 T1000,300"
        fill="none" stroke="red" stroke-width="5"  />
  <!-- End points -->
  <g fill="black" >
    <circle cx="200" cy="300" r="10"/>
    <circle cx="600" cy="300" r="10"/>
    <circle cx="1000" cy="300" r="10"/>
  </g>
  <!-- Control points and lines from end points to control points -->
  <g fill="#888888" >
    <circle cx="400" cy="50" r="10"/>
    <circle cx="800" cy="550" r="10"/>
  </g>
  <path d="M200,300 L400,50 L600,300 
           L800,550 L1000,300"
        fill="none" stroke="#888888" stroke-width="2" />
</svg>
Example quad01 — quadratic Bézier commands in path data

Example quad01

View this example as SVG (SVG-enabled browsers only)

4.7. The elliptical arc curve commands

SVG 2 Requirement: Make it simpler to draw arcs in SVG path syntax.
Resolution: Make arcs in paths easier.
Purpose: To make it easier for authors to write path data with arcs by hand.
Owner: Cameron (ACTION-3151)

The elliptical arc commands are as follows:

Command Name Parameters Description
A (absolute)
a (relative)
elliptical arc (rx ry x-axis-rotation large-arc-flag sweep-flag x y)+ Draws an elliptical arc from the current point to (x, y). The size and orientation of the ellipse are defined by two radii (rx, ry) and an x-axis-rotation, which indicates how the ellipse as a whole is rotated relative to the current coordinate system. The center (cx, cy) of the ellipse is calculated automatically to satisfy the constraints imposed by the other parameters. large-arc-flag and sweep-flag contribute to the automatic calculations and help determine how the arc is drawn.

When a relative a command is used, the end point of the arc is (cpx + x cos cb + y sin cb, cpy + x sin cb + y cos cb). The effective value of the x-axis-rotation parameter is also affected by the current bearing: it is computed as x-axis-rotation + cb.

Example arcs01 shows some simple uses of arc commands within a path.

<?xml version="1.0" standalone="no"?>
<svg width="12cm" height="5.25cm" viewBox="0 0 1200 400"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
  <title>Example arcs01 - arc commands in path data</title>
  <desc>Picture of a pie chart with two pie wedges and
        a picture of a line with arc blips</desc>
  <rect x="1" y="1" width="1198" height="398"
        fill="none" stroke="blue" stroke-width="1" />

  <path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
        fill="red" stroke="blue" stroke-width="5" />
  <path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
        fill="yellow" stroke="blue" stroke-width="5" />

  <path d="M600,350 l 50,-25 
           a25,25 -30 0,1 50,-25 l 50,-25 
           a25,50 -30 0,1 50,-25 l 50,-25 
           a25,75 -30 0,1 50,-25 l 50,-25 
           a25,100 -30 0,1 50,-25 l 50,-25"
        fill="none" stroke="red" stroke-width="5"  />
</svg>
Example arcs01 — arc commands in path data

Example arcs01

View this example as SVG (SVG-enabled browsers only)

The elliptical arc command draws a section of an ellipse which meets the following constraints:

For most situations, there are actually four different arcs (two different ellipses, each with two different arc sweeps) that satisfy these constraints. large-arc-flag and sweep-flag indicate which one of the four arcs are drawn, as follows:

The following illustrates the four combinations of large-arc-flag and sweep-flag and the four different arcs that will be drawn based on the values of these flags. For each case, the following path data command was used:

<path d="M 125,75 a100,50 0 ?,? 100,50"
      style="fill:none; stroke:red; stroke-width:6"/>

where "?,?" is replaced by "0,0" "0,1" "1,0" and "1,1" to generate the four possible cases.

Illustration of flags in arc commands

View this example as SVG (SVG-enabled browsers only)

Refer to Elliptical arc implementation notes for detailed implementation notes for the path data elliptical arc commands.

4.8. The Catmull-Rom curve commands

The Catmull-Rom curve commands (R or r) specify control points for a Catmull-Rom curve. The Catmull-Rom curve commands are:

Command Name Parameters Description
R (absolute)
r (relative)
Catmull-Rom x1 y1 x2 y2 (x y)+

Draws a Catmull-Rom curve using the specified points as its control points. The curve is drawn starting from (x1, y1), passing through each subsequent point, before stopping at the second-last point given. The current point preceding the command provides the first control point of the curve and controls its tangent coming out of (x1, y1). The final point of the command provides the final control point and controls the tangent of the curve coming in to the second-last point. R (uppercase) indicates that absolute coordinates will follows; r (lowercase) indicates that relative coordinates will follow.

The current point after drawing the Catmull-Rom curve is left at the second-last point of the command, i.e. the point at which the curve ends visually.

When a relative r command is used, each of the relative coordinate pairs is computed as for those in an m command. For example, the second control point of the curve – the first listed in the command – is (cpx + x1 cos cb + y1 sin cb, cpy + x1 sin cb + y1 cos cb).

Should we broaden this and allow for a tension parameter to be specified, and thus be cardinal spline rather than a Catmull-Rom spline?

Should we allow for fewer than three coordinate pair arguments to the command and try to do something sensible with them, rather than causing the path data to become invalid?

Is it a problem that the command will move then pen from the current position to (x1, y1) without drawing anything? If so, should we made the first control point explicit in the command rather than implicitly taken from the current position? That would then mirror the behavior written above for how the current position is left at the second-last control point.

We should clarify what it means to have two consecutive R or r commands.

We should add an example.

4.9. The bearing commands

The bearing commands (B or b) set the current bearing, which influences the orientation of subsequent relative path commands:

Command Name Parameters Description
B (absolute)
b (relative)
bearing angle+ Sets the current bearing. The parameter is an angle in degrees, where 0 indicates the direction of the positive x-axis. B (uppercase) sets the current bearing to the specified angle; b (lowercase) sets the current bearing to be the angle of the tangent at the end of the preceding path command plus the specified angle. The current point is unaffected. Although multiple parameters may be specified, this usually will not be useful, as they could be combined into a single angle value.

At the beginning of a path, the current bearing is 0, which points in the direction of the positive x-axis. The current bearing remains unchanged until a B or b command is encountered. Since the relative b command sets the current bearing relative to the tangent at the end of the preceding path command, it is possible to set the bearing to that tangent by using "b 0".

The example below shows how bearing commands can be used to draw a regular pentagon.

<svg xmlns="http://www.w3.org/2000/svg"
     width="300" height="100" viewBox="0 0 300 100">

  <path fill="#eee"
        stroke="deeppink" stroke-width="8px" stroke-linejoin="round"
        d="M 150,10
           B 36 h 47
           b 72 h 47
           b 72 h 47
           b 72 h 47 z"/>

</svg>
Image showing the use of the bearing command.

Bearing commands can be used to position the end points of the sides of a regular polygon without having to use trigonometry to calculate them based on the polygon's interior angles.

4.10. The grammar for path data

Update for new 'Z'/'z' behavior.

SVG path data matches the following EBNF grammar.

svg_path::= wsp* moveto? (moveto drawto_command*)?

drawto_command::=
    moveto
    | closepath
    | lineto
    | horizontal_lineto
    | vertical_lineto
    | curveto
    | smooth_curveto
    | quadratic_bezier_curveto
    | smooth_quadratic_bezier_curveto
    | elliptical_arc
    | bearing
    | catmull-rom

moveto::=
    ( "M" | "m" ) wsp* coordinate_pair_sequence wsp* closepath?

closepath::= 
    ("Z" | "z")

lineto::=
    ("L"|"l") wsp* (coordinate_pair_sequence | closepath)

horizontal_lineto::=
    ("H"|"h") wsp* coordinate_sequence

vertical_lineto::=
    ("V"|"v") wsp* coordinate_sequence

curveto::=
    ("C"|"c") wsp* (curveto_coordinate_sequence | (coordinate_pair_sequence? closepath))

curveto_coordinate_sequence::=
    coordinate_pair_triplet
    | (coordinate_pair_triplet comma_wsp? curveto_coordinate_sequence)

smooth_curveto::=
    ("S"|"s") wsp* (smooth_curveto_coordinate_sequence
    | (coordinate_pair_sequence? closepath))

smooth_curveto_coordinate_sequence::=
    coordinate_pair_double
    | (coordinate_pair_double comma_wsp? smooth_curveto_coordinate_sequence)

quadratic_bezier_curveto::=
    ("Q"|"q") wsp*
    (quadratic_bezier_curveto_coordinate_sequence | (coordinate_pair_sequence? closepath))

quadratic_bezier_curveto_coordinate_sequence::=
    coordinate_pair_double
    | (coordinate_pair_double comma_wsp? quadratic_bezier_curveto_coordinate_sequence)

smooth_quadratic_bezier_curveto::=
    ("T"|"t") wsp* (coordinate_pair_sequence | closepath)

elliptical_arc::=
    ( "A" | "a" ) wsp*
    (elliptical_arc_argument_sequence
    | (elliptical_arc_argument_sequence? elliptical_arc_closing_argument))

elliptical_arc_argument_sequence::=
    elliptical_arc_argument
    | (elliptical_arc_argument comma_wsp? elliptical_arc_argument_sequence)

elliptical_arc_argument::=
    number comma_wsp? number comma_wsp? number comma_wsp
    flag comma_wsp? flag comma_wsp? coordinate_pair

elliptical_arc_closing_argument::=
    number comma_wsp? number comma_wsp? number comma_wsp
    flag comma_wsp? flag comma_wsp? closepath

bearing::=
    ( "B" | "b" ) wsp* bearing_argument_sequence

bearing_argument_sequence::=
    number | (number comma_wsp? bearing_argument_sequence)

catmull-rom:
    ( "R" | "r" ) wsp* catmull-rom-argument-sequence
    
catmull-rom-argument-sequence:
    coordinate-pair coordinate-pair coordinate-pair+

coordinate_pair_double::=
    coordinate_pair comma_wsp? coordinate_pair

coordinate_pair_triplet::=
    coordinate_pair comma_wsp? coordinate_pair comma_wsp? coordinate_pair

coordinate_pair_sequence::=
    coordinate_pair | (coordinate_pair comma_wsp? coordinate_pair_sequence)

coordinate_sequence::=
    coordinate | (coordinate comma_wsp? coordinate_sequence)

coordinate_pair::= coordinate comma_wsp? coordinate

coordinate::= sign? number

sign::= "+"|"-"
number ::= ([0-9])+
flag::=("0"|"1")
comma_wsp::=(wsp+ ","? wsp*) | ("," wsp*)
wsp ::= (#x9 | #x20 | #xA | #xC | #xD)

The processing of the BNF must consume as much of a given BNF production as possible, stopping at the point when a character is encountered which no longer satisfies the production. Thus, in the string "M 100-200", the first coordinate for the "moveto" consumes the characters "100" and stops upon encountering the minus sign because the minus sign cannot follow a digit in the production of a "coordinate". The result is that the first coordinate will be "100" and the second coordinate will be "-200".

Similarly, for the string "M 0.6.5", the first coordinate of the "moveto" consumes the characters "0.6" and stops upon encountering the second decimal point because the production of a "coordinate" only allows one decimal point. The result is that the first coordinate will be "0.6" and the second coordinate will be ".5".

Note that the BNF allows the path d attribute to be empty. This is not an error, instead it disables rendering of the path.

If path data not matching the grammar is encountered, then the path data is in error (see Error Handling).

5. Implementation notes

5.1. Error handling in path data

A conforming SVG user agent must implement path rendering as follows:

6. Distance along a path

Various operations, including text on a path and motion animation and various stroke operations, require that the user agent compute the distance along the geometry of a graphics element, such as a path.

Exact mathematics exist for computing distance along a path, but the formulas are highly complex and require substantial computation. It is recommended that authoring products and user agents employ algorithms that produce as precise results as possible; however, to accommodate implementation differences and to help distance calculations produce results that approximate author intent, the pathLength attribute can be used to provide the author's computation of the total length of the path so that the user agent can scale distance-along-a-path computations by the ratio of pathLength to the user agent's own computed value for total path length.

A "moveto" or "bearing" operation within a path element is defined to have zero length. Only the various "lineto", "curveto" and "arcto" commands contribute to path length calculations.

7. DOM interfaces

7.1. Interface SVGPathSegment

The SVGPathSegment interface is a base interface that corresponds to a single command within a path data specification.
[NoInterfaceObject]
interface SVGPathSegment {
  DOMString type;
  sequence<float> values;
};
Attributes:
type (DOMString)
The type of the path segment as specified in the path grammar.
values (sequence<float>)
The values corresponding to the path segment.

7.2. Mixin SVGPathData

The SVGPathData interface provides a way to get and set path data.
dictionary SVGPathDataSettings {
   boolean normalize = false;
}

interface mixin SVGPathData {
   sequence<SVGPathSegment> getPathData(optional SVGPathDataSettings settings = {});
   undefined setPathData(sequence<SVGPathSegment> pathData);
};
Operations:
sequence<SVGPathSegment> getPathData(optional SVGPathDataSettings settings)
Returns the sequence of path segments that corresponds to the path data, optionally normalizing the values and segment types.

If no valid path data exists, returns an empty sequence.

Parameters
  1. optional SVGPathDataSettings settings
    The settings for the operation, if normalize is set to true then the returned sequence of path segments is converted to the base set of absolute commands ('M', 'L', 'C' and 'Z'), with the values adjusted accordingly.
Returns
The sequence of path segments corresponding to the path data.
undefined setPathData(sequence<SVGPathSegment> pathData)
Sets the sequence of path segments as the new path data.
Parameters
  1. sequence<SVGPathSegment> pathData
    The sequence of path segments.

7.3. Interface SVGPathElement

The SVGPathElement interface corresponds to the path element. The SVGPathData interface corresponds to the typed value of the d geometry property.
interface SVGPathElement : SVGGeometryElement {

  readonly attribute SVGAnimatedNumber pathLength;

  float getTotalLength();
  DOMPoint getPointAtLength(float distance);
  SVGPathSegment? getPathSegmentAtLength(float distance);
};

SVGPathElement includes SVGPathData;
Attributes:
pathLength (readonly SVGAnimatedNumber)
Corresponds to attribute pathLength on the given path element.
Operations:
float getTotalLength()
Returns the user agent's computed value for the total length of the path using the user agent's distance-along-a-path algorithm, as a distance in the current user coordinate system.
Returns
The total length of the path.
DOMPoint getPointAtLength(float distance)
Returns the (x,y) coordinate in local coordinate system which is distance units along the path, utilizing the user agent's distance-along-a-path algorithm. The distance shall be clamped to the range [0, total-length-of-path] before passing it to the distance-along-a-path algorithm.

If no valid path data exists, returns (0,0).

Parameters
  1. float distance
    The distance along the path, relative to the start of the path, as a distance in the current user coordinate system.
Returns
The returned point in local coordinate system.
SVGPathSegment? getPathSegmentAtLength(float distance)
Returns the SVGPathSegment which is distance units along the path, utilizing the user agent's distance-along-a-path algorithm. The distance shall be clamped to the range [0, total-length-of-path] before passing it to the distance-along-a-path algorithm.

If no valid path data exists, returns null.

Parameters
  1. float distance
    The distance along the path, relative to the start of the path, as a distance in the current user coordinate system.
Returns
The path segment, or null.

8. References

8.1. Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997.
Available at https://tools.ietf.org/html/rfc2119.
[SVG2]
Scalable Vector Graphics (SVG) 2, N. Andronikos, T. Bah, A. Bellamy-Royds, B. Birtles, C. Concolato, E. Dahlström, C. Lilley, C. McCormack, D. Schepers, D. Schulze, R. Schwerdtfeger, S. Takagi, J. Watt, eds. World Wide Web Consortium, 09 April 2015.
This edition of SVG 2 is http://www.w3.org/TR/2015/WD-SVG2-20150409/.
The latest edition of SVG 2 is available at https://www.w3.org/TR/SVG2/.
[UNICODE]
The Unicode Standard, Version 6.0.0, The Unicode Consortium, Mountain View, CA, 2011. ISBN 978-1-936213-01-6.
Available at https://www.unicode.org/versions/Unicode6.0.0.

9. Changes since SVG 2