Text — SVG 2 (original) (raw)

s define two floats, one on the left (solid green line) and the right (solid pink line). The floats are rectangular in shape. Each float has ashape-outside property which defines thewrapping context for each float (dotted green and pink lines). The combined wrapping context is subtracted from the content area to defined thewrapping area (light blue line).

11.4.1. The ‘inline-size’ property

'extent' added by resolution fromFebruary 12th, 2015. 'extent' replaces the 'width' and 'height' attributes, added by resolution from June 27th, 2013. Replaced by 'inline-size' presentation attribute per resolution fromLinkoping F2F, June 11, 2015.

The inline-size property allows one to set thewrapping area to a rectangular shape. The computed value of the property sets the width of the rectangle for horizontal text and the height of the rectangle for vertical text. The other dimension (height for horizontal text, width for vertical text) is of infinite length. A value of zero disables the creation of awrapping area.

The initial current text position is taken from the‘x’ and ‘y’ attributes of the‘text’ element (or first child ‘tspan’ element if the attributes are not given on the ‘text’ element). For left-to-right text, the initial current text position is at the left of the rectangle. For right-to-left text it is at the right of the rectangle. For vertical text, the initial current text position is at the top of the rectangle.

The rectangle (wrapping area) is then anchored according to the text-anchor property using the edges of thewrapping area to determine the start, middle, and end positions.

The inline-size property method to wrap text is an extension to pre-formatted SVG text where the author simply gives a limit to the width or height of the block of text; thus the use of the ‘x’ and ‘y’ attributes along with the direction and text-anchor properties to position the first line of text. If full justification is needed, the shape-inside property should be used to create the wrapping area.

Name:	inline-size
Value:	auto |
Initial:	auto
Applies to:	‘text’ elements
Inherited:	no
Percentages:	Refer to the width (for horizontal text) or height (for vertical text) of the current SVG viewport (see Units)
Media:	visual
Computed value:	an absolute length or percentage
Animation type:	by computed value

An example of using inline-size for wrapping horizontal text.

This text wraps at 200 pixels.

Horizontal text wrapping. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite height. The red dot shows the initialcurrent text position.

An example of using inline-size for wrapping right to left horizontal text.

هذا النص يلتف في 200 بكسل.

Horizontal text wrapping for right to left text. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite height. The red dot shows the initialcurrent text position.

Some browser may not render this SVG 1.1 figure correctly. Batik and Firefox seems to get it right. Bug filed against Chrome.

An example of using inline-size for wrapping vertical text.

テキストは１０文字後に折り返されます。

Vertical text wrapping. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite width. The red dot shows the initialcurrent text position.

This SVG 1.1 image doesn't work in Firefox, even nightly. Firefox does not support the presentation attribute 'writing-mode'. Bug filed against Firefox.

An example of using inline-size for wrapping horizontal text, anchored in the middle.

This text wraps at 200 pixels.

Horizontal text wrapping. The light-blue lines indicate the limits of the content area. The text is anchored in the middle. The red dot shows the initialcurrent text position.

11.4.2. The ‘shape-inside’ property

The shape-inside property allows one to set thecontent area to a CSS basic shape or to an SVG shape.

In CSS/HTML shape-inside applies to block-level elements and absolute and percentage values are defined relative to the block-level element. In SVG absolute and percentage values are defined relative to the current user coordinate system and the ‘viewBox’.

Do nor re-specify shape-inside but reference CSS Shapes.

Name:	shape-inside
Value:	auto | [	]+
Initial:	auto
Applies to:	‘text’ elements
Inherited:	no
Percentages:	Relative to the ‘viewBox’
Media:	visual
Computed value:	computed lengths for , the absolute URI for , otherwise as specified
Animation type:	See Interpolation of Basic Shapes

auto

For the purposes of SVG, the 'auto' value indicates that the content area should be defined using the inline-size property or as for pre-formatted text.

The shape is computed based on the values of one of 'circle()', 'ellipse()' or 'polygon()'. The CSS value of 'inset()' is invalid for SVG.

An example of using a CSS basic-shape for wrapping horizontal text.

Lorem ipsum dolor sit amet, consec-tetuer adipiscing elit...

Horizontal text wrapping inside a CSS circle shape. The light-blue circle indicates the limit of thecontent area.

If the references an SVG shape element, that element defines the shape. Otherwise, if the references an image, the shape is extracted and computed based on the alpha channel of the specified image using theshape-image-threshold. If the does not reference an SVG shape element or an image, the effect is as if the value ‘auto’ had been specified.

An example of using a reference to an SVG shape for wrapping horizontal text.

This text wraps in a rectangle.

Horizontal text wrapping inside an SVG rectangle shape. The light-blue lines indicate the limits of thecontent area.

The CSS values of 'outside-shape', 'shape-box', and 'display' are invalid for SVG.

SVG allows the shape-inside property to have a list of shapes. Each shape defines an independent content area. Text is first laid out in the content area of the first shape. If the text overflows the first shape, the overflow text is laid out in the next shape until all text is laid out or no more shapes are available.

The effect is similar to CSS columns, except that the columns can have arbitrary shapes.

It is recommended that an overflow shape be provided to ensure the accessibility of all text in cases; for example, if a user increases the font size.

Except as noted, see the CSS Shapes Module Level 2 for the definition of'shape-inside'. [css-shapes-2]

'shape-inside' was removed when the CSS Exclusions and Shapes Module was split into separate Exclusions and Shapes modules. At the Tokyo joint SVG/CSS F2F meeting, it was agreed that it would reappear in CSS Shapes Module Level 2.

11.4.3. The ‘shape-subtract’ property

The shape-subtract property allows one to exclude part of the content area from the wrapping area. The excluded area is the addition of all the areas defined in a list of CSS basic shapes and/or SVG shapes.

It was resolved at the 2016 Sydney F2F that 'shape-subtract' should be uses instead of 'shape-outside' due to the different behavior required. ('shape-outside' reduces the area of an exclusion.)

Absolute and percentage values are defined relative to the current user coordinate system and the ‘viewBox’.

Name:	shape-subtract
Value:	none | [	]+
Initial:	none
Applies to:	‘text’ elements
Inherited:	no
Percentages:	Relative to the ‘viewBox’
Media:	visual
Computed value:	computed lengths for any , the absolute URI for , otherwise as specified
Animation type:	See Interpolation of Basic Shapes

The shape is computed based on the values of one of 'circle()', 'ellipse()' or 'polygon()'.

For any that references an SVG shape element, that element defines the contributing shape, expanded by the value of its shape-margin distance. For any that references an image, the contributing shape is extracted and computed based on the alpha channel of the specified image using the shape-image-threshold. If an does not reference an SVG shape element or an image, that is ignored.

An example of using shape-subtract.

.

Lorem ipsum ... Lorem ipsum ...

11.4.4. The ‘shape-image-threshold’ property

The shape-image-threshold defines the alpha channel threshold used to extract the shape using an image. A value of 0.5 means that the shape will enclose all the pixels that are more than 50% opaque.

For the purposes of SVG, this property applies to ‘text’ elements.

Except as noted, see the CSS Shapes Module Level 1 for the definition of'shape-image-threshold'. [css-shapes-1]

11.4.5. The ‘shape-margin’ property

The shape-margin property adds a margin to a shape referenced withshape-subtract. It defines a new shape where every point is the specified distance from the original shape. This property takes on positive values only.

Do nor re-specify shape-margin but reference CSS Shapes.

Name:	shape-margin
Value:
Initial:	0
Applies to:	‘text’ elements
Inherited:	no
Percentages:	N/A
Media:	visual
Computed value:	an absolute length
Animation type:	by computed value

Except as noted, see the CSS Shapes Module Level 1 for the definition of See 'shape-margin'. [css-shapes-1]

11.4.6. The ‘shape-padding’ property

The shape-padding property can be used to offset the inline flow content wrapping on the inside of elements. Offsets created by the ‘wrap-padding’ property are offset from the content area of the element. This property takes on positive values only.

An example of using shape-padding

.

This is an example of wrapped text in SVG 2! There should be 25 pixel padding around the text. The text is justified on both sides. It looks good!

This image is a PNG. Figure out how to make a good SVG. Note: Chrome supports 'textLength' on 'tspan' but Firefox does not.

Except as noted, see the CSS Shapes Module Level 2 for the definition of'shape-padding'.

11.5. Text layout – Algorithm

Text layout begins by passing to a CSS-based text renderer the content of the ‘text’ element which includes text data along with styling information and a description of one or more shapes to be filled. The ‘text’ element is treated as a block element and its descendant ‘tspan’, ‘textPath’ and ‘a’ elements are treated as inline elements. The CSS renderer returns a set of typographic characters with their positions resulting from laying out the text as if the text were absolutely positioned.

A typographic character may contain more than one glyph. It is assumed here the relative positioning of the glyphs inside a typographic character is encapsulated by the typographic character and it is not user controllable.

Once a content area has been defined, the following algorithm is used to determine the typographic characters and their positions for a given ‘text’ element:

• For text where the content area is defined by theshape-inside property, layout the text in one or more areas per CSS rules for laying out text in a CSS wrapping area.
  SVG allows the shape-inside property to reference more than one shape. Each shape should be filled in turn until there is no more text or no more shapes.
• For text where the content area is defined by theinline-size property, layout the text in a CSS content box where the inline size is set to the value of the inline-size property and the block size is unconstrained.
  This means that text is laid out with the box width set to the inline-size value if writing-mode is horizontal-tb, or with the box height set to the inline-size value otherwise.
• For all other text (SVG 1.1 compatible text and SVG 1.1 like multi-line text), layout the text in a CSS content box that is unconstrained in width and height.

A number of CSS properties have no or limited effect on SVG text layout:

• The used value of each of the following properties on a text content element (and its pseudo-elements, if any) and on an ‘a’ element within a text content block element must be the property's initial values: ‘border-style’, ‘float’, ‘margin’, ‘padding’, ‘position’ and ‘text-align’.
• If the computed value of the display property on a correctly parented text content block element is anything other thannone, then its used value must beblock.
  This ensures that the ‘text’ element is treated as if it were a block element.
