Text

Within text content elements, the alignment of text with regards to the 'text-anchor' property is determined by the value of the 'direction' property. For example, given a 'text' element with a 'text-anchor' value of "end", for a 'direction' value of "ltr", the text will extend to the left of the position of the 'text' element's 'text/x' attribute value, while for 'direction' value of "rtl", the text will extend to the right of the position of the 'text' element's 'text/x' attribute value.

A more complete discussion of bidirectionality can be found in the Text direction section of CSS 2.1 ([CSS21], section 9.10).

The processing model for bidirectional text is as follows. The user agent processes the characters which are provided in logical order (i.e., the order the characters appear in the original document). The user agent determines the set of independent blocks within each of which it should apply the Unicode bidirectional algorithm. Each text chunk represents an independent block of text. Additionally, any change in glyph orientation due to processing of properties 'glyph-orientation-horizontal' or 'glyph-orientation-vertical' will subdivide the independent blocks of text further. After processing the Unicode bidirectional algorithm and properties 'direction' and 'unicode-bidi' on each of the independent text blocks, the user agent will have a potentially re-ordered list of characters which are now in left-to-right rendering order. Simultaneous with re-ordering of the characters, the 'tspan/dx', 'tspan/dy', and 'tspan/rotate' attributes on the 'tspan' elements are also re-ordered to maintain the original correspondence between characters and attribute values. While kerning or ligature processing might be font-specific, the preferred model is that kerning and ligature processing occurs between combinations of characters or glyphs after the characters have been re-ordered.

The 'direction' property

This property specifies the base writing direction of text and the direction of embeddings and overrides (see 'unicode-bidi') for the Unicode bidirectional algorithm. For the 'direction' property to have any effect on an element that does not by itself establish a new text chunk (such as a 'tspan' element without absolute position adjustments due to 'tspan/x' or 'tspan/y' attributes), the 'unicode-bidi' property's value must be embed or bidi-override.

Except for any additional information provided in this specification, the normative definition of the 'direction' property is in CSS 2.1 ([CSS21], section 9.10).

The 'direction' property applies only to glyphs oriented perpendicular to the inline-progression-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-bottom inline-progression-direction.

The 'unicode-bidi' property

Except for any additional information provided in this specification, the normative definition of the 'unicode-bidi' property is in CSS 2.1 ([CSS21], section 9.10).

Glyph orientation within a text run

CSS Writing Modes Module Level 3 replaces 'glyph-orientation-vertical' with 'text-orientation' but does not provide a replacement for 'glyph-orientation horizontal'. There is, however, a value 'use-glyph-orientation', only valid for SVG, which directs an implementation to use the values of 'glyph-orientation-veritical' and 'glyph-orientation-horizontal'. Note that this value is marked as at risk.

In some cases, it is required to alter the orientation of a sequence of characters relative to the inline-progression-direction. The requirement is particularly applicable to vertical layouts of East Asian documents, where sometimes narrow-cell Latin text is to be displayed horizontally and other times vertically.

Two properties control the glyph orientation relative to the reference orientation for each of the two possible inline-progression-directions. 'glyph-orientation-vertical' controls glyph orientation when the inline-progression-direction is vertical. 'glyph-orientation-horizontal' controls glyph orientation when the inline-progression-direction is horizontal.

The 'glyph-orientation-vertical' property

Reference CSS3 text? CSS3 has additional values: upright, inline.

auto

• Fullwidth ideographic and fullwidth Latin text will be set with a glyph-orientation of 0-degrees.

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

• Text which is not fullwidth will be set with a glyph-orientation of 90-degrees.

  This reorientation rule applies only to the first-level non-ideographic text. All further embedding of writing-modes or bidi processing will be based on the first-level rotation.

  • This is equivalent to having set the non-ideographic text string horizontally honoring the bidi-rule, then rotating the resultant sequence of inline-areas (one area for each change of glyph direction) 90-degrees clockwise.

    It should be noted that text set in this "rotated" manner may contain ligatures or other glyph combining and reordering common to the language and script. (This "rotated" presentation form does not disable auto-ligature formation or similar context-driven variations.)

  • The determination of which characters should be auto-rotated may vary across user agents. The determination is based on a complex interaction between country, language, script, character properties, font, and character context. It is suggested that one consult the Unicode TR 11 and the various JIS or other national standards.

<angle>

<number>

The glyph orientation angle. A value specified as a <number> is interpreted as an angle in degrees. The value of the angle is restricted to 0, 90, 180, and 270 degrees. The user agent shall round the value of the angle to the closest of the permitted values.

A value of 0deg indicates that all glyphs are set with the top of the glyphs oriented towards the reference orientation. A value of 90deg indicates an orientation of 90 degrees clockwise from the reference orientation.

This property is applied only to text written in a vertical 'writing-mode'.

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

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

	wide-cell glyph (e.g. Han) which is the n-th glyph in the text run
	narrow-cell glyph (e.g. Latin) which is the n-th glyph in the text run

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

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

The 'glyph-orientation-horizontal' property

Reference CSS3 text? CSS3 has additional values: auto, inline.

<angle>

<number>

The glyph orientation angle. A value specified as a <number> is interpreted as an angle in degrees. The value of the angle is restricted to 0, 90, 180, and 270 degrees. The user agent shall round the value of the angle to the closest of the permitted values.
A value of 0deg indicates that all glyphs are set with the top of the glyphs oriented towards the reference orientation. A value of 90deg indicates an orientation of 90 degrees clockwise from the reference orientation.

This property is applied only to text written in a horizontal 'writing-mode'.

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

Text layout – Positioning

