Each
'text' element
causes a single string of text to be rendered. SVG performs no automatic line breaking
or word wrapping.
To achieve the effect of multiple lines of text:

The author or authoring package
needs to
pre-compute the line breaks
and use multiple
'text' elements (one for each line of text).

The author or authoring package
needs to
pre-compute the line breaks
and use a single
'text' element with one or more
'tspan' child elements with appropriate values for attributes
x,
y,
dx and
dy
to set new start positions for those characters which start new lines.
(This approach allows user text selection across multiple lines of text --
see Text selection and clipboard operations.)

Express the text to be rendered in
another XML namespace such as XHTML [XHTML10]
embedded inline within a
'foreignObject'
element. (Note: the exact semantics of this approach are not completely
defined at this time.)

The text strings within 'text' elements can be rendered in a straight line or rendered
along the outline of a
'path' element.
SVG supports the following international text processing features
for both straight line text and text on a path:

For accessibility reasons,
it is recommended that text which is included in a document
have appropriate semantic markup to indicate its function.
See SVG accessibility guidelines
for more information.

10.2 Characters and their corresponding glyphs

In XML [XML10], textual content
is defined in terms of XML characters,
where each character is defined by a particular character (i.e., code point) in
Unicode [UNICODE].
Fonts, on the other hand, consists of a collection of
glyphs, where each glyph
consists of some sort of identifier (in some cases a string,
in other cases a number) along with drawing instructions for rendering
that particular glyph.

In many cases, there is a one-to-one mapping of Unicode characters (i.e., Unicode code points)
to glyphs in a font. For example, it is common for a Roman font
to contain a single glyph for each of the standard ASCII
characters (i.e., A-to-Z, a-to-z, 0-to-9, plus the various
punctuation characters found in ASCII). Thus,
in most situations, the string "XML",
which consists of three Unicode characters, would be rendered
by the three glyphs corresponding to "X", "M" and "L", respectively.

In various other cases, however, there is not a strict one-to-one
mapping of Unicode characters to glyphs. Some of the circumstances
when the mapping is not one-to-one:

Ligatures - For best looking typesetting, it is often desirable
that particular sequences of characters are rendered as
a single glyph. An example is the word "office". Many fonts
will define an "ffi" ligature. When the word "office" is
rendered, sometimes the user agent will render the glyph for the "ffi" ligature
instead of rendering distinct glyphs (i.e., "f", "f" and "i") for each
of the three characters. Thus, for ligatures, multiple Unicode
characters map to a single glyph.

Composite characters - In various situations, commonly used
adornments such as diacritical marks will be stored once in a font
as a particular glyph and then composed with one or more other glyphs to
result in the desired character. For example, it is possible that
a font engine might render the é character by first rendering
the glyph for e and
then rendering the glyph for ´ (the accent mark)
such that the accent mark will appear over the e.
In this situation, a single Unicode character
map to multiple glyphs.

Glyph substitution - Some typography systems examine the nature of the
textual content and utilize different glyphs in different circumstances.
For example, in Arabic, the same Unicode character might render as
any of four different glyphs, depending on such factors as whether
the character appears at the start, the end or the middle of a text string.
In these situations, a single Unicode character might map to one of
several alternative glyphs.

Alternative glyph specification - SVG contains a facility for
the author to explicitly specify that a particular sequence of Unicode
characters
is to
be rendered using a particular glyph.
(See Alternate glyphs.)
When this facility is used, multiple Unicode characters map to a single glyph.

In many situations, the algorithms for mapping from characters to glyphs are system-dependent,
resulting in the possibility that the rendering of text might be (usually slightly) different when
viewed in different user environments. If the author of SVG content requires
precise selection of fonts and glyphs, then the recommendation is that the necessary fonts
(potentially subsetted to only include only the glyphs needed for the given document)
be available either as SVG fonts
embedded within the SVG content
or as web fonts
posted at the same web location as the SVG content.

10.3 The 'text' element

The 'text' element defines a
graphics element
consisting of text. The XML [XML10]
character data within the 'text' element,
along with relevant attributes and properties and character-to-glyph
mapping tables within the font itself, define the
glyphs to be rendered. (See Characters and their corresponding glyphs.)
The attributes and properties on the
'text' element
indicate such things as the
writing direction, font specification and painting attributes
which describe how exactly to
render the characters.
Subsequent sections of this chapter describe the relevant text-specific attributes and properties.

The 'text' renders its first character at the
initial current text position, which is
established by the
x and
y
attributes.
After the glyph(s) corresponding to the given character is(are) rendered,
the current text position is updated
for the next character. In the simplest case, the new current text position
is the previous current text position plus the glyphs' text advance value
(horizontal or vertical).
See text layout for a description of glyph placement
and glyph advance.