• If the computed value of the display property on a correctly parented text content child element or ‘a’ element, is anything other thannone, then its used value must beinline.
  This ensures that ‘tspan’, ‘textPath’ and‘a’ elements are treated as if they were inline elements. Note: the transform property has no effect on inline elements.
• The used value of the display property on an element that is a descendant of a text content block element and is not a correctly parented text content child element or ‘a’ element must benone.
  This ensures that graphics and metadata elements inside a ‘text’ element do not render.

Various SVG attributes and properties may reposition thetypographic characters depending on how the content area is defined:

• For text where the content area is defined by theshape-inside property, the typographic characters are rendered with positions as returned from the CSS-based text renderer.
• For text where the content area is defined by theinline-size property, each line box is shifted according to the text-anchor property. No further post-processing is performed.
• For all other text (SVG 1.1 compatible text and SVG 1.1 like multi-line text), the positions of the typographic characters are adjusted according to the algorithm that follows.

The following SVG text layout algorithm returns output information about each character in the DOM in the ‘text’ element's subtree. That information includes:

• a global index number, which indicates the index of the character relative to the start of the ‘text’ element;
• an (x, y) coordinate pair, which gives its position in the coordinate space of the ‘text’ element;
• an angle value, which gives its rotation;
• a "hidden" flag, which represents whether it is hidden due to falling off the end of a ‘textPath’;
• an "addressable" flag, which represents whether it is an addressable character, that is, addressable by text positioning attributes and SVG DOM text methods;
• a "middle" flag, which represents whether it is the second or later character of a typographic character
• an "anchored chunk" flag, which represents whether it starts a contiguous sequence of glyphs that can be affected by text anchoring

The arrays given in the SVG attributes ‘x’,‘y’, ‘dx’, ‘dy’, and ‘rotate’ are indexed by addressable characters. However, repositioning is applied totypographic characters. If a typographic character corresponds to more than one character (e.g. a ligature), only the array values corresponding to the first character are used in positioning the typographic character. Array values corresponding to other characters in the typographic character are skipped (for ‘x’ and ‘y’), are accumulated and applied to the next typographic character (for ‘dx’ and ‘dy’), or if it is the last value in the array, applied to the following typographic characters (for ‘rotate’). This ensures, for example, that attribute values are applied to the same characters regardless of whether or not a font has a particular ligature.

The SVG specific text layout algorithm is as follows:

1. Setup
   1. Let root be the result of generatingtypographic character positions for the‘text’ element and its subtree, laid out as if it were an absolutely positioned element.
      This will be a single line of text unless thewhite-space property causes line breaks.
   2. Let count be the number of DOM characters within the ‘text’ element's subtree.
   3. Let result be an array of length count whose entries contain the per-character information described above. Each entry is initialized as follows:
      • its global index number equal to its position in the array,
      • its "x" coordinate set to "unspecified",
      • its "y" coordinate set to "unspecified",
      • its "rotate" coordinate set to "unspecified",
      • its "hidden" flag is false,
      • its "addressable" flag is true,
      • its "middle" flag is false,
      • its "anchored chunk" flag is false.
        If result is empty, then return result.
   4. Let CSS_positions be an array of lengthcount whose entries will be filled with thex and y positions of the correspondingtypographic character in root. The array entries are initialized to (0, 0).
   5. Let "horizontal" be a flag, true if the writing mode of ‘text’ is horizontal, false otherwise.
2. Set flags and assign initial positions
   For each array element with index i inresult:
   1. Set addressable to false if the character at index i was:
      • part of the text content of a non-rendered element
      • discarded during layout due to being acollapsed white space character, a soft hyphen character, or a bidi control character; or
      • discarded during layout due to being acollapsed segment break; or
      • trimmed from the start or end of a line.
        Since there is collapsible white space not addressable by glyph positioning attributes in the following ‘text’ element (with a standard font), the "B" glyph will be placed at x=300. A B

   This is because the white space before the "A", and all but one white space character between the "A" and "B", is collapsed away or trimmed.
   2. Set middle to true if the character at index i is the second or later character that corresponds to a typographic character.
   3. If the character at index i corresponds to a typographic character at the beginning of a line, then set the "anchored chunk" flag of result[i] to true.
   This ensures chunks shifted by text-anchor do not span multiple lines.
   4. If addressable is true and middle is false then set CSS_positions[i] to the position of the corresponding typographic character as determined by the CSS renderer. Otherwise, if i > 0, then setCSS_positions[i] =CSS_positions[i − 1]

3. Resolve character positioning
   Position adjustments (e.g. values in a ‘x’ attribute) specified by a node apply to all characters in that node including characters in the node's descendants. Adjustments specified in descendant nodes, however, override adjustments from ancestor nodes. This section resolves which adjustments are to be applied to which characters. It also directly sets the rotate coordinate of result.
   1. Set up:
      1. Let resolve_x, resolve_y,resolve_dx, and resolve_dy be arrays of length count whose entries are all initialized to "unspecified".
      2. Set "in_text_path" flag false.
         This flag will allow ‘y’ (‘x’) attribute values to be ignored for horizontal (vertical) text inside ‘textPath’ elements.
      3. Call the following procedure with the ‘text’ element node.
   2. Procedure: resolve character positioning:
      A recursive procedure that takes as input a node and whose steps are as follows:
      1. If node is a ‘text’ or ‘tspan’ node:
         1. Let index equal the "global index number" of the first character in the node.
         2. Let x, y, dx, dy and rotate be the lists of values from the corresponding attributes on node, or empty lists if the corresponding attribute was not specified or was invalid.
         3. If "in_text_path" flag is false:
         * Let new_chunk_count = max(length of x, length of y).
         Else:
         * If the "horizontal" flag is true:
         * Let new_chunk_count = length of x.
         * Else:
         * Let new_chunk_count = length of y.
         4. Let length be the number of DOM characters in the subtree rooted at node.
         5. Let i = 0 and j = 0.
         i is an index of addressable characters in the node;j is an index of all characters in the node.
         6. While j < length, do:
         This loop applies the ‘x’, ‘y’,‘dx’, ‘dy’ and ‘rotate’ attributes to the content inside node.
         1. If the "addressable" flag of result[index +j] is true, then:
         1. If i < new_check_count, then set the "anchored chunk" flag ofresult[index + j] to true. Else set the flag to false.
         Setting the flag to false ensures that ‘x’ and ‘y’ attributes set in a ‘text’ element don't create anchored chunk in a ‘textPath’ element when they should not.
         2. If i < length of x, then set resolve_x[index + j] to x[i].
         3. If "in_text_path" flag is true and the "horizontal" flag is false, unsetresolve_x[index].
         The ‘x’ attribute is ignored for vertical text on a path.
         4. If i < length of y, then set resolve_y[index + j] to y[i].
         5. If "in_text_path" flag is true and the "horizontal" flag is true, unsetresolve_y[index].
         The ‘y’ attribute is ignored for horizontal text on a path.
         6. If i < length of dx, then set resolve_dx[index + j] to dy[i].
         7. If i < length of dy, then set resolve_dy[index + j] to dy[i].
         8. If i < length of rotate, then set the angle value of result[index + j] to rotate[i]. Otherwise, if rotate is not empty, then set result[index + j] to result[index + j − 1].
         9. Set i = i + 1.
         2. Set j = j + 1.
      2. If node is a ‘textPath’ node:
         1. Let index equal the global index number of the first character in the node (including descendant nodes).
         2. Set the "anchored chunk" flag of result[index] to true.
         A ‘textPath’ element always creates an anchored chunk.
         3. Set in_text_path flag true.
      3. For each child node child of node:
         1. Resolve glyph positioning of child.
      4. If node is a ‘textPath’ node:
         1. Set "in_text_path" flag false.
4. Adjust positions: dx, dy
   The ‘dx’ and ‘dy’ adjustments are applied before adjustments due to the ‘textLength’ attribute while the ‘x’, ‘y’ and ‘rotate’ adjustments are applied after.
   1. Let shift be the cumulative x andy shifts due to ‘dx’ and ‘dy’ attributes, initialized to (0,0).
   2. For each array element with index i in result:
      1. If resolve_dx[i] is unspecified, set it to 0. If resolve_dy[i] is unspecified, set it to 0.
      2. Let shift.x = shift.x + resolve_dx[i] and shift.y = shift.y + resolve_dy[i].
      3. Let result[i].x = CSS_positions[i].x + shift.x and result[i].y = CSS_positions[i].y + shift.y.
5. Apply ‘textLength’ attribute
   1. Set up:
      1. Define resolved descendant node as a descendant of node with a valid ‘textLength’ attribute that is not itself a descendant node of a descendant node that has a valid ‘textLength’ attribute.
      2. Call the following procedure with the ‘text’ element node.
   2. Procedure: resolve text length:
      A recursive procedure that takes as input a node and whose steps are as follows:
      1. For each child node child of node:
         1. Resolve text length of child.
         Child nodes are adjusted before parent nodes.
      2. If node is a ‘text’ or ‘tspan’ node and if the node has a valid ‘textLength’ attribute value:
         1. Let a = +∞ and b = −∞.
         2. Let i and j be the global index of the first character and last characters in node, respectively.
         3. For each index k in the range [i, j] where the "addressable" flag of result[k] is true:
         This loop finds the left-(top-) most and right-(bottom-) most extents of the typographic characters within the node and checks for forced line breaks.
         1. If the character at k is a linefeed or carriage return, return. No adjustments due to‘textLength’ are made to a node with a forced line break.
         2. Let pos = the x coordinate of the position in result[k], if the "horizontal" flag is true, and the y coordinate otherwise.
         3. Let advance = the advance of the typographic character corresponding to character k. [NOTE: This advance will be negative for RTL horizontal text.]
         4. Set a = min(a, pos, pos + advance).
         5. Set b = max(b, pos, pos + advance).
         4. If a ≠ +∞ then:
         1. Find the distance delta = ‘textLength’ computed value − (b − a).
         User agents are required to shift the lasttypographic character in the node bydelta, in the positive x direction if the "horizontal" flag is true and ifdirection islrt, in the negative x direction if the "horizontal" flag is true and direction isrtl, or in the positive y direction otherwise. User agents are free to adjust intermediatetypographic characters for optimal typography. The next steps indicate one way to adjust typographic characters when the value of ‘lengthAdjust’ isspacing.
         2. Find n, the total number oftypographic characters in this node including any descendant nodes that are not resolved descendant nodes or within a resolved descendant node.
         3. Let n = n + number of resolved descendant nodes − 1.
         Each resolved descendant node is treated as if it were a singletypographic character in this context.
         4. Find the per-character adjustment δ = delta/n.
         5. Let shift = 0.
         6. For each index k in the range [i,j]:
         1. Add shift to the x coordinate of the position in result[k], if the "horizontal" flag is true, and to the y coordinate otherwise.
         2. If the "middle" flag for result[k] is not true and k is not a character in a resolved descendant node other than the first character then shift = shift + δ.