Current text position is referred to throughout the document (almost 100 times!). The idea of current text position needs to be reconciled with CSS inline boxes. See: CSS-Inline as well as with the idea that text is laid out first using CSS rules and then tranformed, if necessary, with SVG rules.

The section covers the general rules for positiong glyphs. In SVG, the first step in positioning a glyph is to find its inline position which is determined by the current text position. Next, the glyph is aligned relative to a particular baseline. Once a glyph is positioned, the current text position is advanced and the next glyph is placed.

Current text position

In processing a given 'text' element, the SVG user agent keeps track of the current text position. The initial current text position is established by the 'text/x' and 'text/y' attributes on the 'text' element for pre-formatted and in some cases for auto-wrapped text. FIX FOR AUTO-WRAPPED TEXT IN SHAPE

The current text position is adjusted after each glyph to establish a new current text position at which the next glyph shall be rendered. The adjustment to the current text position is based on:

• The current inline-progression-direction.
• Glyph-specific advance values corresponding to the glyph orientation of the glyph just rendered.
• Kerning tables in the font.
• The current values of various attributes and properties, such as the spacing properties.
• New lines in pre-formatted or auto-wrapped text.

If a glyph does not provide explicit advance values corresponding to the current glyph orientation, then an appropriate approximation should be used. For vertical text, a suggested approximation is the sum of the ascent and descent values for the glyph. Another suggested approximation for an advance value for both horizontal and vertical text is the size of an em (see units-per-em).

For each glyph to be rendered, the SVG user agent determines an appropriate alignment-point on the glyph which will be placed exactly at the current text position. The alignment-point is determined based on glyph cell metrics in the glyph itself, the current inline-progression-direction and the glyph orientation relative to the inline-progression-direction. For example, in most uses of pre-formatted Latin text (i.e., writing-mode:lr, text-anchor:start, and alignment-baseline:baseline) the alignment-point in the glyph will be the intersection of left edge of the glyph cell (or some other glyph-specific x-axis coordinate indicating a left-side origin point) with the Latin baseline of the glyph. For many cases with top-to-bottom vertical text layout, the reference point will be either a glyph-specific origin point based on the set of vertical baselines for the font or the intersection of the center of the glyph with its top line (see top baseline; in [CSS3LINEBOX], section 4.2). If a glyph does not provide explicit origin points corresponding to the current glyph orientation, then an appropriate approximation should be used, such as the intersection of the left edge of the glyph with the appropriate horizontal baseline for the glyph or intersection of the top edge of the glyph with the appropriate vertical baseline. If baseline tables are not available, user agents should establish baseline tables that reflect common practice.

The distinction between absolute and relative position adjustments seems mostly made to define text chunks. 'x' and 'y' attributes are ignored for wrapped text and partially ignored for text on a path. Does this impact text chunks? How are new lines (either manual or auto) handled?

Once all the glyphs in a 'text' element are laid out according to the above rules, the position of the glyphs maybe adjusted according to SVG specific rules. Adjustments to the current text position are either absolute position adjustments or relative position adjustments. An absolute position adjustment occurs in the following circumstances:

• At the start of a 'text' element
• At the start of each 'textPath' element
• For each character within a 'text' and 'tspan' element which for pre-formatted text has an explicit 'x' or 'y' value, or for text on a path has an explicit 'x' value if horizontal or 'y' value if vertical.

All other position adjustments to the current text position are relative position adjustments.

Each absolute position adjustment defines a new text chunk. Absolute position adjustments impact text layout in the following ways:

• Ligatures only occur when a set of characters which might map to a ligature are all in the same text chunk.
• Each text chunk represents a separate block of text for alignment due to 'text-anchor' property values.
• Reordering of characters due to bidirectionality only occurs within a text chunk. Reordering does not happen across text chunks.

The following additional rules apply to ligature formation:

• As defined in CSS 2.1, ([CSS21], section 16.4), when the resultant space between two characters is not the same as the default space, user agents should not use ligatures; thus, if there is a non-default value for 'letter-spacing', the user agent should not use ligatures.
• Ligature formation should not be enabled for the glyphs corresponding to characters within different DOM text nodes; thus, characters separated by markup should not use ligatures.
• As mentioned above, ligature formation should not be enabled for the glyphs corresponding to characters within different text chunks.

White Space

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

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 in [CSS3 Text].

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

     width="200" height="200" viewBox="0 0 200 200">

     千利奴流乎和加
                                  餘多連曽津祢那
                                  良牟有為能於久
                                  耶万計不己衣天
                                  阿佐伎喩女美之
                                  恵比毛勢須

]]>

Example of multi-line vertical text with line breaks. The text is from the Japanese poem Iroha. The lines are broken at traditional places. Example does not render properly in Firefox. It is SVG 1.1 text. Bad Firefox.

Legacy whitespace 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.

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 [XML10] 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'.) When xml: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 with xml:space="preserve", the string "a   b" (three spaces between "a" and "b") will produce a larger separation between "a" and "b" than "a b" (one space between "a" and "b").

The following example illustrates that line indentation can be important when using xml:space="default". The fragment below show two pairs of similar 'text' elements, with both 'text' elements using xml: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]  <text xml:space='default'>
[02]    WS example
[03]    indented lines
[04]  </text>
[05]  <text xml:space='preserve'>WS example indented lines</text>
[06]
[07]  <text xml:space='default'>
[08]WS example
[09]non-indented lines
[10]  </text>
[11]  <text xml:space='preserve'>WS examplenon-indented lines</text>
  

The first pair of 'text' elements above show the effect of indented character data. The attribute xml: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 "</text>" 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 attribute xml: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 "</text>" 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 "#xD#xA" or the stand-alone literals #xD or #xA) into the single character #xA before passing character data to the application. Thus, each newline in SVG will be represented by the single character #xA, no matter what representation for newlines might have been used in the original resource. (See XML end-of-line handling.)