The X-coordinate for the initial current text position
for the text to be drawn. If the value is expressed as a simple
<number> without
a unit identifier (e.g., 48), then
the value represents a coordinate in the current user coordinate system.
If one of the CSS unit identifiers
is provided (e.g., 12pt
or 10%), then the value represents
a distance in viewport units relative to
the origin of the user coordinate system.
(See Processing rules for CSS units and percentages.)
The default value is "0".
Animatable: yes.

y = "<coordinate>"

The corresponding Y-coordinate for the initial current text position.
The default value is "0".
Animatable: yes.

Example text01 below expresses
all values in
physical units such as centimeters and points.
The 'text' element
contains the text string "Hello, out there" which will be rendered onto the canvas
using the Verdana font family with font size of 12 points
with the glyphs filled with the color blue.

If a single <coordinate>
is provided,
this value represents the new absolute X coordinate for the current text position
for the first character
within the 'tspan' element.
If a comma- or space-separated list of <n>
<coordinate>s is provided,
then the values represent new absolute X coordinates for the current text position
for the first <n> characters within the 'tspan' element.
If more <coordinate>s
are provided than characters, then
the extra <coordinate>s
will have no effect on glyph positioning.
If more characters exist than
<coordinate>s, then
the starting X coordinate of each extra character is positioned at the
X coordinate of the resulting current text position from rendering the previous
character within the
'text'
element.
CSS unit identifiers,
such as
cm,
pt or
%,
can be provided for any
<coordinate>.
If a <coordinate>
is provided without
a unit identifier (e.g., 48), then
the value represents a coordinate in the current user coordinate system.
If a CSS unit identifier is provided (e.g., 12pt
or 10%), then the value represents
a distance in viewport units relative to
the origin of the user coordinate system.
(Processing rules for CSS units and percentages.)
The default value is "0".
Animatable: yes.

If a single <coordinate> is provided,
this value represents the new relative X coordinate for the
current text position
for the first character
within the 'tspan' element.
Thus, the current text position
is shifted along the X axis of the current user coordinate system
by <coordinate>.
If a comma- or space-separated list of <n>
<coordinate>s is provided,
then the values represent new relative X coordinates for the
current text position
for the first <n> characters within the 'tspan' element.
Thus, before each character is rendered,
the current text position resulting from drawing the previous character
(or, for the first character in a
'text'
element, the initial current text position)
is shifted along the X axis of the current user coordinate system
by <coordinate>.
If more <coordinate>s are provided than characters, then
any extra <coordinate>s will have no effect on glyph positioning.
If more characters exist than <coordinate>s, then
the starting X coordinate of each extra character is positioned at the
X coordinate of the resulting current text position
from rendering the previous character within the
'text'
element.
CSS unit identifiers,
such as
cm,
pt or
%,
can be provided for any <coordinate>.
If a <coordinate> is provided without
a unit identifier (e.g., 48), then
the value represents a length along the X axis in the current user coordinate system.
If one of the CSS unit identifiers
is provided (e.g., 12pt
or 10%), then the value represents
a distance in the viewport coordinate system.
(Processing rules for CSS units and percentages.)
The default value is "0".
Animatable: yes.

A value of auto causes all characters
to be oriented as specified by other text attributes without any supplemental
rotation.
If a single <number> is provided,
then this value represents a supplemental rotation about the
current text position
that will be applied to each glyph corresponding to each character within the
'tspan' element.
If a comma- or space-separated list of
<number>s is provided,
then the first <number> represents the supplemental rotation of the first character,
the second <number> represents the supplemental rotation of the second character,
and so on. If more <number>s are provided than there are characters, then the
extra <number>s will be ignored. If more characters are provided than <number>s,
then the extra characters will be rotated by the last <number> in the list.
This supplemental rotation has no impact on the rules by which
current text position
is modified as glyphs get rendered.
The default value is "auto".
Animatable: yes (non-additive, 'set' and 'animate' elements only).

The
x,
y,
dx,
dy and
rotate
on the 'tspan'
element are useful in high-end typography scenarios
where individual glyphs requires exact placement.
These attributes are useful for minor positioning adjustments between characters
or for major positioning adjustments, such as moving the current text position
to a new location to achieve the visual effect of a new line of text.
Multi-line 'text'
elements are possible by defining different
'tspan' elements for each line of text, with attributes
x,
y,
dx and/or
dy
defining the position of each 'tspan'.
(An advantage of such an approach is that users
will be able to perform multi-line text selection.)

In situations where advanced typographic control
is required and micro-level positioning adjustment are necessary,
the SVG content designer needs to ensure that the necessary font
will be available for all viewers of the document (e.g., package
up the necessary font data in the form of an SVG font or an alternative web font format which is
stored at the same web site as the SVG content) and that the
viewing software will process the font in the expected way
(the capabilities, characteristics and font layout mechanisms vary
greatly from system to system).
If the SVG content contains
x,
y,
dx or
dy
attribute values which are meant to correspond to a particular font
processed by a particular set of viewing software
and either of these requirements is not met, then
the text
might
display with poor quality.