6. Adjust positions: x, y
   This loop applies ‘x’ and ‘y’ values, and ensures that text-anchor chunks do not start in the middle of a typographic character.
   1. Let shift be the current adjustment due to the ‘x’ and ‘y’ attributes, initialized to (0,0).
   2. Set index = 1.
   3. While index < count:
      1. If resolved_x[index] is set, then letshift.x =resolved_x[index] −result.x[index].
      2. If resolved_y[index] is set, then letshift.y =resolved_y[index] −result.y[index].
      3. Let result.x[index] =result.x[index] + shift.x and result.y[index] =result.y[index] + shift.y.
      4. If the "middle" and "anchored chunk" flags of result[index] are both true, then:
         1. Set the "anchored chunk" flag of result[index] to false.
         2. If index + 1 < count, then set the "anchored chunk" flag of result[index + 1] to true.
      5. Set index to index + 1.
7. Apply anchoring
   1. For each slice result[i..j] (inclusive of both i and j), where:
      • the "anchored chunk" flag of result[i] is true,
      • the "anchored chunk" flags of result[k] where i < k ≤ j are false, and
      • j = count − 1 or the "anchored chunk" flag of result[j + 1] is true;
        do:
        This loops over each anchored chunk.
      1. Let a = +∞ and b = −∞.
      2. For each index k in the range [i, j] where the "addressable" flag of result[k] is true:
         This loop finds the left-(top-) most and right-(bottom-) most extents of the typographic character within the anchored chunk.
         1. Let pos = the x coordinate of the position in result[k], if the "horizontal" flag is true, and the y coordinate otherwise.
         2. Let advance = the advance of the typographic character corresponding to character k. [NOTE: This advance will be negative for RTL horizontal text.]
         3. Set a = min(a, pos, pos + advance).
         4. Set b = max(b, pos, pos + advance).
      3. If a ≠ +∞, then:
         Here we perform the text anchoring.
         1. Let shift be the x coordinate ofresult[i], if the "horizontal" flag is true, and the y coordinate otherwise.
         2. Adjust shift based on the value of text-anchor and direction of the element the character at index i is in:
         (start, ltr) or (end, rtl)
         Set shift = shift − a.
         (start, rtl) or (end, ltr)
         Set shift = shift − b.
         (middle, ltr) or (middle, rtl)
         Set shift = shift − (a + b) / 2.
         3. For each index k in the range [i, j]:
         1. Add shift to the x coordinate of the position in result[k], if the "horizontal" flag is true, and to the y coordinate otherwise.
8. Position on path
   1. Set index = 0.
   2. Set the "in path" flag to false.
   3. Set the "after path" flag to false.
   4. Let path_end be an offset for characters that follow a ‘textPath’ element. Set path_end to (0,0).
   5. While index < count:
      1. If the character at index i is within a‘textPath’ element and corresponds to a typographic character, then:
         1. Set "in path" flag to true.
         2. If the "middle" flag ofresult[index] is false, then:
         Here we apply ‘textPath’ positioning.
         1. Let path be the equivalent path of the basic shape element referenced by the ‘textPath’ element, or an empty path if the reference is invalid.
         2. If the ‘side’ attribute of the ‘textPath’ element is'right', then reverse path.
         3. Let length be the length of path.
         4. Let offset be the value of the‘textPath’ element's‘startOffset’ attribute, adjusted due to any ‘pathLength’ attribute on the referenced element.
         5. Let advance = the advance of the typographic character corresponding to character k. [NOTE: This advance will be negative for RTL horizontal text.]
         6. Let (x, y) and angle be the position and angle in result[index].
         7. Let mid be a coordinate value depending on the value of the "horizontal" flag:
         true
         mid is x + advance / 2 + offset
         false
         mid is y + advance / 2 + offset
         The user agent is free to make any additional adjustments tomid necessary to ensure high quality typesetting due to a ‘spacing’ value of'auto' or a‘method’ value of'stretch'.
         8. If path is not a closed subpath andmid < 0 or mid > length, set the "hidden" flag of result[index] to true.
         9. If path is a closed subpath depending on the values of text-anchor and direction of the element the character at index is in:
         This implements the special wrapping criteria for singleclosed subpaths.
         (start, ltr) or (end, rtl)
         If mid−offset < 0 or mid−offset > length, set the "hidden" flag of result[index] to true.
         (middle, ltr) or (middle, rtl)
         If mid−offset < −length/2 or mid−offset > length/2, set the "hidden" flag of result[index] to true.
         (start, rtl) or (end, ltr)
         If mid−offset < −length or mid−offset > 0, set the "hidden" flag of result[index] to true.
         Set mid = mid mod length.
         10. If the hidden flag is false:
         1. Let point be the position andt be the unit vector tangent to the point mid distance along path.
         2. If the "horizontal" flag is
         true
         1. Let n be the normal unit vector pointing in the direction t + 90°.
         2. Let o be the horizontal distance from the vertical center line of the glyph to the alignment point.
         3. Then set the position inresult[index] topoint -o×t +y×n.
         4. Let r be the angle from the positive x-axis to the tangent.
         5. Set the angle value in result[index] to angle + r.
         false
         1. Let n be the normal unit vector pointing in the direction t - 90°.
         2. Let o be the vertical distance from the horizontal center line of the glyph to the alignment point.
         3. Then set the position inresult[index] topoint -o×t +x×n.
         4. Let r be the angle from the positive y-axis to the tangent.
         5. Set the angle value in result[index] to angle + r.
         3. Otherwise, the "middle" flag of result[index] is true:
         1. Set the position and angle values of result[index] to those in result[index − 1].
      2. If the character at index i is not within a‘textPath’ element and corresponds to a typographic character, then:
         This sets the starting point for rendering any characters that occur after a ‘textPath’ element to the end of the path.
         1. If the "in path" flag is true:
         1. Set the "in path" flag to false.
         2. Set the "after path" flag to true.
         3. Set path_end equal to the end point of the path referenced by ‘textPath’ − the position ofresult[index].
         2. If the "after path" is true.
         1. If anchored chunk ofresult[index] is true, set the "after path" flag to false.
         2. Else, let result.x[index] =result.x[index] + path_end.x and result.y[index] =result.y[index] + path_end.y.
      3. Set index = index + 1.
9. Return result

---

11.6. Pre-formatted text

This option corresponds to basic SVG 1.1 text layout.

This is the default text layout method and is used in the absence of an explicitly defined content area. It is also used as a first step in laying out text on a path (with slightly modified rules). In this layout method, no automatic line breaking or word wrapping is done. Nominally, the text is rendered as a single line inside a rectangular content area of infinite width and height. Multiple lines of text can be obtained by precomputing line breaks and using one of the following methods:

• Use a single ‘text’ element with white-space set to pre or pre-line. Line spacing is set by line-height.
  New in SVG 2.
• 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.
• Use multiple ‘text’ elements, one for each line of text. (Not recommended as this may prevent selection across multiple lines of text -- seeText selection and clipboard operations.)

The following properties do not apply to pre-formatted text:text-align, text-align-last, line-break,word-break, hyphens, word-wrap, and overflow-wrap.

11.6.1. Multi-line text via 'white-space'

Multi-line pre-formatted text may be created by using thewhite-space values pre or pre-line. In these cases, a line-feed or carriage return is preserved as a forced line break which creates a new line box. The line boxes are stacked following the rules of CSS.

11.6.2. Repositioning Glyphs

After text is laid out according to the basic CSS text layout rules, typographic characters can be repositioned using SVG specific rules. Absolute repositioning can be prescribed by giving absolute coordinates in the ‘x’ and ‘y’ attributes or by forced line breaks. Absolute repositioning may be influenced by the text-anchor property. Relative repositioning can be prescribed by giving relative coordinates in the ‘dx’ and ‘dy’ attributes. Thetypographic characters may be arbitrarily rotated by giving a list of values in the ‘rotate’ attribute. Absolute repositioning (including any adjustment due to the text-anchor property) is done before relative repositioning and rotation.

11.7. Auto-wrapped text

Text is automatically wrapped when a content area is specified in the ‘text’ element. The content area defines the outermost container for wrapping text. A wrapping context (set of exclusion areas) may also be given. The actual wrapping area is defined by subtracting thewrapping context from the content area. Thewrapping context may also be reduced by the value of theshape-padding property. The effective area of an exclusion may be enlarged by the value of theshape-margin property.

In the case where the content area is defined by the inline-size property, the ‘x’ and ‘y’ attributes corresponding to the first renderedtypographic character define the initial current text position. When the content area is inside a shape, the initial current text position is determined from the position of the first rendered typographic character after laying out the first line box inside the shape.

Except when used to determine the initial current text position, all values ‘x’ and ‘y’ are ignored on ‘text’, and ‘tspan’ elements in auto-wrapped text.

The attributes ‘x’ and ‘y’ can provide a natural fallback mechanism for SVG1.1 renderers for wrapped text. Content producers may wish to pre-layout text by breaking up lines into ‘tspan’ elements with ‘x’ and‘y’ attributes. Then, for example, if a fallback font is used to render the text, an SVG2 renderer will ignore the ‘x’ and ‘y’ attributes and reflow the text using the font metrics of the fallback font. An SVG1.1 renderer will use the ‘x’ and ‘y’ attributes in rendering the text which will usually result in readable text even if the rendering doesn't match the shape. Many of the text wrapping examples in this section rely on this mechanism to render text in browsers that have not implemented text wrapping.