Any features in the SVG language or the SVG DOM that are based on character position number, such as the 'tspan/x', 'tspan/y', 'tspan/dx', 'tspan/dy' and 'tspan/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 whitespace 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.

Duplicate whitespace directives

Older, SVG 1.1 content will use 'xml:space'. New content, and older content that is being reworked, will use 'white-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.

Tab character size: the ‘tab-size’ property

See the CSS Text Module Level 3 specification for the definition of 'tab-size'. [CSSXX]

Line spacing, the 'line-height' property

New in SVG 2. Added for multi-line pre-formatted and auto-wrapped text. Aligns SVG and HTML/CSS text processing.

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

Is this correct for vertical text?

See the CSS2.1 specification for the definition of 'line-height'. [CSS21]

See the CSS Line Layout Module 3 specification for the definition of 'line-height'. [CSS3LINEBOX] CSS 3 adds the value 'none'.

Spacing within lines

Two properties affect the space between characters and words:

• 'letter-spacing' indicates an amount of space that is to be added between text characters.
• 'word-spacing' indicates the spacing behavior between words.

Note that the 'kerning' property from SVG 1.1 has been removed in favor of using 'letter-spacing' to add or remove spacing between glyphs and the 'font-kerning' property to disable kerning based on information from the font.

We need to require 'font-kerning'.

The 'letter-spacing' property

This property specifies spacing behavior between text characters.

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

If a <length> is provided with one of the unit identifiers (e.g., .25em or 1%), then the SVG user agent converts the <length> into a corresponding value in the current user coordinate system by applying the rules described in Units.

Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 16.4).

The 'word-spacing' property

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

If a <length> is provided with one of the unit identifiers (e.g., .25em or 1%), then the SVG user agent converts the <length> into a corresponding value in the current user coordinate system by applying the rules described in Units.

Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 16.4).

Baseline alignment properties

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

An overview of baseline alignment and baseline tables can be found above in Fonts, font tables and baselines.

One of the characteristics of international text is that there are different baselines (different alignment points) for glyphs in different scripts. For example, in horizontal writing, ideographic scripts, such as Han Ideographs, Katakana, Hiragana, and Hangul, alignment occurs with a baseline near the bottoms of the glyphs; alphabetic based scripts, such as Latin, Cyrillic, Hebrew, Arabic, align a point that is the bottom of most glyphs, but some glyphs descend below the baseline; and Indic based scripts are aligned at a point that is near the top of the glyphs.

When different scripts are mixed on a line of text, an adjustment must be made to ensure that the glyphs in the different scripts are aligned correctly with one another. OpenType [OPENTYPE] fonts have a Baseline table (BASE) [OPENTYPE-BASETABLE] that specifies the offsets of the alternative baselines from the current baseline.

SVG uses a similar baseline table model that assumes one script (at one font-size) is the "dominant run" during processing of a 'text' element; that is, all other baselines are defined in relation to this dominant run. The baseline of the script with the dominant run is called the dominant baseline. So, for example, if the dominant baseline is the alphabetic baseline, there will be offsets in the baseline table for the alternate baselines, such as the ideographic baseline and the Indic baseline. There will also be an offset for the math baseline which is used for some math fonts. Note that there are separate baseline tables for horizontal and vertical writing-modes. The offsets in these tables may be different for horizontal and vertical writing.

The baseline table established at the start of processing of a 'text' element is called the dominant baseline table.

Because the value of the 'font-family' property is a list of fonts, to insure a consistent choice of baseline table we define the nominal font in a font list as the first font in the list for which a glyph is available. This is the first font that could contain a glyph for each character encountered. (For this definition, glyph data is assumed to be present if a font substitution is made or if the font is synthesized.) This definition insures a content independent determination of the font and baseline table that is to be used.

The value of the 'font-size' property on the 'text' element establishes the dominant baseline table font size.

The model assumes that each glyph has a 'alignment-baseline' value which specifies the baseline with which the glyph is to be aligned. (The 'alignment-baseline' is called the "Baseline Tag" in the OpenType baseline table description.) The initial value of the 'alignment-baseline' property uses the baseline identifier associated with the given glyph. Alternate values for 'alignment-baseline' can be useful for glyphs such as a "*" which are ambiguous with respect to script membership.

The model assumes that the font from which the glyph is drawn also has a baseline table, the font baseline table. This baseline table has offsets in units-per-em from the (0,0) point to each of the baselines the font knows about. In particular, it has the offset from the glyph's (0,0) point to the baseline identified by the 'alignment-baseline'.

The offset values in the baseline table are in "design units" which means fractional units of the EM. Thus, the current 'font-size' is used to determine the actual offset from the dominant baseline to the alternate baselines.

The glyph is aligned so that its baseline identified by its 'alignment-baseline' is aligned with the baseline with the same name from the dominant baseline table.

The offset from the dominant baseline of the parent to the baseline identified by the 'alignment-baseline' is computed using the dominant baseline table and dominant baseline table font size. The font baseline table and font size applicable to the glyph are used to compute the offset from the identified baseline to the (0,0) point of the glyph. This second offset is subtracted from the first offset to get the position of the (0,0) point in the shift direction. Both offsets are computed by multiplying the baseline value from the baseline table times the appropriate font size value.

If the 'alignment-baseline' identifies the dominant baseline, then the first offset is zero and the glyph is aligned with the dominant baseline; otherwise, the glyph is aligned with the chosen alternate baseline.