The following additional rules apply to attributes
x,
y,
dx,
dy,
rotate
when they contain a list of numbers:

Required behavior when multiple XML characters map to a single glyph
(e.g., when a ligature is used) -
Assume that the i-th and
(i+1)-th XML characters map to a single glyph.
In this case, the i-th value for the
x,
y,
dx,
dy and
rotate
attributes all apply when rendering the glyph.
For the (i+1)-th values, however,
the
x,
y and
rotate
value are not applied (although the final
rotate
value would still apply to subsequent characters), whereas the
dx and
dy
are applied to the subsequent XML character
(i.e., the (i+2)-th character), if one exists.

Relationship to right-to-left text and bi-directionality -
Text is laid out in a two-step process, where any right-to-left and bi-directional text
is first re-ordered into a left-to-right string, and then text layout occurs with the re-ordered text string.
Whenever the character data within a 'tspan' element is re-ordered,
the corresponding elements within the
x,
y,
dx,
dy and
rotate
are also re-ordered to maintain the correspondence.
For example, suppose that you have the following
'tspan' element:

and that the word "Arabic" will be drawn right-to-left. First, the character data and
the corresponding values in the
dx
list will be reordered, such that the text string will be "Roman and cibarA"
and the list of values for the
dx
attribute will be "11 12 13 14 15 0 21 22 23 0 36 35 34 33 32 31".
After this re-ordering, the characters will be positioned using standard
left-to-right layout rules.

Nested 'tspan' elements - The
x,
y,
dx,
dy and
rotate
attributes on a given 'tspan' element apply only to the
character data that is directly within that
'tspan' element and do not apply to the
character data within child (i.e., nested) 'tspan' elements.
If the child/nested 'tspan' elements
require positioning adjustments or rotation values,
the child/nested 'tspan' elements
need to
specify
x,
y,
dx,
dy and
rotate
values for their own character data.

The following examples show basic use of the 'tspan' element.

Example tspan01 uses a
'tspan'
element to indicate that the
word "not" is to use a bold font and have red fill.

Example tspan03 uses the
x and
y attributes on the
'tspan'
to establish a new absolute current text position
for each glyph to be rendered.
The example shows two lines of text within a single
'text' element.
Because both lines of text are within the same
'text' element,
the user will be able to select through both lines of text and copy the
text to the system clipboard
in user agents that support text selection and clipboard operations,

10.5 The 'tref' element

The textual content for a
'text'
can be either character data directly embedded within the
'text'
element or the character data content of a referenced element, where the
referencing is specified with a 'tref' element.

All character data within the referenced element, including character data
enclosed within additional markup, will be rendered.

The
x,
y,
dx,
dy and
rotate
attributes have the same meanings as for the
'tspan'
element. The attributes are applied as if the 'tref'
element was replaced by a 'tspan' with the referenced
character data (stripped of all supplemental markup)
embedded within the hypothetical 'tspan' element.

Example tref01 shows how to use character data
from a different element as the character data for a given
'tspan' element.
The first
'text'
element (with id="ReferencedText")
will not draw because
it is part of a
'defs'
element. The second
'text'
element draws the
string "Inline character data".
The third
'text'
element draws the string "Reference character data" because it includes
a 'tspan' element
which is a reference to element "ReferencedText", and that
element's character data is "Referenced character data".

10.6 Text layout

10.6.1 Text layout introduction

This section describes the text layout features
supported by SVG, which includes support for various international
writing directions, such as left-to-right (e.g., Roman scripts),
right-to-left (e.g., Hebrew or Arabic),
bi-directional (e.g., mixing Roman with Arabic) and vertical (e.g., Asian scripts).
The descriptions in this section assume straight line text (i.e., text
that is either strictly horizontal or vertical with respect to the
current user coordinate system). Subsequent sections describe the
supplemental layout rules for text on a path.

Because SVG does not provide for automatic line breaks or word wrapping,
internationalized text layout is simpler in SVG than in languages such
as XHTML [XHTML10].

In processing a given
'text'
element, the SVG user agent keeps track of the current text position.
The initial current text position
is established by the
x and
y
attributes on the
'text'
element. The current text position
is adjusted after each glyph to establish a new
current text position
at which the next glyph
shall
be rendered.
The adjustment to the current text position
is based on the current text advance direction,
the glyph orientation relative to the text advance direction,
the metrics of the glyph just rendered,
kerning tables in the font
and the current values of various attributes and properties,
such as
the spacing properties
and any
x,
y,
dx and
dy
attributes on
'tspan'
elements.