11.7.1. Notes on Text Wrapping

The following examples illustrate a few issues with laying out text in a shape.

11.7.1.1. First Line Positioning

Given an arbitrary shaped wrapping area, the firstline box may not fit flush against the top (or side for vertical text). In this case, the first line box is shifted until it fits.

In CSS, the edge of a shape is treated as a series of 1 pixel × 1 pixel floats.

A future CSS specification may define a line grid that could be used to control the position of the first line of text to allow alignment of text between different wrapping areas.

The top line box (small light-blue rectangle), consisting of the smallest possible block of text, is moved down until theline box fits inside the wrapping area (light-blue path). Note, the line box includes the effect of the line-height property, here set to 1.25. The red rectangles tightly wrap the glyphs in each line box.

This appears to be different from the SVG 1.2 draft in which the top of the wrapping area served as the origin of a line grid. The first line was moved down by the line height until it fit inside the shape.

11.7.1.2. Broken Lines

Given an arbitrary shaped wrapping area, a single line of text might be broken into more than one part. In this case, a line box for each part is created. The height of all line boxes in a single line of text must be the same (ensuring all parts have the same baseline). This height is calculated by looking at all glyphs in the line of text.

This default behavior was agreed to at the CSS/SVG joint working group meeting in Sydney 2016.

A future CSS specification may allow one to control which parts of a shape broken into different parts is filled (e.g, fill only the right most parts, fill only the left most parts, etc.).

The top line is split into two line boxes (light-blue rectangles), text in each line box is centered inside the box (due to 'text-align:center').

11.8. Text on a path

SVG can place text along a path defined either by a ‘path’ element or the path equivalent of a basic shape. This is specified by including text within a ‘textPath’ element that has either an ‘href’ attribute with an URL reference pointing to a ‘path’ element or basic shape, or by specifying a value for the ‘path’ attribute that specifies the path data directly.

The ability to place text along a basic shape is new in SVG 2.

Placing text along a basic shape was resolved at theSydney (2015) meeting.

Directly using a 'd' attribute to specify the path was added to SVG 2. The 'd' attribute was renamed to 'path' by decision at theLondon (2016) editor's meeting at the same time 'd' was promoted to being a presentation attribute.

Text on a path is conceptionally like a single line ofpre-formatted text that is then transformed to follow the path. Except as indicated, all the properties that apply to pre-formatted text apply to text on a path.

11.8.1. The ‘textPath’ element

‘textPath’

Categories:

Graphics element, renderable element, text content element, text content child element

Content model:

Any number of the following elements or character data, in any order:

• descriptive elements — ‘desc’, ‘title’, ‘metadata’
• paint server elements — ‘linearGradient’, ‘radialGradient’, ‘pattern’ a, animate, clipPath, marker, mask, script, set, style, tspan

Attributes:

• aria attributes — ‘aria-activedescendant’, ‘aria-atomic’, ‘aria-autocomplete’, ‘aria-busy’, ‘aria-checked’, ‘aria-colcount’, ‘aria-colindex’, ‘aria-colspan’, ‘aria-controls’, ‘aria-current’, ‘aria-describedby’, ‘aria-details’, ‘aria-disabled’, ‘aria-dropeffect’, ‘aria-errormessage’, ‘aria-expanded’, ‘aria-flowto’, ‘aria-grabbed’, ‘aria-haspopup’, ‘aria-hidden’, ‘aria-invalid’, ‘aria-keyshortcuts’, ‘aria-label’, ‘aria-labelledby’, ‘aria-level’, ‘aria-live’, ‘aria-modal’, ‘aria-multiline’, ‘aria-multiselectable’, ‘aria-orientation’, ‘aria-owns’, ‘aria-placeholder’, ‘aria-posinset’, ‘aria-pressed’, ‘aria-readonly’, ‘aria-relevant’, ‘aria-required’, ‘aria-roledescription’, ‘aria-rowcount’, ‘aria-rowindex’, ‘aria-rowspan’, ‘aria-selected’, ‘aria-setsize’, ‘aria-sort’, ‘aria-valuemax’, ‘aria-valuemin’, ‘aria-valuenow’, ‘aria-valuetext’, ‘role’
• conditional processing attributes — ‘requiredExtensions’, ‘systemLanguage’
• core attributes — ‘id’, ‘tabindex’, ‘autofocus’, ‘lang’, ‘xml:space’, ‘class’, ‘style’
• global event attributes — ‘oncancel’, ‘oncanplay’, ‘oncanplaythrough’, ‘onchange’, ‘onclick’, ‘onclose’, ‘oncopy’, ‘oncuechange’, ‘oncut’, ‘ondblclick’, ‘ondrag’, ‘ondragend’, ‘ondragenter’, ‘ondragexit’, ‘ondragleave’, ‘ondragover’, ‘ondragstart’, ‘ondrop’, ‘ondurationchange’, ‘onemptied’, ‘onended’, ‘onerror’, ‘onfocus’, ‘oninput’, ‘oninvalid’, ‘onkeydown’, ‘onkeypress’, ‘onkeyup’, ‘onload’, ‘onloadeddata’, ‘onloadedmetadata’, ‘onloadstart’, ‘onmousedown’, ‘onmouseenter’, ‘onmouseleave’, ‘onmousemove’, ‘onmouseout’, ‘onmouseover’, ‘onmouseup’, ‘onpaste’, ‘onpause’, ‘onplay’, ‘onplaying’, ‘onprogress’, ‘onratechange’, ‘onreset’, ‘onresize’, ‘onscroll’, ‘onseeked’, ‘onseeking’, ‘onselect’, ‘onshow’, ‘onstalled’, ‘onsubmit’, ‘onsuspend’, ‘ontimeupdate’, ‘ontoggle’, ‘onvolumechange’, ‘onwaiting’, ‘onwheel’
• presentation attributes —
• deprecated xlink attributes — ‘xlink:href’, ‘xlink:title’
• ‘lengthAdjust’
• ‘textLength’
• ‘path’
• ‘href’
• ‘startOffset’
• ‘method’
• ‘spacing’
• ‘side’

DOM Interfaces:

• SVGTextPathElement

Both the ‘path’ attribute and the ‘href’ attribute specify a path along which the typographic characters will be rendered.

If both attributes are specified on a ‘textPath’ element, the path that is used must follow the following order of precedence:

1. ‘path’ attribute
2. ‘href’ attribute
3. ‘xlink:href’ attribute

If the ‘path’ attribute contains an error, the‘href’ attribute must be used.

11.8.2. Attributes

startOffset

An offset from the start of the path for the initial current text position, calculated using the user agent'sdistance along the path algorithm, after converting the path to the ‘textPath’ element's coordinate system.

If a other than a percentage is given, then the‘startOffset’ represents a distance along the path measured in the current user coordinate system for the ‘textPath’ element.

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 andstartOffset="100%" indicates the end point of the path.

Negative values and values larger than the path length (e.g. 150%) are allowed.

Limiting values to the range 0%-100% prevents easily creating effects like text moving along the path.

Any typographic characters with mid-points that are not on the path are not rendered.

Rendering for different values of the ‘startOffset’ attribute. From top to bottom: default value, 50%, -50%.

The bottom path should show only "path." on the left side of the path. Chrome and Safari both do not handle offsets outside the range 0% to 100%. Chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=476554

For paths consisting of a single closed subpath (including an equivalent path for a basic shape), typographic characters are rendered along one complete circuit of the path. The text is aligned as determined by the text-anchor property to a position along the path set by the ‘startOffset’ attribute. For the start (end) value, the text is rendered from the start (end) of the line until the initial position along the path is reached again. For themiddle, the text is rendered from the middle point in both directions until a point on the path equal distance in both directions from the initial position on the path is reached.

Rendering for text on a path referencing a ‘circle’ with different values of the ‘startOffset’ attribute. Left: 0. Right: 75% or -25%. The red circle marks the beginning of the path (after the canonical decomposition of the circle into a path).

Rendering for text on a path referencing a ‘circle’ with different values of the text-anchor attribute. Left: 'start'. Middle: 'middle'. Right: 'end'. The red circles marks the beginning of the path (after the canonical decomposition of the circle into a path). The blue square marks the reference point for the start of rendering (shifted from the path start by a ‘startOffset’ value of 75%). The gray arrow(s) shows the direction of typographic character placement and the point at which typographic character placement stops. The arrow(s) would be reversed if the direction property has a value ofrtl.

Rendering all glyphs was agreed to for basic shapes at theSydney (2015) meeting (but missing in minutes). Limiting the wrapping to a path with a single closed sub-path and to one loop, effected by the 'startOffset' attribute agreed to at theLondon (2016) Editor's Meeting.

Value

|

initial value

0

Animatable

yes

method

Indicates the method by which text should be rendered along the path.

A value of align indicates that the typographic character should be rendered using simple 2×3 matrix transformations such that there is no stretching/warping of the typographic characters. Typically, supplemental rotation, scaling and translation transformations are done for each typographic characters to be rendered. As a result, withalign, in fonts where the typographic characters are designed to be connected (e.g., cursive fonts), the connections may not align properly when text is rendered along a path.

A value of stretch indicates that the typographic character outlines will be converted into paths, and then all end points and control points will be adjusted to be along the perpendicular vectors from the path, thereby stretching and possibly warping the glyphs. With this approach, connected typographic characters, such as in cursive scripts, will maintain their connections. (Non-vertical straight path segments should be converted to Bézier curves in such a way that horizontal straight paths have an (approximately) constant offset from the path along which the typographic characters are rendered.)

Rendering of text on a path for different ‘method’ values: Left: 'align'. Right: 'stretch'.

Value

align | stretch

initial value

align

Animatable

yes

spacing

Indicates how the user agent should determine the spacing between typographic characters that are to be rendered along a path.

A value of exact indicates that the typographic characters should be rendered exactly according to the spacing rules as specified inText on a path layout rules.

A value of auto indicates that the user agent should use text-on-a-path layout algorithms to adjust the spacing between typographic characters in order to achieve visually appealing results.

Value

auto | exact

initial value

exact

Animatable

yes

side

Determines the side of the path the text is placed on (relative to the path direction). Specifying a value of right effectively reverses the path.