The baseline-identifiers below are used in this specification. Some of these are determined by baseline-tables contained in a font as described in XSL ([XSL], section 7.9.1). Others are computed from other font characteristics as described below.

alphabetic

This identifies the baseline used by most alphabetic and syllabic scripts. These include, but are not limited to, many Western, Southern Indic, Southeast Asian (non-ideographic) scripts.

ideographic

This identifies the baseline used by ideographic scripts. For historical reasons, this baseline is at the bottom of the ideographic EM box and not in the center of the ideographic EM box. See the "central" baseline. The ideographic scripts include Chinese, Japanese, Korean, and Vietnamese Chu Nom.

hanging

This identifies the baseline used by certain Indic scripts. These scripts include Devanagari, Gurmukhi and Bengali.

mathematical

This identifies the baseline used by mathematical symbols.

central

This identifies a computed baseline that is at the center of the EM box. This baseline lies halfway between the text-before-edge and text-after-edge baselines.

For ideographic fonts, this baseline is often used to align the glyphs; it is an alternative to the ideographic baseline.

middle

This identifies a baseline that is offset from the alphabetic baseline in the shift-direction by 1/2 the value of the x-height font characteristic. The position of this baseline may be obtained from the font data or, for fonts that have a font characteristic for "x-height", it may be computed using 1/2 the "x-height". Lacking either of these pieces of information, the position of this baseline may be approximated by the "central" baseline.

text-before-edge

This identifies the before-edge of the EM box. The position of this baseline may be specified in the baseline-table or it may be calculated.

The position of this baseline is normally around or at the top of the ascenders, but it may not encompass all accents that can appear above a glyph. For these fonts the value of the "ascent" font characteristic is used. For ideographic fonts, the position of this baseline is normally 1 EM in the shift-direction from the "ideographic" baseline. However, some ideographic fonts have a reduced width in the inline-progression-direction to allow tighter setting. When such a font, designed only for vertical writing-modes, is used in a horizontal writing-mode, the "text-before-edge" baseline may be less than 1 EM from the text-after-edge.

text-after-edge

This identifies the after-edge of the EM box. The position of this baseline may be specified in the baseline-table or it may be calculated.

For fonts with descenders, the position of this baseline is normally around or at the bottom of the descenders. For these fonts the value of the "descent" font characteristic is used. For ideographic fonts, the position of this baseline is normally at the "ideographic" baseline.

There are, in addition, two computed baselines that are only defined for line areas. Since SVG does not support the notion of computations based on line areas, the two computed baselines are mapped as follows:

before-edge

For SVG, this is equivalent to text-before-edge.

after-edge

For SVG, this is equivalent to text-after-edge.

There are also four baselines that are defined only for horizontal writing-modes.

top

This baseline is the same as the "before-edge" baseline in a horizontal writing-mode and is undefined in a vertical writing mode.

text-top

This baseline is the same as the "text-before-edge" baseline in a horizontal writing-mode and is undefined in a vertical writing mode.

bottom

This baseline is the same as the "after-edge" baseline in a horizontal writing-mode and is undefined in a vertical writing mode.

text-bottom

This baseline is the same as the "text-after-edge" baseline in a horizontal writing-mode and is undefined in a vertical writing mode.

The 'dominant-baseline' property

See the CSS Line Layout Module 3 specification for the definition of 'dominant-baseline'. [CSSXX]

The "dominant-baseline" property is used to determine or re-determine a scaled-baseline-table. A scaled-baseline-table is a compound value with three components: a baseline-identifier for the dominant-baseline, a baseline-table and a baseline-table font-size. Some values of the property re-determine all three values; other only re-establish the baseline-table font-size. When the initial value, auto, would give an undesired result, this property can be used to explicitly set the desire scaled-baseline-table.

Values for the property have the following meaning:

auto

If this property occurs on a 'text' element, then the computed value depends on the value of the 'writing-mode' property. If the 'writing-mode' is horizontal, then the value of the dominant-baseline component is 'alphabetic', else if the 'writing-mode' is vertical, then the value of the dominant-baseline component is 'central'.

If this property occurs on a 'tspan' or 'textPath' element, then the dominant-baseline and the baseline-table components remain the same as those of the parent text content element. If the computed 'baseline-shift' value actually shifts the baseline, then the baseline-table font-size component is set to the value of the 'font-size' property on the element on which the 'dominant-baseline' property occurs, otherwise the baseline-table font-size remains the same as that of the element. If there is no parent text content element, the scaled-baseline-table value is constructed as above for 'text' elements.

use-script

The dominant-baseline and the baseline-table components are set by determining the predominant script of the character data content. The 'writing-mode', whether horizontal or vertical, is used to select the appropriate set of baseline-tables and the dominant baseline is used to select the baseline-table that corresponds to that baseline. The baseline-table font-size component is set to the value of the 'font-size' property on the element on which the 'dominant-baseline' property occurs.

no-change

The dominant-baseline, the baseline-table, and the baseline-table font-size remain the same as that of the parent text content element.

reset-size

The dominant-baseline and the baseline-table remain the same, but the baseline-table font-size is changed to the value of the 'font-size' property on this element. This re-scales the baseline-table for the current 'font-size'.

ideographic

The baseline-identifier for the dominant-baseline is set to be 'ideographic', the derived baseline-table is constructed using the 'ideographic' baseline-table in the nominal font, and the baseline-table font-size is changed to the value of the 'font-size' property on this element.

alphabetic

The baseline-identifier for the dominant-baseline is set to be 'alphabetic', the derived baseline-table is constructed using the 'alphabetic' baseline-table in the nominal font, and the baseline-table font-size is changed to the value of the 'font-size' property on this element.

hanging