For each glyph to be rendered, the SVG user agent determines
an appropriate reference point on the glyph
which will be placed exactly
at the current text position.
The reference point is determined
based on character cell metrics in the glyph itself,
the current text advance direction and
the glyph orientation relative to the text advance direction
For the most common uses of Roman text
(i.e.,
'writing-mode:lr',
'text-anchor:start',
and
'glyph-anchor:baseline')
the reference point in the glyph will be the intersection
of left edge of the glyph character cell (or some other glyph-specific X axis coordinate
indicating a left-side origin point)
with the baseline of the glyph.
For most cases with top-to-bottom vertical text layout,
the reference point will be
either a glyph-specific origin point for top-to-bottom vertical text or the
intersection of the center of the glyph with its top line
(see [CSS2] for a definition of top line).

The various text layout diagrams in this section
use the following symbols:

- wide-cell glyph (e.g. Han) which is the
n-th character in the text run - narrow-cell glyph (e.g. Roman) which is
the n-th glyph in the text run - connected glyph (e.g. Hebrew or Arabic) which is the
n-th glyph in the text run

The orientation which the above symbols assume in the diagrams corresponds
to the orientation that the glyphs they represent are intended to assume
when rendered in the user agent. Spacing between these characters in the diagrams
is usually symbolic, unless intentionally changed to make a point.

10.6.2 Setting the primary text advance direction

The 'writing-mode'
property specifies whether the primary text advance direction for a
'text'
element
shall
be left-to-right, right-to-left, or top-to-bottom.
The 'writing-mode' property applies only to
'text'
elements; the property is ignored for
'tspan',
'tref' and
'textPath' sub-elements.
(Note that even when the primary text advance direction if left-to-right or right-to-left, some or
all of the content within a given
'text'
element might advance in the opposite direction because of the Unicode [UNICODE]
bi-directional algorithm or
because of explicit text advance overrides due to properties
'direction' and
'unicode-bidi'.
For more on bi-directional text, see
Relationship with bi-directionality.)

Sets the primary text advance direction to left-to-right, as is common in
most Roman-based documents. For most characters,
the current text position is advanced from left to right
after each glyph is rendered.
(When the character data includes
characters which are subject to the Unicode bi-directional algorithm,
the text advance rules are more complex.
See Relationship with bi-directionality).

rl-tb | rl

Sets the primary text advance direction to right-to-left, as is common in
Arabic or Hebrew scripts.

tb-rl | tb

Sets the primary text advance direction to top-to-bottom, as is common in Asian scripts. Though hardly
as frequent as horizontal, this type of vertical layout also occurs in Latin based
documents, particularly in table column or row labels. In most cases, the vertical baselines
running through the middle of each glyph are aligned.

10.6.3 Glyph orientation with a text run

In some cases, it is required to alter the orientation of a sequence of
characters relative to the primary text advance direction.
The requirement is particularly applicable to vertical layouts of East Asian documents,
where sometimes half-width Roman text is to be displayed horizontally and other
times vertically.

The value of the angle is a <integer>
restricted to the range of -360 to +360 in 90-degree increments.
A value of 0 indicates that all glyphs are oriented with the bottom of the glyphs
toward the primary text advance direction, resulting in glyphs which are
stacked vertically on top of each other. A value of 90 indicates a rotation of
90 degrees clockwise from the "0" orientation. Negative angle values are computed
modulo 360; thus, a value of -90
is equivalent to a value of 270.

auto

The glyph orientation relative to the primary text advance direction is determined
automatically based on the Unicode character number of the rendered glyph.

Full-width ideographic and full-width Roman glyphs (excluding ideographic punctuation)
are oriented as if an <angle> of "0" had been specified
(i.e., glyphs are oriented with the bottom of the glyphs
toward the primary text advance direction, resulting in glyphs which are
stacked vertically on top of each other).

Ideographic punctuation and other ideographic
characters having alternate horizontal and vertical forms
shall
use the vertical form of
the glyph.

Text which is not full-width will be set as if an <angle> of "90" had been specified;
thus, half-width Roman text will be rotated 90 degree clockwise versus full-width
ideographic and full-width Roman text.

Note that a value of auto will generally produce
the expected results in common uses of mixing Japanese with European characters;
however, the exact algorithms are based on complex interactions between many factors,
including font design, and thus different algorithms might be employed in different
processing environments. For precise control, specify explicit <angle> values.

The glyph orientation affects the amount that the current text position advances
as each glyph is rendered. When the primary text advance direction is vertical
and the 'glyph-orientation-vertical' results in
an orientation angle that is a multiple of 180 degrees, then the current text
position is incremented according to the vertical metrics of the glyph.
Otherwise, if the 'glyph-orientation-vertical' results in
an orientation angle that is not a multiple of 180 degrees, then the
current text position is incremented according to the horizontal metrics of the glyph.

The diagrams below illustrate different uses of
'glyph-orientation-vertical'.
The diagram on the left shows the result of
the mixing of full-width ideographic characters
with half-width Roman characters when
'glyph-orientation-vertical'
for the Roman characters is either auto
or 90. The diagram on the right
show the result of mixing full-width ideographic characters with
half-width Roman characters when
Roman characters are specified to have a 'glyph-orientation-vertical'
of 0.