Rendering for text on a path referencing a ‘circle’ with different values of the ‘side’ attribute. Left: left. Right: right.

Added in SVG 2 to allow text either inside or outsideclosed subpaths and basic shapes (e.g. rectangles, circles, and ellipses).

Adding 'side' was resolved at theSydney (2015) meeting.

Value

left | right

initial value

left

Animatable

yes

path

A path data string describing the path onto which the typographic characters will be rendered. An empty string indicates that there is no path data for the element. This means that the text within the ‘textPath’ does not render or contribute to the bounding box of the ‘text’ element. If the attribute is not specified, the path specified with ‘href’ is used instead.

Value

path data

initial value

(none)

Animatable

yes

href

An URL reference to the ‘path’ element or basic shape element onto which the glyphs will be rendered, if no ‘path’ attribute is provided. If the attribute is used, and the is an invalid reference (e.g., no such element exists, or the referenced element is not a ‘path’ element) or basic shape, then the ‘textPath’ element is in error and its entire contents shall not be rendered by the user agent.

Refer to the common handling defined for URL reference attributes anddeprecated XLink attributes.

Value

URL [URL]

initial value

See above.

Animatable

yes

The path data coordinates within the referenced ‘path’ element or basic shape element are assumed to be in the same coordinate system as the current ‘text’ element, not in the coordinate system where the ‘path’ element is defined. The transform attribute on the referenced ‘path’ element or basic shape element represents a supplemental transformation relative to the current user coordinate system for the current ‘text’ element, including any adjustments to the current user coordinate system due to a possible transform property on the current ‘text’ element. For example, the following fragment of SVG content:

should have the same effect as the following:

and be equivalent to:

Note that the transform="translate(25,25)" has no effect on the ‘textPath’ element, whereas thetransform="rotate(45)" applies to both the ‘text’ and the use of the ‘path’ element as the referenced shape for text on a path. Further note that the transform="scale(2)" scales the path (equivalent to multiplying every coordinate by 2 for simple linear paths), but does not scale the text placed along the path.

Example toap01 provides a simple example of text on a path:

We go up, then we go down, then up again

Example toap01

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

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.

The ‘x’, ‘y’, ‘dx’,‘dy’, and ‘rotate’ attributes can only be specified on ‘text’ and ‘tspan’ elements (but may effect the rendering of glyphs in text on a path — see text on a path layout rules).

We go up , then we go down, then up again

Example toap02

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

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).

We go up, then we go down, then up again

Example toap03

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

11.8.3. Text on a path layout rules

Conceptually, for text on a path 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 standardtext layout rules are applied to the hypothetical straight line segment and the result is mapped back onto the target path. Vertical and bidirectional text layout rules also apply to text on a path.

The orientation of each glyph along a path is determined individually. For horizontal text layout flows, the default orientation (the up direction) for a given glyph is along the vector that starts at the intersection point on the path to which the glyph is attached and which points in the direction 90 degrees counter-clockwise from the angle of the curve at the intersection point. For vertical text layout flows, the default orientation for a given glyph is along the vector that starts at the intersection point on the path to which the glyph is attached and which points in the direction 180 degrees from the angle of the curve at the intersection point.

Default glyph orientation along a path. Left, horizontal text. Right: vertical text.

Example toap04 will be used to illustrate the particular layout rules for text on a path that supplement the basic text layout rules for straight line horizontal or vertical text.

Choose shame or get war