The baseline-identifier for the dominant-baseline is set to be 'hanging', the derived baseline-table is constructed using the 'hanging' baseline-table in the nominal font, and the baseline-table font-size is changed to the value of the 'font-size' property on this element.

mathematical

The baseline-identifier for the dominant-baseline is set to be 'mathematical', the derived baseline-table is constructed using the 'mathematical' baseline-table in the nominal font, and the baseline-table font-size is changed to the value of the 'font-size' property on this element.

central

The baseline-identifier for the dominant-baseline is set to be 'central'. The derived baseline-table is constructed from the defined baselines in a baseline-table in the nominal font. That font baseline-table is chosen using the following priority order of baseline-table names: 'ideographic', 'alphabetic', 'hanging', 'mathematical'. The baseline-table font-size is changed to the value of the 'font-size' property on this element.

middle

The baseline-identifier for the dominant-baseline is set to be 'middle'. The derived baseline-table is constructed from the defined baselines in a baseline-table in the nominal font. That font baseline -table is chosen using the following priority order of baseline-table names: 'alphabetic', 'ideographic', 'hanging', 'mathematical'. The baseline-table font-size is changed to the value of the 'font-size' property on this element.

text-after-edge

The baseline-identifier for the dominant-baseline is set to be 'text-after-edge'. The derived baseline-table is constructed from the defined baselines in a baseline-table in the nominal font. The choice of which font baseline-table to use from the baseline-tables in the nominal font is implementation defined. The baseline-table font-size is changed to the value of the 'font-size' property on this element.

Using the following priority order of baseline-table names: 'alphabetic', 'ideographic', 'hanging', 'mathematical' is probably a reasonable strategy for determining which font baseline-table to use.

text-before-edge

The baseline-identifier for the dominant-baseline is set to be 'text-before-edge'. The derived baseline-table is constructed from the defined baselines in a baseline-table in the nominal font. The choice of which baseline-table to use from the baseline-tables in the nominal font is implementation defined. The baseline-table font-size is changed to the value of the 'font-size' property on this element.

Using the following priority order of baseline-table names: 'alphabetic', 'ideographic', 'hanging', 'mathematical' is probably a reasonable strategy for determining which font baseline-table to use.

If there is no baseline table in the nominal font or if the baseline table lacks an entry for the desired baseline, then the user agent may use heuristics to determine the position of the desired baseline.

The 'alignment-baseline' property

See the CSS Line Layout Module 3 specification for the definition of 'alignment-baseline'. [CSSXX]

This property specifies how an object is aligned with respect to its parent. This property specifies which baseline of this element is to be aligned with the corresponding baseline of the parent. For example, this allows alphabetic baselines in Roman text to stay aligned across font size changes. It defaults to the baseline with the same name as the computed value of the alignment-baseline property. That is, the position of "ideographic" alignment-point in the block-progression-direction is the position of the "ideographic" baseline in the baseline-table of the object being aligned.

Values have the following meanings:

auto

The value is the dominant-baseline of the script to which the character belongs – i.e., use the dominant-baseline of the parent.

baseline

The alignment-point of the object being aligned is aligned with the dominant-baseline of the parent text content element.

before-edge

The alignment-point of the object being aligned is aligned with the "before-edge" baseline of the parent text content element.

text-before-edge

The alignment-point of the object being aligned is aligned with the "text-before-edge" baseline of the parent text content element.

middle

The alignment-point of the object being aligned is aligned with the "middle" baseline of the parent text content element.

central

The alignment-point of the object being aligned is aligned with the "central" baseline of the parent text content element.

after-edge

The alignment-point of the object being aligned is aligned with the "after-edge" baseline of the parent text content element.

text-after-edge

The alignment-point of the object being aligned is aligned with the "text-after-edge" baseline of the parent text content element.

ideographic

The alignment-point of the object being aligned is aligned with the "ideographic" baseline of the parent text content element.

alphabetic

The alignment-point of the object being aligned is aligned with the "alphabetic" baseline of the parent text content element.

hanging

The alignment-point of the object being aligned is aligned with the "hanging" baseline of the parent text content element.

mathematical

The alignment-point of the object being aligned is aligned with the "mathematical" baseline of the parent text content element.

The 'baseline-shift' property

See the CSS Line Layout Module 3 specification for the definition of 'baseline-shift'. [CSSXX]

The 'baseline-shift' property allows repositioning of the dominant-baseline relative to the dominant-baseline of the parent text content element. The shifted object might be a sub- or superscript. Within the shifted object, the whole baseline-table is offset; not just a single baseline. The amount of the shift is determined from information from the parent text content element, the sub- or superscript offset from the nominal font of the parent text content element, percent of the "line-height" of the parent text content element or an absolute value.

In SVG, the 'baseline-shift' property represents a supplemental adjustment to the baseline tables. The 'baseline-shift' property shifts the baseline tables for each glyph to temporary new positions, for example to lift the glyph into superscript or subscript position, but it does not effect the current text position. When the current text position is adjusted after rendering a glyph to take into account glyph advance values, the adjustment happens as if there were no baseline shift.

'baseline-shift' properties can nest. Each nested 'baseline-shift' is added to previous baseline shift values.

Values for the property have the following meaning:

baseline

There is no baseline shift; the dominant-baseline remains in its original position.

sub

The dominant-baseline is shifted to the default position for subscripts. The offset to this position is determined using the font data for the nominal font. Because in most fonts the subscript position is normally given relative to the "alphabetic" baseline, the user agent may compute the effective position for subscripts for superscripts when some other baseline is dominant. The suggested computation is to subtract the difference between the position of the dominant baseline and the position of the "alphabetic" baseline from the position of the subscript. The resulting offset is determined by multiplying the effective subscript position by the dominant baseline-table font-size. If there is no applicable font data the user agent may use heuristics to determine the offset.