The value of the angle is a <integer>
restricted to the range of -360 to +360 in 90-degree increments.
A value of 0 indicates that all glyphs are oriented with the
right edge of the glyphs
toward the primary text advance direction, resulting in glyphs which are positioned
side by side.
A value of 90 indicates an orientation of
90 degrees clockwise from the "0" orientation. Negative angle values are computed
modulo 360; thus, a value of -90
is equivalent to a value of 270.

The glyph orientation affects the amount that the current text position advances
as each glyph is rendered. When the primary text advance direction is horizontal
and the 'glyph-orientation-horizontal' results in
an orientation angle that is a multiple of 180 degrees, then the current text
position is incremented according to the horizontal metrics of the glyph.
Otherwise, if the 'glyph-orientation-vertical' results in
an orientation angle that is not a multiple of 180 degrees, then the
current text position is incremented according to the vertical metrics of the glyph.

10.6.4 Relationship with bi-directionality

The characters in certain scripts are written from right to left. In some documents,
in particular those written with the Arabic or Hebrew script, and in some
mixed-language contexts, text in a single line may appear
with mixed directionality. This phenomenon is called bidirectionality, or "bidi" for
short.

The Unicode standard ([UNICODE], section 3.11)
defines a complex algorithm
for determining the proper directionality of text. The algorithm consists of an
implicit part based on character properties, as well as explicit controls for embeddings
and overrides. The SVG user agent applies this bidirectional algorithm
when determining the layout of characters within a
'text'
element. The
'direction'
and
'unicode-bidi'
properties allow authors to override the inherent directionality of the
content characters and thus explicitly control
how the elements and attributes of a document language map to this algorithm.
These two properties are only applicable when the primary text advance direction is horizontal.

Because the directionality of a text depends on the structure and semantics of
the document language, in most cases these properties
will
be used only by
designers of document type descriptions (DTDs) or authors of special documents.

A more complete discussion of bi-directionality can be found in the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2].

The processing model for right-to-left or bi-directional horizontal text is as follows.
The user agent processes the characters which are provided in lexical order
and re-orders the characters after processing the Unicode bi-directional algorithm
and properties
'direction' and
'unicode-bidi',
resulting in a potentially re-ordered list of characters which are now in left-to-right rendering order.
Simultaneous with re-ordering of the characters, the
x,
y,
dx,
dy and
rotate
attributes on the
'tspan' and
'tref'
elements are also re-ordered to maintain the original correspondence between characters
and attribute values. While kerning or ligature processing might be font-specific, the preferred model
is that kerning and ligature processing occurs between combinations of characters or glyphs
after the characters have been re-ordered.
Similarly, text selection occurs on the re-ordered text
(i.e., based on visual layout rather than lexical layout).

When included in a
'text'
element whose primary text advance direction is vertical, Arabic text
has a default orientation where the glyphs are rotated 90 degrees
counter-clockwise from standard vertically-oriented glyphs, making
the default orientation of the Arabic glyphs the same as for half-width Roman glyphs.

This property specifies the base writing direction of text
and the direction of embeddings and overrides (see
'unicode=bidi')
for the Unicode bidirectional algorithm.
For the 'direction' property to have any effect, the
'unicode=bidi'
property's value must be 'embed' or 'override'.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for the specification for this property.

The 'direction' property applies only to
text whose
glyph orientation
has the right edge of the glyphs oriented in the same direction as the
primary text advance direction,
which includes the usual case of horizontally-oriented Roman or Arabic text and
the case of half-width Roman or Arabic characters rotated 90 degrees clockwise
relative to a top-to-bottom primary text advance direction.

This property, which applies only to
'text'
elements and is ignored for elements
'tspan',
'tref' and
'textPath',
describes how the characters within a
'text'
element
are
aligned relative to the initial current text position for
the 'text' element. Values
have the following meanings:

start

The rendered characters
are
aligned such that the start
of the text string is at the initial current text position.
For standard Roman text, this is comparable to left alignment.
For Asian text with a vertical primary text direction, this
is comparable to top alignment.

middle

The rendered characters
are
al current text position.
For standard Roman text, this is comparable to center alignment.

end

The rendered characters
are
aligned such that the end
of the text string is at the initial current text position.
For standard Roman text, this is comparable to right alignment.

This property, which only applies to glyphs rendered horizontally (i.e., bottom of the
glyph is parallel to the primary text advance direction),
describes the vertical alignment of glyphs relative to the
current text position. Values
have the following meanings:

text-top

Align the glyph vertically relative such that the top of the glyph is aligned with
the current text position.
(Refer to the discussion of text-top under SVG fonts
and the "text-top" value for the 'vertical-align' property in [CSS2].)

topline

Align the glyph vertically such that the "topline" of the glyph is aligned with the current text position.
(Refer to the discussion of topline under SVG fonts
and the "topline" font descriptor described in [CSS2].)

hanging