Example toap04

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

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 left-to-right horizontal text layout along a path (i.e., when the glyph orientation is perpendicular to theinline-base direction the layout rules are as follows:

• Determine thestartpoint-on-the-path for the first glyph using attribute ‘startOffset’ and propertytext-anchor. For text-anchor:start, startpoint-on-the-path is the point on the path which represents the point on the path which is ‘startOffset’ distance along the path from the start of the path, calculated using the user agent's distance along the path algorithm. For text-anchor:middle, startpoint-on-the-path is the point on the path which represents the point on the path which is [ ‘startOffset’ minus half of the total advance values for all of the glyphs in the ‘textPath’ element ] distance along the path from the start of the path, calculated using the user agent's distance along the path algorithm. For text-anchor:end, startpoint-on-the-path is the point on the path which represents the point on the path which is [ ‘startOffset’ minus the total advance values for all of the glyphs in the ‘textPath’ element ]. Before rendering the first glyph, the horizontal component of the startpoint-on-the-path is adjusted to take into account various horizontal alignment text properties and attributes, such as a ‘dx’ attribute value 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'sdistance along the path algorithm. This point is theendpoint-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 themidpoint-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 alignment-baseline and any specified values for attribute ‘dy’ on a ‘tspan’ element. In the example above, the alignment-baseline property is unspecified, so the initial value of alignment-baseline: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 horizontal kerning tables in the font and current values of various attributes and properties, including spacing properties (e.g. letter-spacing and word-spacing) 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 path are not rendered.
• Continue rendering glyphs until there are no more glyphs (or no more space on path).

Comparable rules are used for top-to-bottom vertical text layout along a path (i.e., when the glyph orientation is parallel with the inline-base direction, the layout rules are as follows:

• Determine the startpoint-on-the-path using the same method as for horizontal text layout along a path, except that before rendering the first glyph, the horizontal component of the startpoint-on-the-path is adjusted to take into account various vertical alignment text properties and attributes, such as a ‘dy’ attribute value on a ‘tspan’ element.
• Determine the glyph's charheight (i.e., the amount which the current text position advances vertically when the glyph is drawn using vertical text layout).
• Determine the point on the curve which is charheight distance along the path from the startpoint-on-the-path for this glyph, calculated using the user agent'sdistance along the path algorithm. This point is the endpoint-on-the-path for the glyph.
• 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.
• Determine the glyph-midline, which is the horizontal line in the glyph's coordinate system that goes through the glyph's y-axis midpoint.
• 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 horizontally (where horizontal is relative to the glyph's coordinate system) relative to the midpoint-on-the-path based on property alignment-baseline and any specified values for attribute ‘dx’ on a ‘tspan’ element.
• 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 vertical 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'sdistance along the path algorithm.
• Glyphs whose midpoint-on-the-path are off either end of an open subpath 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.

When the inline-base direction is horizontal, then any ‘x’ attributes on ‘text’ or ‘tspan’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘y’ attributes on ‘text’ or ‘tspan’ elements are ignored. When the inline-base direction is vertical, then any ‘y’ attributes on ‘text’ or ‘tspan’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘x’ attributes on ‘text’ or ‘tspan’ elements are ignored.

After positioning all characters within the ‘textPath’, the current text position is set to the end point of the path, after adjusting for the ‘startOffset’ in the case of paths that are a single closed loop. In other words, text that follows a ‘textPath’ element (but is still inside a ‘text’ element) that does not have explicit positioning information (‘x’ and ‘y’ attributes) is positioned from the end of the path.

The starting point for text after the ‘textPath’ element without explicit positioning information is at the end of the path (red dot).

The choice of the end of the path over the position of the last character was chosen as it is more author predictable (not depending on font, etc.) Decided at theLondon (2016) editor's meeting. See alsoGitHub Issue 84.

11.9. Text rendering order

A ‘text’ element is rendered in one or more chunks. Each chunk (as produced by the text layout algorithm) is rendered, one after the other, in document order. Each rendered chunk, which consists of one or more glyphs, is filled and stroked as if it were a single path.

This means that all glyphs in the chunk should be filled, then all glyphs stroked at once, or the reverse according to the value of the paint-order property.

For the purposes of painting, a ‘text’ has zero, one, or moreequivalent paths, one for each chunk. Each equivalent path consists of one subpath per glyph within that chunk.

Since the fill-rule property does not apply to SVG text elements, the specific order of the subpaths within the equivalent path does not matter.

The specific position of the start of each subpath, and the direction that the path progresses around glyph shape, is not defined. However, user agents should be consistent for a given font and glyph.

This means that dashed strokes on text may not place the dash pattern at the same positions across different implementations.

11.10. Properties and pseudo-elements

CSS offers a multitude of properties for styling text. In general, only two sets of properties are applicable to SVG: those that determine which glyphs are to be rendered (font-family, font-style, etc.) and those that apply at the paragraph level (direction,writing-mode, line-height, letter-spacing, etc.).

The list of CSS properties that must be supported on SVG text elements can be found in theStyling chapter.

• Properties that apply only to pre-formatted text and auto-wrapped text where the wrapping area is defined by theinline-size property:
  text-anchor.
• Properties that apply only to auto-wrapped text except for text where the wrapping area is defined by theinline-size property:
  text-align,text-align-last,text-justify,
• Properties that apply only to auto-wrapped text:
  text-indent,line-break,word-break,hyphens,word-wrap,overflow-wrap.

Additionally, the @font-face rule must be supported for font selection as well as the ::first-line and ::first-letter pseudo-elements must be supported on ‘text’ elements. In interactive modes, the ::selection pseudo-element must also be supported.

Other CSS properties that affect text layout and rendering may also be supported by an SVG user agent; their effect should be taken into account as part of the CSS text layout step of the overall SVG text layout process.

For example, while SVG 2 does not require support for thetext-combine-upright property, its behavior in an SVG context should be obvious.

A number of CSS properties must not have any effect on SVG text elements:

• Border properties (such as border-top-style). Boxes generated by the CSS layout process must not be sized as if they had any borders. The used value for all of the border-style component longhand properties on SVG text elements is none.
• Display property values other thannone andinline. Like all other SVG elements, any value of display on an SVG text element other than none is handled just as if it were inline. Thus it is not possible for a single ‘text’ element to have any block children.
• The float property, whose used value on SVG text elements is none.
• The position property, whose used value on SVG text elements is static.
• Margin properties (such as margin-top), whose used values on SVG text elements are0.
• The text-align property when text is pre-formatted, whose used value on such SVG text elements is start.
• The content property, whose used value on SVG text elements is none.

Additionally, the ::before and ::after generated content pseudo-elements must not apply to SVG text elements.

A future specification may introduce support for the ::before and ::after generated content pseudo-elements; authors should not rely on them being ignored.

11.10.1. SVG properties

This section covers properties that are not covered elsewhere in this specification and that are specific to SVG.

11.10.1.1. Text alignment, the ‘text-anchor’ property

The text-anchor property is used to align (start-, middle- or end-alignment) a string of pre-formatted text or auto-wrapped text where the wrapping area is determined from the inline-size property relative to a given point. It is not applicable to other types of_auto-wrapped text_, see instead text-align. For multi-line text, the alignment takes place for each line.

The text-anchor property is applied to each individualtext chunk within a given ‘text’ element. Each text chunk has an initial current text position, which represents the point in the user coordinate system resulting from (depending on context) application of the ‘x’ and ‘y’ attributes on the ‘text’ element, any ‘x’ or ‘y’ attribute values on a ‘tspan’ element assigned explicitly to the first rendered character in a text chunk, or determination of the initial current text position for a ‘textPath’ element. Each text chunk also has a final current text position which is thecurrent text position after placing the last glyph in the text chunk. The positions are determined before applying the text-anchor property.

Name:	text-anchor
Value:	start | middle	end
Initial:	start
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Computed value:	as specified
Animation type:	discrete

Values have the following meanings:

start

The rendered characters are aligned such that the start of the resulting rendered text is at the initial current text position. For an element with a direction property value of "ltr" (typical for most European languages), the left side of the text is rendered at the initial text position. For an element with adirection property value of"rtl" (typical for Arabic and Hebrew), the right side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the top side of the text is rendered at the initial text position.

middle

The rendered characters are shifted such that the geometric middle of the resulting rendered text (determined from the initial and final current text position before applying the text-anchor property) is at the initial current text position.

end

The rendered characters are shifted such that the end of the resulting rendered text (final current text position before applying the text-anchor property) is at the initial current text position. For an element with a direction property value of "ltr" (typical for most European languages), the right side of the text is rendered at the initial text position. For an element with a direction property value of "rtl" (typical for Arabic and Hebrew), the left side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the bottom of the text is rendered at the initial text position.

An example of using text-anchor on multi-line text.

This multi-line text is anchored to the middle.

The preserved line-feed creates two text chunks, each anchored independently.

Another example of using text-anchor on multi-line text.

The text is divided into three text chunks (due to the three coordinates in the ‘x’ and ‘y’ attributes). Each text chunk is independently anchored.

11.10.1.2. The ‘glyph-orientation-horizontal’ property

This property has been removed in SVG 2.

11.10.1.3. The ‘glyph-orientation-vertical’ property

This property applies only to vertical text. It has been obsoleted in SVG 2 and partially replaced by the text-orientation property of CSS Writing Modes Level 3. The following SVG 1.1 values must still be supported by aliasing the property as a shorthand to text-orientation as follows:

• 'auto' to'mixed';
• '0deg', and'0', to'upright'.
• '90deg', and'90', to'sideways'.

Any other values must be treated as invalid.

11.10.1.4. The ‘kerning’ property

The ‘kerning’ property has been removed in SVG 2.

SVG 1.1 uses the 'kerning' property to determine if the font kerning tables should be used to adjust inter-glyph spacing. It also allows a value which if given is added to the spacing between glyphs (supplemental to any from the letter-spacing property). This property is replaced in SVG 2 by the CSS font-kerning property which solely controls turning on/off the use of the font kerning tables.

Chrome's UseCounter data showed a use of 0.01% in 2014. See GitHub issue 80.

11.10.2. SVG adaptions

This section covers CSS properties that are not covered elsewhere in this specification and have either SVG specific adaptions or are significantly altered from SVG 1.1.

SVG 2 Requirement:	Reference CSS3 Fonts.
Resolution:	SVG 2 will depend on CSS3 Fonts.
Purpose:	Alignment with CSS 2.1 and CSS3 for Web font functionality, and to provide access to advanced typographic features of fonts.
Owner:	Chris (ACTION-3123)

11.10.2.1. The ‘font-variant’ property

This section is not normative

The font-variant property gets defined by the CSS Font Module ([css-font-3]).

CSS Font Module changes the meaning of thefont-variant property from that defined by CSS 2.1. It has been repurposed (and its functionality greatly expanded) as a shorthand for selecting font variants from within a single font.

SVG 2 supports all font-variant longhand properties (e.g. font-variant-ligatures).

11.10.2.2. The ‘line-height’ property

SVG uses the line-height property to determine the amount of leading space which is added between lines in multi-line text (both for horizontal and vertical text). It is not applicable to text on a path.

Except for the additional information provided here, thenormative definition of the line-height property is in the CSS 2.1 specification ([CSS2]).

The CSS Inline Module Level 3 may update the definition of 'line-height'.

11.10.2.3. The ‘writing-mode’ property

This section is not normative.

The writing-mode property gets defined by the CSS Writing Modes Module ([css-writing-modes-3]).

This property sets the block-flow direction; or in-other-words, the direction in which lines of text are stacked. As a consequence it also determines if the text has a horizontal or vertical orientation.

SVG 2 referencesCSS Writing Modes Level 3 for the definition of the'writing-mode' property. That specification introduces new values for the property. The SVG 1.1 values are obsolete but must still be supported by converting the specified values to computed values as follows:

In SVG 1.0, this property could be interpreted as to also setting theinline-base direction leading to confusion about its role relative to the direction property. SVG 1.1 was a bit more specific about the role of direction (e.g. that direction set the reference point for the text-anchor property) but still was open to interpretation. The fact that neither SVG 1.0 nor SVG 1.1 allowed multi-line text added to the confusion.

11.10.2.4. The ‘direction’ property

The property specifies the inline-base direction of a‘text’ or ‘tspan’ element. It defines thestart and end points of a line of text as used by the text-anchor and inline-size properties. It also may affect the direction in which characters are positioned if the unicode-bidi property's value is eitherembed orbidi-override.

The direction property applies only to glyphs oriented perpendicular to the inline-base direction, which includes the usual case of horizontally-oriented Latin or Arabic text and the case of narrow-cell Latin or Arabic characters rotated 90 degrees clockwise relative to a top-to-bottominline-base direction.

Reviewers, please take special care to ensure this agrees with CSS3 Writing modes.

Except for the additional information provided here, thenormative definition of the direction property is in CSS Writing Modes Level 3 ([css-writing-modes-3]).

In many cases, the bidirectional algorithm from Unicode [UNICODE] produces the desired result automatically, and in such cases the author does not need to use these properties. For other cases, such as when using right-to-left languages, it may be sufficient to add thedirection property to the outermost svg element, and allow that direction to inherit to all text elements, as in the following example (which may be used as a template):

Right-to-left Text A simple example for using the 'direction' property in documents that predominantly use right-to-left languages.

داستان SVG 1.1 SE طولا ني است.

Example

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

Below is another example, where implicit bidi reordering is not sufficient:

Right-to-left Text An example for using the 'direction' and 'unicode-bidi' properties in documents that predominantly use right-to-left languages.

כתובת MAC:‏ 00-24-AF-2A-55-FC

Example

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

11.10.2.5. The ‘dominant-baseline’ property

This property is defined in the CSS Line Layout Module 3 specification. See'dominant-baseline'. [css-inline-3]

SVG 2 introduces some changes to the definition of this property. In particular:

• The 'reset-size' value is no longer supported. Any change in font-size resets the dominant baseline table.
• The 'use-script' and 'no-change' values are no longer supported.
• The property is now inherited. (Behavior is effectively unchanged.)

SVG uses the value of the dominant-baseline property to align glyphs relative to the ‘x’ and ‘y’ attributes. For the text-orientation valuesideways, theauto value fordominant-baseline isalphabetic; however, for backwards compatibility, the glyphs should be aligned to the‘x’ and ‘y’ attributes using the value central.

We are interested in any actual use where one would prefer the old behavior.

11.10.2.6. The ‘alignment-baseline’ property

This property is defined in the CSS Line Layout Module 3 specification. See'alignment-baseline'. [css-inline-3]

The vertical-align property shorthand should be preferred in new content.

SVG 2 introduces some changes to the definition of this property. In particular: the values 'auto', 'before-edge', and 'after-edge' have been removed. For backwards compatibility, 'text-before-edge' should be mapped to 'text-top' and 'text-after-edge' should be mapped to 'text-bottom'. Neither 'text-before-edge' nor 'text-after-edge' should be used with the vertical-align property.

11.10.2.7. The ‘baseline-shift’ property

This property is defined in the CSS Line Layout Module 3 specification. See'baseline-shift'. [css-inline-3]

The vertical-align property shorthand should be preferred in new content.

The 'baseline' value was removed with the conversion of 'vertical-align' to a shorthand for 'alignment-baseline' and 'baseline-shift' as it is also a value for 'alignment-baseline' and it is redundant with a length value of '0'.

'baseline-shift' is important for aligning subscripts and superscripts (Inkscape relies on it for this purpose). It remains in the CSS Inline Layout Module Level 3.'vertical-align' is a shorthand for changing multiple properties at once, including 'baseline-shift'.

11.10.2.8. The ‘letter-spacing’ property

Except as noted, see CSS Text Level 3 for the definition of theletter-spacing.([css-text-3]).

SVG 1.1 allowed percentage values in the letter-spacing property. Percentage values based on the SVG viewport are not seen as useful, so this was removed in SVG 2. This brings the definition of 'letter-spacing' in line with CSS.

11.10.2.9. The ‘word-spacing’ property

Except as noted, see CSS Text Level 3 for the definition of theword-spacing.([css-text-3]).

SVG 2 changes the meaning of percentage values for theword-spacing property. In SVG 1.1, percentages define additional spacing as a percentage of the SVG viewport size. Percentage values based on the SVG viewport are not seen as useful. In SVG 2, following CSS Text Level 3, percentages define additional spacing as a percentage of the affected character's width. This brings the definition of 'word-spacing' in line with CSS.

11.10.2.10. The ‘text-overflow’ property

New in SVG 2. Added to allow user agents to handle text strings that overflow a predefined wrapping area in a more useful way. Aligns SVG and HTML/CSS text processing.

See the CSS3 Overflow specification for the definition of'text-overflow'. [css-overflow-3]

SVG uses the text-overflow property to control how text content block elements render when text overflows line boxes as, for example, can happen when thewhite-space property has the valuenowrap. The property does not apply to pre-formatted text or text-on-a-path.

In SVG text-overflow has an effect if there is a validly specified wrapping area, regardless of the computed value of the overflow property on the text content block element.

If the text-overflow property has the valueellipsis then if the text that is to be rendered overflows the wrapping area an ellipsis is rendered such that it fits within the given area. For the purposes of rendering, the ellipsis is treated as if it replaced the characters at the point where it is inserted.

If the text-overflow property has the valueclip then any text that overflows the wrapping area is clipped. Characters may be partially rendered.

Any other value for text-overflow is treated as if it wasn't specified.

Note that the effect of text-overflow is purely visual, the ellipsis itself does not become part of the DOM. For all the DOM methods it is as if text-overflow was not applied, and as if the wrapping area did not constrain the text.

The following example shows the use of text-overflow. The top line shows text as it would normally be rendered (text overflows due to white-space valuepre and is displayed due tooverflow value visible). The middle line shows text with text-overflow valueclip, and the bottom line shows text with text-overflow valueellipsis.

SVG is awesome SVG is awesome SVG is awesome

The text-overflow property used on text elements, the bottom line showing text with an ellipsis applied.

It has been argued that this property is useless. It would be of more use if coupled with a mechanism that would expose the hidden text (tool-tip on hovering over ellipses?). The text-overflow property only deals with text that overflows off the end of a line. It does not deal with text that overflows the off the end of the wrapping area.

11.10.3. White space

New in SVG 2. Added white-space to allow a more useful way to control white-space handling. Aligns SVG and HTML/CSS text processing. ‘xml:space’ deprecated in new content, retained for backwards compatibility.

11.10.3.1. SVG 2 Preferred white space handling, the ‘white-space’ property

Rendering of white space in SVG 2 is controlled by the white-space property. This specifies two things:

• whether and how white space inside the element is collapsed
• whether lines may wrap at unforced soft wrap opportunities

Values and their meanings are defined inCSS Text Module Level 3.[css-text-3]

An example of using the white-space value pre-line.

 <text x="150" y="30" style="font: 20px IPAMincho; writing-mode: vertical-rl;
                         white-space: pre-line;">
   千利奴流乎和加
   餘多連曽津祢那
   良牟有為能於久
   耶万計不己衣天
   阿佐伎喩女美之
   恵比毛勢須</text>

Example of multi-line vertical text with line breaks. The text is from the Japanese poem Iroha. The lines are broken at traditional places.

11.10.3.2. Legacy white-space handling, the ‘xml:space’ property

For compatibility, SVG 2 also supports the XML attribute‘xml:space’ to specify the handling of white space characters within a given ‘text’ element's character data. New content should not use ‘xml:space’ but instead, use the white-space property.

This section should be simplified to limit the discussion of xml:space and instead define it in the user agent style sheet using thewhite-space property. TheCSS Text 4 specification'spreserve-spaces value for the'white-space-collapse' property is intended to matchxml:space=preserve. (fantasai agreed to add an appropriate value for white-space to match SVG 1.1's odd xml:space="preserve" behavior.)

Note that any child element of a ‘text’ element may also have an ‘xml:space’ attribute which will apply to that child element's text content. The SVG user agent has special processing rules associated with this attribute as described below. These are behaviors that occur subsequent to XML parsing [XML] and any construction of a DOM.

‘xml:space’ is an inheritable attribute which can have one of two values:

'default'

(The initial/default value for ‘xml:space’.) Whenxml:space="default", the SVG user agent will do the following using a copy of the original character data content. First, it will remove all newline 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 using a copy of the original character data content. It will convert all newline and tab characters into space characters. Then, it will draw all space characters, including leading, trailing and multiple contiguous space characters. Thus, when drawn withxml: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 example illustrates that line indentation can be important when usingxml:space="default". The fragment below show two pairs of similar ‘text’ elements, with both ‘text’ elements usingxml:space="default". 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).

[01] [02] WS example [03] indented lines [04] [05] WS example indented lines [06] [07] [08]WS example [09]non-indented lines [10] [11] WS examplenon-indented lines

The first pair of ‘text’ elements above show the effect of indented character data. The attributexml:space="default" in the first‘text’ element instructs the user agent to:

• convert all tabs (if any) to space characters,
• strip out all line breaks (i.e., strip out the line breaks at the end of lines [01], [02] and [03]),
• strip out all leading space characters (i.e., strip out space characters before "WS example" on line [02]),
• strip out all trailing space characters (i.e., strip out space characters before "" on line [04]),
• consolidate all intermediate space characters (i.e., the space characters before "indented lines" on line [03]) into a single space character.

The second pair of ‘text’ elements above show the effect of non-indented character data. The attributexml:space="default" in the third‘text’ element instructs the user agent to:

• convert all tabs (if any) to space characters,
• strip out all line breaks (i.e., strip out the line breaks at the end of lines [07], [08] and [09]),
• strip out all leading space characters (there are no leading space characters in this example),
• strip out all trailing space characters (i.e., strip out space characters before "" on line [10]),
• consolidate all intermediate space characters into a single space character (in this example, there are no intermediate space characters).

Note that XML parsers are required to convert the standard representations for a newline indicator (e.g., the literal two-character sequence "U+000D U+000A", CARRIAGE-RETURN LINE-FEED or the stand-alone literals U+000D or U+000A) into the single character U+000A before passing character data to the application. Thus, each newline in SVG will be represented by the single character U+000A, no matter what representation for newlines might have been used in the original resource. (SeeXML end-of-line handling.)

Any features in the SVG language or the SVG DOM that are based on character position number, such as the ‘x’,‘y’, ‘dx’, ‘dy’ and‘rotate’ attributes on the ‘text’ and ‘tspan’ elements, are based on character position after applying the white space handling rules described here. In particular, if xml:space="default", it is often the case that white space characters are removed as part of processing. Character position numbers index into the text string after the white space characters have been removed per the rules in this section.

Note that a glyph corresponding to a white-space character should only be displayed as a visible but blank space, even if the glyph itself happens to be non-blank. See display of unsupported characters [UNICODE].

The ‘xml:space’ attribute is:

Animatable: no.

11.10.3.3. Duplicate white-space directives

Older, SVG 1.1 content will use ‘xml:space’. New content, and older content that is being reworked, will usewhite-space and remove any existing‘xml:space’. However, user agents may come across content which uses both methods on the same element. If the white-space property is set on any element, then the value of ‘xml:space’ is ignored.

11.11. Text decoration

Text in SVG can be decorated with an underline, overline, and/or strike-through. The position and style of the decoration is determined respectively by the text-decoration-line andtext-decoration-style properties, or by the text-decoration shorthand property as defined in theLine Decoration section of theCSS Text Decoration Module Level 3 [(css-text-decor-3)] specification.

The fill and stroke of the text decoration are given by the fill and stroke of the text at the point where the text decoration is declared (see example below).

The text-decoration-line andtext-decoration-style properties are new in SVG 2. The SVG 1.1/CSS 2.1 text-decoration property is transformed in a backwards compatible way to a short hand for these properties.

The order in which the text and decorations are drawn is defined by thePainting Order of Text Decorations section ofCSS Text Decoration Module Level 3. The paint order of the text decoration itself (fill/stroke) is determined by the value of thepaint-order property at the point where the text decoration is declared.

Example textdecoration01 provides examples for text-decoration. The first line of text has no value for text-decoration, so the initial value of text-decoration:none is used. The second line showstext-decoration:line-through. The third line showstext-decoration:underline. The fourth line illustrates the rule whereby decorations are rendered using the same fill and stroke properties as are present on the element for which the text-decoration is specified. Sincetext-decoration is specified on the ‘text’ element, all text within the ‘text’ element has its underline rendered with the same fill and stroke properties as exist on the ‘text’ element (i.e., blue fill, red stroke), even though the various words have different fill and stroke property values. However, the word "different" explicitly specifies a value for text-decoration; thus, its underline is rendered using the fill and stroke properties as the ‘tspan’ element that surrounds the word "different" (i.e., yellow fill, darkgreen stroke):

Example textdecoration01

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

11.12. 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
• no links orevents have been assigned to the ‘text’, ‘tspan’ or‘textPath’ element(s) (or their ancestors) associated with the given glyph.

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 applying styles for the ::selection pseudo-class. 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 glyph 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).