super

The dominant-baseline is shifted to the default position for superscripts. The offset to this position is determined using the font data for the nominal font. Because in most fonts the superscript position is normally given relative to the "alphabetic" baseline, the user agent may compute the effective position for superscripts when some other baseline is dominant. The suggested computation is to subtract the difference between the position of the dominant baseline and the position of the "alphabetic" baseline from the position of the superscript. The resulting offset is determined by multiplying the effective superscript position by the dominant baseline-table font-size. If there is no applicable font data the user agent may use heuristics to determine the offset.

<percentage>

The computed value of the property is this percentage multiplied by the computed "line-height" of the 'text' element. The dominant-baseline is shifted in the shift direction (positive value) or opposite to the shift direction (negative value) of the parent text content element by the computed value. A value of "0%" is equivalent to "baseline".

<length>

The dominant-baseline is shifted in the shift direction (positive value) or opposite to the shift direction (negative value) of the parent text content element by the <length> value. A value of "0cm" is equivalent to "baseline".

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.

  In Firefox. Needs to be fully specified.

• Use a single 'text' element with one or more 'tspan' child elements with appropriate values for attributes 'tspan/x', 'tspan/y', 'tspan/dx' and 'tspan/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 prevents selection across multiple lines of text -- see Text 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'.

Multi-line text via 'white-space'

Multi-line pre-formatted text may be created by using the 'white-space' values pre or pre-line. In these cases, a line-feed or carriage return is preserved as a forced line break. When a renderer encounters a forced line break, the current text position is set as follows:

• For horizontal text: x is reset to the initial current text position while y is incremented by the computed value of the 'line-height' property.
• For vertical text: y is reset to the initial value while x is decremented (for right-to-left block-progression-direction) or incremented (for left-to-right block-progression-direction) by the computed value of 'line-height'.

  SVG 1.1 only has right-to-left vertical text but CSS Writing Modes Module Level 3 also has left-to-right. This is required for Mongolian.

Adjusting Text Chunks

After text is laid out according to the basic CSS text layout rules, glyphs can be repositioned using SVG specific rules. Two types of adjustments can be made. The first uses the 'tspan/x', 'tspan/y', 'tspan/dx', 'tspan/dy', 'tspan/rotate' attributes to reposition glyphs with in a 'tspan' element. The second uses the 'text-anchor' property to realign lines of text.

Repositioning Glyphs

Expand on how 'x' and 'y' effect characters.

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 relative to a given point. It is not applicable to auto-wrapped text, see instead 'text-align'. For multi-line text, the alignment takes place for each line.

This is confusing, perhaps a figure would help: The 'text-anchor' property is applied to each individual text 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 'text/x' and 'text/y' attributes on the 'text' element, any 'tspan/x' or 'tspan/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.

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 a 'direction' 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 aligned such that the geometric middle of the resulting rendered text is at the initial current text position.

end

The rendered characters are aligned such that the end 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 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.


]]>

Text anchoring is applied independently to each line of text.

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 the wrapping context from the content area. The wrapping context may also be reduced by the value of the 'shape-padding' property. The effective area of an exclusion may be enlarged by the value of the 'shape-margin' property.

In the case where the content area is defined by the by the 'text/height' or 'text/width' attributes, the 'tspan/x' and 'tspan/y' attributes corresponding to the first rendered glyph define the initial current text position. When the content area is inside a shape, the initial current text position is determined by FIX ME, FIND WHERE IN CSS THIS IS SPECED..

Except when used to determine the initial current text position, all values 'tspan/x' and 'tspan/y' are ignored on 'text', and 'tspan' elements.