Align the glyph vertically such that the "hanging" position of the glyph is aligned with the current text position.
(Refer to the discussion of hanging under SVG fonts.)

mathline

Align the glyph vertically such that the "mathline" of the glyph is aligned with the current text position.
(Refer to the discussion of mathline under SVG fonts
and the "mathline" font descriptor described in [CSS2].)

centerline

Align the glyph vertically such that the "centerline" of the glyph is aligned with the current text position.
(Refer to the discussion of centerline under SVG fonts
and the "centerline" font descriptor described in [CSS2].)

baseline

Align the glyph vertically such that the "baseline" of the glyph is aligned with the current text position.
(Refer to the discussion of baseline under SVG fonts
and the "baseline" font descriptor described in [CSS2].)

ideographic

Align the glyph vertically such that the "ideographic" position of the glyph is aligned with the current text position.
(Refer to the discussion of ideographic under SVG fonts.)

text-bottom

Align the glyph vertically relative such that the bottom of the glyph is aligned with
the current text position.
(Refer to the discussion of text-bottom under SVG fonts
and the "text-bottom" value for the 'vertical-align' property in [CSS2].)

This property, which only applies to glyphs rendered horizontally (i.e., bottom of the
glyph is parallel to the primary text advance direction),
provides for vertical adjustment of the current text position.
Property values are cumulative; thus, the
'baseline-shift' value for the
current element is added to all of the
'baseline-shift' values for its ancestors
up to its parent 'text' element.
Values
have the following meanings:

This property which font family is to be used to render the text,
specified as a prioritized list of font family names
and/or generic family names. Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property specifies whether the text is to be rendered using a normal,
italic or oblique face. Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property indicates whether the text is to be rendered using the normal glyphs
for lowercase characters or using small-caps glyphs for lowercase characters.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property refers to the boldness or lightness of the glyphs used to render
the text, relative to other fonts in the same font family.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property indicates the desired amount of condensing or expansion
in the glyphs used to render the text.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property refers to the size of the font from baseline to baseline
when multiple lines of text are set solid in a multiline layout environment.
For SVG, if a <length>
is provided without a unit identifier (e.g., an unqualified number
such as 128), the
SVG user agent processes the <length>
as a height value in the current user coordinate system.

If a <length> is provided with one of the
CSS unit identifiers
(e.g., 12pt
or 10%), then the
SVG user agent converts the <length> into a corresponding
value in the current user coordinate system by applying the
processing rules for CSS units and percentages.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property allows authors to specify an aspect value for an element that will
preserve the x-height of the first choice font in a substitute font.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

Shorthand property for setting 'font-style', 'font-variant', 'font-weight',
'font-size', 'line-height' and 'font-family'. The 'line-height' property has no visual effect in SVG.
Conforming SVG Viewers are not required to
support the various system font options (caption, icon, menu, message-box, small-caption and status-bar)
and can use a system font or one of the generic fonts instead.

Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

10.9 Spacing properties

This property specifies spacing behavior between
text characters.
For SVG, if a <length>
is provided without a unit identifier (e.g., an unqualified number
such as 128), the
SVG user agent processes the <length>
as a width value in the current user coordinate system.

If a <length> is provided with one of the
CSS unit identifiers
(e.g., .25em
or 1%), then the
SVG user agent converts the <length> into a corresponding
value in the current user coordinate system by applying the
processing rules for CSS units and percentages.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

This property specifies spacing behavior between words.
For SVG, if a <length>
is provided without a unit identifier (e.g., an unqualified number
such as 128), the
SVG user agent processes the <length>
as a width value in the current user coordinate system.

If a <length> is provided with one of the
CSS unit identifiers
(e.g., .25em
or 1%), then the
SVG user agent converts the <length> into a corresponding
value in the current user coordinate system by applying the
processing rules for CSS units and percentages.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

10.10 Text decoration

This property describes decorations that are added to the text of
an element.
Conforming SVG Viewers
are not required to support the blink value.
Refer to the
"Cascading Style Sheets (CSS) level 2" specification
[CSS2] for more information about this property.

10.11 Text on a path

10.11.1 Introduction to text on a path

In addition to text drawn in a straight line, SVG also includes the ability to place text
along the shape of a
'path'
element. To specify that a block of text
is to
be rendered along the shape of a
'path',
include the given text within a
'textPath'
element which includes an
xlink:href
attribute with a
URI reference
to a
'path'
element.

An offset from the start of the
'path'
for the initial current text position, calculated using the user agent's
distance along the path algorithm.
If a <length> without a percentage
is given, then the startOffset represents a distance along the path
measured in the current user coordinate system.
If a <percentage>
is given, then the
startOffset
represents a percentage distance along the entire path. Thus,
startOffset="0%" indicates the start point of the
'path'
and startOffset="100%" indicates the end point of the
'path'.
Animatable: yes.

A URI reference to the
'path'
element onto which the glyphs will be rendered. If
<uri> is an
invalid reference (e.g., no such element exists, or the referenced element is not a
'path'),
then the
'textPath' element is in error and its entire contents
shall
not be rendered by the user agent.
Animatable: yes.