Detailed rules for determining which characters to highlight during a text selection operation are provided inText selection implementation notes.

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 it is 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 bidirectional text, the user agent must support text selection in logical order, which will result in discontinuous highlighting of glyphs due to the bidirectional reordering of characters. User agents can provide an alternative ability to select bidirectional text in visual rendering order (i.e., after bidirectional text layout algorithms have been applied), with the result that selected character data might be discontinuous logically. In this case, if the user requests that bidirectional 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.

SVG authors and SVG generators should order their text strings to facilitate properly ordered text selection within SVG viewing applications such as Web browsers; in other words, the DOM order of the text should match the natural reading order of the text.

11.12.1. Text selection implementation notes

The following implementation notes describe the algorithm for deciding which characters are selected during a text selectionoperation.

As the text selection operation occurs (e.g., while the user clicks and drags the mouse to identify the selection), the user agent determines a start selection position and an_end selection position_, each of which represents a position in the text string between two characters. After determining start selection position and end selection position, the user agent selects the appropriate characters, where the resulting text selection consists of either:

• no selection or
• a start character, an end character (possibly the same character), and all of the characters within the same ‘text’ element whose position in the DOM is logically between the start character and end character.

On systems with pointer devices, to determine the start selection position, the SVG user agent determines which boundary between characters corresponding to rendered glyphs is the best target (e.g., closest) based on the current pointer location at the time of the event that initiates the selection operation (e.g., the mouse down event). The user agent then tracks the completion of the selection operation (e.g., the mouse drag, followed ultimately by the mouse up). At the end of the selection operation, the user agent determines which boundary between characters is the best target (e.g., closest) for the end selection position.

If no character reordering has occurred due to bidirectionality, then the selection consists of all characters between the_start selection position_ and end selection position. For example, if a ‘text’ element contains the string "abcdef" and the start selection position and end selection positions are 0 and 3 respectively (assuming the left side of the "a" is position zero), then the selection will consist of "abc".

