SVG allows text to be inserted into the drawing. All of the same styling attributes available for paths and vector graphic shapes are also available for text. (See Filling, Stroking and Paint Servers.)
The <text> element adds text to a drawing.
In the example below, the string "Hello, out there" is drawn in blue:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG July 1999//EN"
"http://www.w3.org/Graphics/SVG/svg-19990706.dtd">
<svg width="4in" height="3in">
<text x=".5in" y="2in"
style="fill:blue">Hello, out there</text>
</svg>
<text> elements which are not positioned along a path (see Text On A Path below) can supply optional attributes x= and y= which represents the location in user coordinates (or Transformed CSS units or a percentage of the current viewport) for the initial current text position. Default values for x= and y= are zero in the user coordinate system. For left-aligned character strings, the placement point of the first glyph will be positioned exactly at the current text position and the glyph will be rendered based on the current set of text and font properties. After the glyph is rendered, the current text position is advanced based on the metrics of the glyph that were used along with the current set of text and font properties. For Roman text, the current text position is advanced along the x-axis by the width of that glyph. The cycle repeats until all characters in the <text> element have been rendered.
Within a <text> element, text and font properties and the current text position can be modified by including a <tspan> element. The <tspan> element can contain attributes style (which allows new visual rendering attributes to be specified) and the following attributes, which perform adjustments on the current text position:
The x= and dx= values are cumulative; thus, if both
are provided, the new current text position will have an X-coordinate
of x+dx. Similarly, if both x= and dx=
are provided, the new current text position will have a Y-coordinate
of y+dy.
(Internationalization issues need to be addressed.)
A <tspan> element can also be used to specify that the character data from a different element should be used as character data for the given <tspan> element. In the example below, the first <text> element (with id="TextToUse") will not draw because it is part of a <defs> element. The second <text> element draws the string "ABC". The third text element draws the string "XYZ" because it includes a <tspan> element which is a reference to element "TextToUse", and that element's character data is "XYZ":
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG July 1999//EN"
"http://www.w3.org/Graphics/SVG/svg-19990706.dtd">
<svg width="4in" height="3in">
<defs>
<text id="TextToUse">XYZ</text>
</defs>
<text>ABC</text>
<text>
<tspan href="#TextToUse"/>
</text>
</svg>
If a <tspan> element has both an href attribute and its own character data, the character data from the href attribute draws before its own character data.
SVG supports the standard XML attribute xml:space for determining how it should handle white space characters within a given <text> element's character data. xml:space is an inheritable attribute which can have one of two values:
xml:space="default", the SVG user agent will do the following.
First, it will convert
all carriage returns, linefeeds and tab characters into space characters.
Then, it will drop all strip off all leading and trailing space characters.
Finally, it will consolidate all contiguous space characters into a single
space character. (This algorithm is very close to standard practice in
HTML4 web browsers.)xml:space="preserve", the SVG user agent will do the following.
It will convert
all carriage returns, linefeeds and tab characters into space characters.
Then, it will draw all space characters, including leading, trailing and
multiple contiguous space characters. Thus, when drawn with xml:space="preserve",
the string "a b"
(three spaces between "a" and "b") will produce a larger separation between
"a" and "b' than "a b"
(one space between "a" and "b").SVG user agents running on systems with have clipboards for copy/paste operations and which are equipped with input devices that allow for text selection should support the selection of text from an SVG document and the ability to copy selected text strings to the system clipboard.
Within an SVG user agent which supports text selection and pointer devices such as a mouse, the following behavior should exist. When the pointing device is clicked over an SVG character and then dragged, then whenever the mouse goes over another character defined within the same <text> elements, all characters whose position in the document is between the initial character and the current character should be highlighted, no matter where they might be located on the canvas.
When feasible, generators of SVG should attempt to order their text strings to facilitate properly ordered text selection within SVG viewing applications such as Web browsers.
(Descriptions (or references to the CSS2 spec) for all of the text and font properties from CSS2 go here. The following are SVG-specific text properties which go beyond the text and font properties already defined in CSS2:)
There are situations such as ligatures, special-purpose fonts (e.g., a font for music symbols) or alternate glyphs for Asian text strings where a different glyph should be used to render some text than the glyph which normally corresponds to the given character data. Also, the W3C Character Model (??? add link) requires early normalization of character data to facilitate meaningful and unambiguous exchange of character data and correct comparisons between character strings. The W3C Character Model will bring about many common situations where the normalized character data will be different than the glyphs which the user want to use to render that character data.
To allow for control over the glyphs used to render particular character data, the 'altglyph' property is available.
| Value: | unicode(<value>) |
glyphname(<string>) | glyphid(<value>) | ROS(<value>) cid(<value>) | inherit |
| Initial: | none |
| Applies to: | <text> elements |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
In addition to text drawn in a straight line, SVG also includes the ability to place text along the shape of a <path> element. The basic algorithm is such that each glyph is positioned at a specific point on the path, with the glyph getting rotated such that the baseline of the glyph is either parallel or tangent to the tangent of the curve at the given point. Here are some examples of text on a path:
(??? include some drawings here )
The following is a simple example which illustrates many of the basic concepts:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG July 1999//EN"
"http://www.w3.org/Graphics/SVG/svg-19990706.dtd">
<svg width="4in" height="3in">
<desc>Simple text on a path
</desc>
<path id="MyPath" style="visibility: hidden"
d="M 100 100 C 125 125 175 125 200 100" />
<text>
<textpath href="#MyPath">Text on path</textpath>
</text>
</svg>
The start-offset attribute defines the distance from the start of the path where the first character should be positioned.
Various CSS properties control aspects of text drawn along a path. The standard set of text and font properties from CSS2 apply, including 'text-align' and 'vertical-align'. Additional, the following additional properties control how the text is formatted and rendered:
Text on a path opens the possibility of significant implementation differences due to different methods of calculating distance along a path. In order to ensure that distance calculations are sufficiently precise, the following two attributes are available on <path> elements. (??? Obviously, this section needs to be moved to the <path> element section.)
SVG's text on a path features set has been generalized to allow for arbitrary SVG along a path, by adding the use element as a valid child of text.