Example toap02 shows how
'tspan'
elements can be included within
'textPath'
elements to adjust styling attributes and adjust the
current text position before rendering a particular glyph.
The first occurrence of the word "up" is filled with the
color red. Attribute
dy
is used to lift the word "up" from the baseline.

Example toap03 demonstrates the use of the
startOffset attribute on the
'textPath'
element to specify the start position of the text string
as a particular position along the path. Notice that glyphs that fall off the
end of the path are not rendered
(see text on a path layout rules).

The following picture does an initial zoom in on the first glyph in the
'text' element.

The small dot above shows
the point at which the glyph is attached to the path.
The box around the glyph shows the glyph
is rotated such that its horizontal axis is parallel to the tangent of the curve
at the point at which the glyph is attached to the path. The box also shows
the glyph's charwidth (i.e., the amount which the
current text position advances horizontally
when the glyph is drawn using horizontal text layout).

The next picture zooms in further to demonstrate the detailed layout rules.

For horizontal text layout along a path, the layout rules are as follows:

Determine the
startpoint-on-the-path
for the first glyph using attribute
startOffset
and, if present, the
dx attribute
on a
'tspan' element.
(In the picture above, the startpoint-on-the-path
is the leftmost dot on the path.)

Determine the glyph's charwidth (i.e., the amount which the
current text position advances horizontally
when the glyph is drawn using horizontal text layout). (In the picture above,
the charwidth is the distance between the two dots
at the side of the box.)

Determine the point on the curve which is charwidth distance along the
path from the startpoint-on-the-path for this glyph, calculated using the user agent's
distance along the path algorithm.
This point is the endpoint-on-the-path for the glyph.
(In the picture above, the endpoint-on-the-path for the glyph is
the rightmost dot on the path.)

Determine the midpoint-on-the-path, which is the point on the path which
is "halfway" (user agents can choose either a distance calculation or a parametric calculation)
between the startpoint-on-the-path and the
endpoint-on-the-path.
(In the picture above, the midpoint-on-the-path is shown as a white dot.)

Determine the glyph-midline,
which is the vertical line in the glyph's coordinate system
that goes through the glyph's x-axis midpoint. (In the picture above,
the glyph-midline is shown as a dashed line.)

Position the glyph such that the glyph-midline
passes through the midpoint-on-the-path and is perpendicular to the line
through the startpoint-on-the-path and the
endpoint-on-the-path.

Align the glyph vertically relative to the midpoint-on-the-path based on property
'glyph-anchor'
and any specified values for attribute
dy
on a
'tspan' element.
In the example above, the
'glyph-anchor'
property is unspecified, so the initial value of
'glyph-anchor:baseline'
will be used. There are no
'tspan' elements;
thus, the baseline of the glyph is aligned to the midpoint-on-the-path.

For each subsequent glyph, set a new startpoint-on-the-path
as the previous endpoint-on-the-path, but with appropriate adjustments
taking into account kerning tables in the font and current values of various attributes and properties,
including spacing properties and
'tspan' elements with values
provided for attributes
dx and
dy. All adjustments
are calculated as distance adjustments along the path, calculated using the user agent's
distance along the path algorithm.

Glyphs whose midpoint-on-the-path are off the end of the path
are not rendered.

Continue rendering glyphs until there are no more glyphs.

In the calculations above, if either the startpoint-on-the-path
or the endpoint-on-the-path is off the end of the path,
then extend the path beyond its end points with a straight line
that is parallel to the tangent at the path at its end point so that the
midpoint-on-the-path can still be calculated.

For
'tspan' elements
that are children of
'textPath' elements,
x and
y
attributes on
'tspan' elements
have no effect on text layout.

Vertical, right-to-left and bi-directional
text layout rules
also apply to text on a path. Conceptually, the target
path is stretched out into either a horizontal or vertical straight line segment.
For horizontal text layout flows, the path is stretched out into a hypothetical
horizontal line segment such
that the start of the path is mapped to the left of the line segment.
For vertical text layout flows, the path is stretched out into a hypothetical
vertical line segment such
that the start of the path is mapped to the top of the line segment.
The standard text layout rules are
applied to the hypothetical straight line segment and the result is
mapped back onto the target path.

10.12 Alternate glyphs

There are situations such as ligatures, special-purpose fonts (e.g.,
a font for music symbols) or alternate glyphs for Asian text strings where
it is required that
a different glyph
is
used than the glyph
which normally corresponds to the given character data. Also,
The W3C Character Model [CHARMOD] encourages
creators of XML to normalize
character data to facilitate meaningful exchange of character
data and to promote correct comparisons between character strings. This normalization
potentially loses some information about which specific glyph
is required
to achieve a particular visual result.

The 'altGlyph' element provides control
over the glyphs used to render particular character data.