The attributes 'text/x' and 'text/y' can provide a natural fallback mechanism for SVG1.1 renderers for wrapped text. Provide an example (actually, all the example SVG's displayed in this section do this)..

How does shape-padding effect text when the content area is defined by length or width. I am inclined to allow shape-padding only when the content area is defined by an SVG shape.

Alignment

Text alignment: the 'text-align' property

See the CSS Text Module Level 3 specification for the definition of 'text-align'. [CSSXX]

Last line alignment: the 'text-align-last' property

See the CSS Text Module Level 3 specification for the definition of 'text-align-last'. [CSSXX]

Line Breaking

Breaking Rules for Punctuation: the ‘line-break’ property

See the CSS Text Module Level 3 specification for the definition of 'line-break'. [CSSXX]

Breaking Rules for Letters: the ‘word-break’ property

See the CSS Text Module Level 3 specification for the definition of 'word-break'. [CSSXX]

Hyphenation Control: the ‘hyphens’ property

See the CSS Text Module Level 3 specification for the definition of 'hyphens'. [CSSXX]

Overflow Wrapping: the ‘word-wrap’ and ‘overflow-wrap’ properties

See the CSS Text Module Level 3 specification for the definition of 'word-wrap'. [CSSXX]

See the CSS Text Module Level 3 specification for the definition of 'overflow-wrap'. [CSSXX]

Edge Effects

First Line Indentation: the ‘text-indent’ property

See the CSS Text Module Level 3 specification for the definition of 'text-indent'. [CSSXX]

This property might also be useful for preformatted text.

Hanging Punctuation: the ‘hanging-punctuation’ property

See the CSS Text Module Level 3 specification for the definition of 'hanging-punctuation'. [CSSXX]

This property might also be useful for preformatted text. It is marked in the CSS spec as at risk.

Text on a path

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

Text on a path is conceptional like a single line of pre-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.

The 'textPath' element

SVG 2 Requirement:	Have a more precise explanation of text path stretch methods.
Resolution:	We will clarify method="stretch" on >'textPath' elements.
Purpose:	Improve interoperability of the feature.
Owner:	Cameron (no action)

Attributes

startOffset

An offset from the start of the path for the initial current text position, calculated using the user agent's distance along the path algorithm.

If a <length> other than a percentage is given, then the 'startOffset' represents a distance along the path measured in the current user coordinate system.
If a percentage is given, then the 'startOffset' represents a percentage distance along the entire path. Thus, startOffset="0%" indicates the start point of the path and startOffset="100%" indicates the end point of the path.

Value

<length>

Lacuna value

0

Animatable

yes

method

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

A value of align indicates that the glyphs should be rendered using simple 2x3 transformations such that there is no stretching/warping of the glyphs. Typically, supplemental rotation, scaling and translation transformations are done for each glyph to be rendered. As a result, with align, fonts where the glyphs 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 glyph 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 glyphs, such as in cursive scripts, will maintain their connections.

Value

align | stretch

Lacuna value

align

Animatable

yes

spacing

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

A value of exact indicates that the glyphs should be rendered exactly according to the spacing rules as specified in Text 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 glyphs in order to achieve visually appealing results.

Value

auto | exact

Lacuna value

align

Animatable

yes

d

The definition of the path onto which the glyphs will be rendered. The handling of erroneous path data follows the behavior specified in the 'path' element implementation notes.

If both the 'd' attribute and 'xlink:href' attributes are specified, it is as if the 'xlink:href' attribute were not specified for the purposes of rendering. In the SVGTextPathElement interface both values will still be reflected. Furthermore, if a value for 'xlink:href' is specified in markup and path data is subsequently specified via the SVGAnimatedPathData::pathSegList member of the SVGTextPathElement, then this is equivalent to specifying the 'd' attribute—the 'xlink:href' will be disregarded for rendering and the path specified in the SVGAnimatedPathData::pathSegList will be used instead.

Value

path data

Lacuna value

See above.

Animatable

yes

xlink:href

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

Value

<url>

Lacuna value

See above.

Animatable

yes

The path data coordinates within the referenced 'path' 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 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:

<svg xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <g transform="translate(25,25)">
    <defs>
      <path id="path1" transform="scale(2)" d="..." fill="none" stroke="red"/>
    </defs>
  </g>
  <text transform="rotate(45)">
    <textPath xlink:href="#path1">Text on a path1</textPath>
  </text>
</svg>
  

should have the same effect as the following:

<svg xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <g transform="rotate(45)">
    <defs>
      <path id="path1" transform="scale(2)" d="..." fill="none" stroke="red"/>
    </defs>
    <text>
      <textPath xlink:href="#path1">Text on a path1</textPath>
    </text>
  </g>
</svg>
  

Note that the transform="translate(25,25)" has no effect on the 'textPath' element, whereas the transform="rotate(45)" applies to both the 'text' and the use of the 'path' element as the referenced shape for text on a path.

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

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 'tspan/dy' is used to lift the word "up" from the baseline.

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

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 standard text 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 reference orientation is determined individually for each glyph that is rendered along the path. For horizontal text layout flows, the reference orientation for a given glyph is 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 reference orientation for a given glyph is 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.

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.

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 the inline-progression-direction), the layout rules are as follows:

• Determine the startpoint-on-the-path for the first glyph using attribute 'startOffset' and property 'text-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 'tspan/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's distance along the path algorithm. This point is the endpoint-on-the-path for the glyph. (In the picture above, the endpoint-on-the-path for the glyph is the rightmost dot on the path.)
• Determine the midpoint-on-the-path, which is the point on the path which is "halfway" (user agents can choose either a distance calculation or a parametric calculation) between the startpoint-on-the-path and the endpoint-on-the-path. (In the picture above, the midpoint-on-the-path is shown as a white dot.)
• Determine the glyph-midline, which is the vertical line in the glyph's coordinate system that goes through the glyph's x-axis midpoint. (In the picture above, the glyph-midline is shown as a dashed line.)
• Position the glyph such that the glyph-midline passes through the midpoint-on-the-path and is perpendicular to the line through the startpoint-on-the-path and the endpoint-on-the-path.
• Align the glyph vertically relative to the midpoint-on-the-path based on property 'alignment-baseline' and any specified values for attribute 'tspan/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 and 'tspan' elements with values provided for attributes 'tspan/dx' and 'tspan/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 either end of the path are not rendered.
• Continue rendering glyphs until there are no more glyphs.

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-progression-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 'tspan/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's distance 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 'tspan/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 'tspan/dx' and 'tspan/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 either end of the path are not rendered.
• Continue rendering glyphs until there are no more glyphs.

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

When the inline-progression-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-progression-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.

Text rendering order

The glyphs associated with the characters within a 'text' element are rendered in the logical order of the characters in the original document, independent of any re-ordering necessary to implement bidirectionality. Thus, for text that goes right-to-left visually, the glyphs associated with the rightmost character are rendered before the glyphs associated with the other characters.

Additionally, each distinct glyph is rendered in its entirety (i.e., it is filled and stroked as specified by the 'fill' and 'stroke' properties) before the next glyph gets rendered.

Text overflow processing: the 'text-overflow' property

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

See the CSS3 UI specification for the definition of of 'text-overflow'. [CSS3UI]

SVG uses the 'text-overflow' property to control how text content block elements render when the text overflows a specified region. In the case of wrapped text, the region is the wrapping area. In the case of text on a path, a region is determined by the path length. Pre-formatted text does not create a region.