When the user agent is implementing selection of bidirectional text, and when the selection starts (or ends) between characters which are not contiguous in logical order, then there might be multiple potential combinations of characters that can be considered part of the selection. The algorithms to choose among the combinations of potential selection options shall choose the selection option which most closely matches the text string's visual rendering order.

When multiple characters map inseparably to a given set of one or more glyphs, the user agent can either disallow the selection to start in the middle of the glyph set or can attempt to allocate portions of the area taken up by the glyph set to the characters that correspond to the glyph.

For systems which support pointer devices such as a mouse, the user agent is required to provide a mechanism for selecting text even when the given text has associated event handlers or links, which might block text selection due to event processing precedence rules (see Pointer events). One implementation option: For platforms which support a pointer device such as a mouse, the user agent may provide for a small additional region around character cells which initiates text selection operations but does not initiate event handlers or links.

11.13. DOM interfaces

11.13.1. Interface SVGTextContentElement

The SVGTextContentElement interface is implemented by elements that support rendering child text content.

For the methods on this interface that refer to an index to a character or a number of characters, these references are to be interpreted as an index to a UTF-16 code unit or a number of UTF-16 code units, respectively. This is for consistency with DOM Level 2 Core, where methods on the CharacterData interface use UTF-16 code units as indexes and counts within the character data. Thus for example, if the text content of a ‘text’element is a single non-BMP character, such as U+10000, then invoking getNumberOfChars on that element will return 2 since there are two UTF-16 code units (the surrogate pair) used to represent that one character.

[Exposed=Window] interface SVGTextContentElement : SVGGraphicsElement {

// lengthAdjust Types const unsigned short LENGTHADJUST_UNKNOWN = 0; const unsigned short LENGTHADJUST_SPACING = 1; const unsigned short LENGTHADJUST_SPACINGANDGLYPHS = 2;

[SameObject] readonly attribute SVGAnimatedLength textLength; [SameObject] readonly attribute SVGAnimatedEnumeration lengthAdjust;

long getNumberOfChars(); float getComputedTextLength(); float getSubStringLength(unsigned long charnum, unsigned long nchars); DOMPoint getStartPositionOfChar(unsigned long charnum); DOMPoint getEndPositionOfChar(unsigned long charnum); DOMRect getExtentOfChar(unsigned long charnum); float getRotationOfChar(unsigned long charnum); long getCharNumAtPosition(optional DOMPointInit point = {}); undefined selectSubString(unsigned long charnum, unsigned long nchars); };

The numeric length adjustment type constants defined on SVGTextContentElementare used to represent the keyword values that the ‘lengthAdjust’ attribute can take. Their meanings are as follows:

Constant	Meaning
LENGTHADJUST_SPACING	The spacing keyword.
LENGTHADJUST_SPACINGANDGLYPHS	The spacingAndGlyphs keyword.
LENGTHADJUST_UNKNOWN	Some other value.

The textLength IDL attributereflects the ‘textLength’ content attribute.

The initial value of the ‘textLength’ content attribute is defined to equal the user-agent's calculated length for the element. In other words, when the content attribute is not present, the IDL property is initialized with a base length equal to the return-value of getComputedTextLengthon the same element, as a length in user units.

The lengthAdjust IDL attributereflects the ‘lengthAdjust’ content attribute. The numeric type valuesfor ‘lengthAdjust’ are as described above in the numeric length adjust type constant table.

The getNumberOfCharsmethod returns the total number of addressable characters available for rendering within the current element, regardless of whether they will be rendered. When getNumberOfChars() is called, the following steps are run:

1. Let node be the element or node upon which this method was called
2. If node is a DOM text node, return the length of the text content ofnode, after normalizing whitespace according to the value of thewhite-space property on its parent element.
3. If node is an Element:
   • If the element is not rendered (e.g., because the display property has the used valuenone), then return 0;
   • Otherwise, set count to 0, and for each child of node:
     * Recursively call this algorithm and add the returned value to count.

   Return count.

4. For all other node types (e.g., DOM comments), return 0.

The getComputedTextLengthmethod is used to compute a "length" for the text within the element. When getComputedTextLength() is called, the following steps are run:

1. Let count be the value that would be returned if the getNumberOfChars method were called on this element.
2. Let length be the value that would be returned if the getSubStringLength method were called on this element, passing 0 and count as arguments.
3. Return length.

The getSubStringLengthmethod is used to compute the formatted text advance distance for a substring of text within the element. When getSubStringLength(charnum, nchars) is called, the following steps are run:

1. Assign an index to each addressable character in the DOM within this element, where the first character has index 0.
2. If charnum is greater than the highest index assigned to a character or if nchars is negative, then throw an IndexSizeError.
3. Let length be a length in user units, initialized to 0.
4. For each addressable character in the DOM within this element that has an index such thatcharnum ≤ index < (charnum + nchars):
   1. If the character corresponds to a typographic character and it is the first character in document order to correspond to that typographic character, then:
      1. Add the advance of the typographic character to length, adjusted for any font kerning in effect.
      2. If the letter-spacing or word-spacing properties contributed space just after the typographic character, then add that space to length.
         This means that, for example, if there is a ligature that is only partly included in the substring, then the advance of the typographic character and any subsequent letter-spacing orword-spacing space will be assigned to the first character's text length.
5. Return length.

Previous versions of SVG required that this method and getComputedTextLength also include positioning adjustments in the inline direction due to‘dx’ or ‘dy’ on child elements, so that the returned value would be equivalent to the user agent's calculation for ‘textLength’. However, it was poorly specified, poorly implemented, and of dubious benefit, so has been simplified to match implementations.

Change to text length methods resolved at August 2015 Paris face-to-face.

To find the typographic character for a character at index index within an element element, the following steps are run:

1. Assign an index to each addressable character in the DOM within this element, where the first character has index 0.
2. Let last be the highest index assigned to a character.
3. While charnum < last and the character at index charnum does not correspond to a typographic character:
   1. Set charnum to charnum + 1.
4. If charnum is greater than the highest index assigned to a character or, then return null.
5. Otherwise, return the typographic character that corresponds tocharnum.

The getStartPositionOfCharmethod is used to get the position of a typographic character after text layout has been performed. When getStartPositionOfChar(charnum) is called, the following steps are run:

1. Let cluster be the result offinding the typographic character for the character at index charnum within the current element.
2. If cluster is null, then throw anIndexSizeError.
3. Let p be thealignment point of the typographic character that correspond to the character at index charnum, in the coordinate system of the current element.
4. Return a newly created, detached DOMPoint object representing the point p.

The getEndPositionOfCharmethod is used to get the trailing position of a typographic character after text layout has been performed. When getEndPositionOfChar(charnum) is called, the following steps are run:

1. Let cluster be the result offinding the typographic character for the character at index charnum within the current element.
2. If cluster is null, then throw anIndexSizeError.
3. Let p be thealignment point of cluster that correspond to the character at index charnum, in the coordinate system of the current element.
4. Let direction be a unit vector in the direction of the cluster's advance. This direction takes into account the writing mode being used, the direction of the character, the text-orientation, glyph-orientation-horizontal and glyph-orientation-vertical properties, any ‘rotate’ value that applies to cluster, and any rotation applied to due a ‘textPath’.
5. Let advance be cluster's advance.
6. Set p to p + advance · direction.
7. Return a newly created, detached DOMPoint object representing the point p.

The getExtentOfCharmethod is used to compute a tight bounding box of the glyph cell that corresponds to a given typographic character. When getExtentOfChar(charnum) is called, the following steps are run:

1. Let cluster be the result offinding the typographic character for the character at index charnum within the current element.
2. If cluster is null, then throw anIndexSizeError.
3. Let quad be the potentially rotated rectangle in the current element's coordinate system that is the glyph cell for cluster.
4. Let rect be the rectangle that forms the tightest bounding box around quad in the current element's coordinate system.
5. Return a newly created DOMRect object representing the rectangle rect.

The getRotationOfCharmethod is used to get the rotation of typographic character. When getRotationOfChar(charnum) is called, the following steps are run:

1. Let cluster be the result offinding the typographic character for the character at index charnum within the current element.
2. If cluster is null, then throw anIndexSizeError.
3. Let direction be the angle in degrees that represents the direction of the cluster's advance. This direction takes into account the writing mode being used, the direction of the character, the text-orientation, glyph-orientation-horizontal and glyph-orientation-vertical properties, any ‘rotate’ value that applies to cluster, and any rotation applied to due a ‘textPath’.
4. Return direction.

The getCharNumAtPositionmethod is used to find which character caused a text glyph to be rendered at a given position in the coordinate system. Because the relationship between characters and glyphs is not one-to-one, only the first character of the relevant typographic character is returned When getCharNumAtPosition(point) is called, the following steps are run:

1. Assign an index to each character in the DOM within this element, where the first character has index 0.
2. Let last be the highest index assigned to a character.
3. Let charnum be 0.
4. Let result be -1.
5. While charnum < last:
   1. If the character at index charnum corresponds to a typographic character and it is the first character in document order to correspond to that typographic character, and point in this element's coordinate system is within the glyph cell for the typographic character, then set result to charnum.
6. Return result.

The selectSubStringmethod is used to select text within the element. When selectSubString(charnum, nchars) is called, the following steps are run:

Selects a substring of the text in this element, beginning at character index charnum and extending forwards ncharscharacters. The following steps must be followed when this method is called:

1. Let node be this text content element.
2. Let count be the number of characters in this text content element.
3. Let end = charnum + nchars.
4. If charnum ≥ count or end ≥ count, then throw an IndexSizeError.
5. Remove all ranges from the document's selection. [DOM][EDITING]
6. Set the selection'sdirection to forwards.
7. Add to the selection a new range whosestart is theboundary point tuple (node, charnum) and end is the boundary point tuple (node, end).

Ignoring the argument checking and exception throwing, this is equivalent to performing the following:

var selection = document.getSelection(); selection.removeAllRanges(); var range = new Range(); range.setStart(textContentElement, charnum); range.setEnd(textContentElement, charnum + nchars); selection.addRange(range);

This method is deprecated, as it duplicates functionality from the Selection API.