A URI reference either to a
'glyph' element
in an SVG document fragment or to a
'altGlyphDef' element.
If the reference is to a
'glyph' element, then that
glyph is rendered instead of the character(s) that are inside of the
'altGlyph' element.
If the reference is to a
'altGlyphDef' element, then
if an appropriate alternate glyph is located from processing the
'altGlyphDef' element, then that
alternate glyph is rendered the that
glyph is rendered instead of the character(s) that are inside of the
'altGlyph' element.
If the reference does not result in successful identification of
an alternate glyph to use, then the character(s) that are inside
of the 'altGlyph' element are rendered.
Animatable: no.

The 'altGlyphDef' element,
which can only appear as a child of a
'defs'
element, defines
a list of possible glyph substitutions which can be referenced from an
'altGlyph'
element. Each possible glyph substitution is defined by a
'glyphSub'
child element. The first 'glyphSub'
element which locates a substitute glyph will be applied.

The identifier for a single font which might contain the substitute glyph.
The <string> can contain any single font family name value as is allowed
in [CSS2].
Animatable: no.

glyphRef = "<string>"

The glyph identifier, the format of which is dependent on the
format
of the given font.
Animatable: no.

format = "<string>"

The format of the given font. If the font is in one of the formats listed in the
[CSS2] specification (e.g., TrueDoc Portable Font Resource
or Embedded OpenType), then the <string>
must
contain the corresponding font format
string defined in the
[CSS2] specification (e.g., truedoc-pfr or embedded-opentype).
Animatable: no.

10.13 White space handling

SVG supports the standard XML attribute xml:space
to specify the handling of
white space characters within
a given 'text' element's character data.
xml:space is an inheritable attribute which can have one of two values:

default (the initial/default value for xml:space) -
When xml:space="default", the SVG user agent will do the following.
First, it will remove all carriage return and linefeed characters.
Then it will convert all tab characters into space characters.
Then, it will strip off all leading and trailing space characters.
Then, all contiguous space characters will be consolidated.

preserve -
When 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").

The following examples illustrate that line indentation can be important
when using xml:space="default".
The fragments below show two pairs of equivalent
'text' elements.
Each pair consists of two equivalent 'text' elements,
with the first 'text' element
using xml:space='default' and the second
using xml:space='preserve'.
For these examples, there is no extra white space at the end of any of the lines (i.e.,
the line break occurs immediately after the last visible character).

10.14 Text selection and clipboard operations

Conforming SVG viewers
on systems which have the capacity for text selection (e.g., systems
which are equipped with a pointer device such as a mouse)
and which have system clipboards for copy/paste operations
are required to support:

user selection of text strings in SVG content

the ability to copy selected text strings to the system clipboard

A text selection operation starts when all of the following occur:

the user positions the pointing device over a
glyph that has been rendered
as part of a
'text' element, initiates a select operation
(e.g., pressing the standard system mouse button for select operations) and
then moves the pointing device while continuing the select operation
(e.g., continuing to press the standard system mouse button for select operations)

no other visible graphics element has been painted above the
glyph at the point at
which the pointing device was clicked

As the text selection operation proceeds (e.g., the user continues to
press the given mouse button), all associated events with other graphics
elements are ignored (i.e., the text selection operation is modal)
and the SVG user agent
shall
dynamically indicate which
characters are selected by an appropriate
highlighting technique, such as redrawing the selected
glyphs with inverse colors.
As the pointer is moved during the text selection process, the
end glyph for the text selection operation is the glyph within the
same
'text' element
whose character cell is closest to the pointer.
All characters within the
'text' element
whose position within the
'text' element
is between the start of selection and end of selection
shall
be highlighted, regardless of position on the canvas and
regardless of any graphics elements that might be above the end of
selection point.

Once the text selection
operation ends (e.g., the user releases the given mouse button), the selected text
will stay highlighted until an event occurs which cancels text selection, such as
a pointer device activation event (e.g., pressing a mouse button).

For systems which have system clipboards, the SVG user agent is required
to provide a user interface for initiating a copy of the currently selected
text to the system clipboard. It is sufficient for the SVG user agent to
post the selected text string in the system's appropriate clipboard format for plain text,
but preferable if the SVG user agent also posts a rich text alternative which
captures the various font properties
associated with the given text string.

For bi-directional text, the user agent must support text selection in lexical order,
which will result in discontinuous highlighting of glyphs due to the bi-directional
reordering of characters. User agents can provide an alternative ability to
select bi-directional text in visual rendering order (i.e., after
bi-directional text layout algorithms
have been applied), with
the result that selected character data
might
be discontinous lexically.
In this case, if the user
requests that bi-directional text be copied to the clipboard, then the user agent
is required to make appropriate adjustments to copy only the visually selected characters
to the clipboard.

When feasible,
it is recommended that
generators of SVG
attempt to order their text strings
to facilitate properly ordered text selection within SVG viewing applications such as Web
browsers.