When applied to a text content block element setting 'text-overflow' to ellipsis then if the text that is to be rendered overflows the specified region an ellipsis is rendered such that it fits within the given region. For the purposes of rendering, the ellipsis is treated as if it replaced the characters at the point where it is inserted. In SVG 'text-overflow' has an effect if there is a validly specified region, regardless of the computed value of the 'overflow' property on the text content block element.

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

SVG could allow the keyword 'clip' to work too. It's already possible to do clipping with clip-path, but it's unconditional, where this would theoretically only clip if the text overflowed. It's mostly a convenient shorthand.

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's as if 'text-overflow' wasn't applied, and as if 'text/width' didn't constrain the text.

Need updated example.

The following example shows the use of 'text-overflow'. The top line shows text as it would normally be rendered, without any width restriction. The middle line shows text with text-overflow=clip specified, and the bottom line shows text with text-overflow=ellipsis.

  

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

Font selection properties

SVG uses the following font specification properties. Except for any additional information provided in this specification, the normative definition of these properties is in CSS 2.1 ([CSS21], chapter 15). Any SVG-specific notes about these properties are contained in the descriptions below.

Update to "CSS Font Module Level 3. Note that 'font-variant' is completely reworked.

The 'font-family' property

This property indicates which font family is to be used to render the text, specified as a prioritized list of font family names and/or generic family names. Unless the family name corresponds to a CSS IDENT, it must be quoted. Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.3).

The 'font-style'property

This property specifies whether the text is to be rendered using a normal, italic or oblique face. Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.4).

The 'font-variant' property

This property indicates whether the text is to be rendered using the normal glyphs for lowercase characters or using small-caps glyphs for lowercase characters. Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.5).

The 'font-weight' property

This property refers to the boldness or lightness of the glyphs used to render the text, relative to other fonts in the same font family. Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.6).

The 'font-stretch' property

This property indicates the desired amount of condensing or expansion in the glyphs used to render the text. Except for any additional information provided in this specification, the normative definition of the property is in CSS3 Fonts ([CSS3FONTS], section 3.3).

The 'font-size' property

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

If a <length> is provided with one of the unit identifiers (e.g., 12pt or 10%), then the SVG user agent converts the <length> into a corresponding value in the current user coordinate system by applying the rules described in Units.

Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.7).

The 'font-size-adjust' property

This property allows authors to specify an aspect value for an element that will preserve the x-height of the first choice font in a substitute font. Except for any additional information provided in this specification, the normative definition of the property is in CSS3 Fonts ([CSS3FONTS], section 3.6).

The 'font' property

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

Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 15.8).

Text decoration

The 'text-decoration' property

Do we align with CSS Text Decoration Module Level 3?

This property describes decorations that are added to the text of an element. Conforming SVG Viewers are not required to support the blink value.

Except for any additional information provided in this specification, the normative definition of the property is in CSS 2.1 ([CSS21], section 16.3.1).

The CSS 2.1 specification defines the behavior of the 'text-decoration' property using the terminology "block-level elements" and "inline elements". For the purposes of the 'text-decoration' property and SVG, a 'text' element represents a block-level element and any of the potential children of a 'text' element (e.g., a 'tspan') represent inline elements.

Also, the CSS 2.1 definition of 'text-decoration' specifies that the "color of the decorations" remain the same on descendant elements. Since SVG offers a painting model consisting of the ability to apply various types of paint (see Painting: Filling, Stroking and Marker Symbols) to both the interior (i.e., the "fill") and the outline (i.e., the "stroke") of text, for SVG the 'text-decoration' property is defined such that, for an element which has a specified value for the 'text-decoration' property, all decorations on its content and that of its descendants are rendered using the same fill and stroke properties as are present on the given element. If the 'text-decoration' property is specified on a descendant, then that overrides the ancestor.

Because SVG allows text to be both filled and stroked, drawing order matters in some circumstances with text decorations. Text decoration drawing order should be as follows:

• All text decorations except line-through should be drawn before the text is filled and stroked; thus, the text is rendered on top of these decorations.
• Line-through should be drawn after the text is filled and stroked; thus, the line-through is rendered on top of the text.

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 shows text-decoration:line-through. The third line shows text-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. Since 'text-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):

interface SVGTextContentElement : SVGGraphicsElement {

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

  readonly attribute SVGAnimatedLength textLength;
  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(DOMPoint point);
  void selectSubString(unsigned long charnum, unsigned long nchars);
};

interface SVGTextPositioningElement : SVGTextContentElement {
  readonly attribute SVGAnimatedLengthList x;
  readonly attribute SVGAnimatedLengthList y;
  readonly attribute SVGAnimatedLengthList dx;
  readonly attribute SVGAnimatedLengthList dy;
  readonly attribute SVGAnimatedNumberList rotate;
};

interface SVGTextElement : SVGTextPositioningElement {
};

interface SVGTSpanElement : SVGTextPositioningElement {
};

interface SVGTextPathElement : SVGTextContentElement {

  // textPath Method Types
  const unsigned short TEXTPATH_METHODTYPE_UNKNOWN = 0;
  const unsigned short TEXTPATH_METHODTYPE_ALIGN = 1;
  const unsigned short TEXTPATH_METHODTYPE_STRETCH = 2;

  // textPath Spacing Types
  const unsigned short TEXTPATH_SPACINGTYPE_UNKNOWN = 0;
  const unsigned short TEXTPATH_SPACINGTYPE_AUTO = 1;
  const unsigned short TEXTPATH_SPACINGTYPE_EXACT = 2;

  readonly attribute SVGAnimatedLength startOffset;
  readonly attribute SVGAnimatedEnumeration method;
  readonly attribute SVGAnimatedEnumeration spacing;
};

SVGTextPathElement implements SVGURIReference;
SVGTextPathElement implements SVGAnimatedPathData;