--- a/master/text.html Thu May 10 13:01:10 2012 +0200
+++ b/master/text.html Fri May 11 00:29:22 2012 +0200
@@ -17,204 +17,94 @@
<!-- THESE ANNOTATIONS NEED TO BE MOVED TO PROPER SECTIONS -->
<div class="annotation">
- <p>
- SVG2 Requirement: Require automatic text wrapping in arbitrary shapes compatible with CSS.
- </p>
- <p>
- Resolution: SVG2 will require automatic textwrapping compatible with CSS.
- </p>
- <p>
- <a href="http://www.w3.org/2011/11/17-svg-irc#T22-04-11">Conference call 2012-11-17</a>.
- </p>
- <p>
- Purpose: Text in flow charts, etc.
- </p>
- <p>
- Owner: Tav.
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties
- </p>
- <p>
- Resolution: SVG2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties.
- </p>
- <p>
- <a href="http://www.w3.org/2012/03/15-svg-irc#T21-07-21">Pre-TPAC F2F Day 1</a>.
- </p>
- <p>
- Purpose: Allows aligning of different sized glyphs along a baseline other than alphabetic.
- </p>
- <p>
- Owner: Chris.
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Clarify the stretch method for textpath.
- </p>
- <p>
- Resolution: We will clarify method=stretch on textPath elements.
- </p>
- <p>
- <a href="http://www.w3.org/2011/11/17-svg-irc#T22-23-10">Conference call 2011-11-17</a>.
- </p>
- <p>
- Purpose: Better definition of how glyphs should be stretched.
- </p>
- <p>
- Owner: Cameron.
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Have a way to specify flip-invariant text.
- </p>
- <p>
- Resolution: SVG2 will have a way to specify flip-invariant text.
- </p>
- <p>
- <a href="http://www.w3.org/2011/11/17-svg-irc#T22-26-26">Conference call 2011-11-17</a>.
- </p>
- <p>
- Purpose: Keep text readable if image flipped.
- </p>
- <p>
- Owner: Doug.
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Allow transforms on tspan.
- </p>
- <p>
- Resolution: SVG2 will allow transforms on tspan.
- </p>
- <p>
- <a href="http://www.w3.org/2011/12/01-svg-irc#T21-02-34">Conferene call 2011-12-01</a>.
- </p>
- <p>
- Purpose: Align with other elements such as <a> which already allow transforms.
- </p>
- <p>
- Owner: Cameron.
- </p>
+ <p>SVG2 Requirement: Require automatic text wrapping in arbitrary shapes compatible with CSS.</p>
+ <p>Resolution: SVG2 will require automatic textwrapping compatible with CSS.</p>
+ <p><a href="http://www.w3.org/2011/11/17-svg-irc#T22-04-11">Conference call 2012-11-17</a>.</p>
+ <p>Purpose: Text in flow charts, etc.</p>
+ <p>Owner: Tav.</p>
</div>
<div class="annotation">
- <p>
- SVG2 Requirement: Have a DOM method to convert a <text> element to outline path data.
- </p>
- <p>
- Resolution: Add a DOM method to convert a <text> element to outline path data and possible migrate to fx.
- </p>
- <p>
- <a href="http://www.w3.org/2012/01/13-svg-irc#T05-07-07">Sydney F2F day 4</a>.
- </p>
- <p>
- Purpose: Allow manipulation of text as a path (while still keeping it as text).
- </p>
- <p>
- Owner: Cameron.
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search.
- </p>
- <p>
- Resolution: SVG 2 will include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search.
- </p>
- <p>
- <a href="http://www.w3.org/2012/02/02-svg-minutes.html#action05">Conference call 2012-02-02</a>.
- </p>
- <p>
- Purpose: Include more clear SVG Tiny 1.2 text, no functional change.
- </p>
- <p>
- Owner: Chris (Action-3236).
- </p>
-</div>
-
-<div class="annotation">
- <p>
- SVG2 Requirement: Use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG .
- </p>
- <p>
- Resolution: SVG2 will use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG.
- </p>
- <p>
- <a href="http://www.w3.org/2011/07/29-svg-minutes.html#item08">Seattle 2011 F2F Day 3</a>.
- </p>
- <p>
- Purpose: Align with CSS3.
- </p>
- <p>
- Owner: Cameron.
- </p>
+ <p>SVG2 Requirement: Support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties</p>
+ <p>Resolution: SVG2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties.</p>
+ <p><a href="http://www.w3.org/2012/03/15-svg-irc#T21-07-21">Pre-TPAC F2F Day 1</a>.</p>
+ <p>Purpose: Allows aligning of different sized glyphs along a baseline other than alphabetic.</p>
+ <p>Owner: Chris.</p>
</div>
<div class="annotation">
- <p>
- SVG2 Requirement: Add text-overflow.
- </p>
- <p>
- Resolution: We will add text-overflow in SVG2.
- </p>
- <p>
- <a href="http://www.w3.org/2011/03/03-svg-minutes.html#item04">Conference call 2011-03-03</a>.
- </p>
- <p>
- Purpose: Align with CSS. Indicate that not all text is shown.
- </p>
- <p>
- Owner: Erik.
- </p>
+ <p>SVG2 Requirement: Clarify the stretch method for textpath.</p>
+ <p>Resolution: We will clarify method=stretch on textPath elements.</p>
+ <p><a href="http://www.w3.org/2011/11/17-svg-irc#T22-23-10">Conference call 2011-11-17</a>.</p>
+ <p>Purpose: Better definition of how glyphs should be stretched.</p>
+ <p>Owner: Cameron.</p>
</div>
<div class="annotation">
- <p>
- SVG2 Requirement: Remove the restriction of tref pointing to only an SVG document fragment.
- </p>
- <p>
- Resolution: We agree to remove the restriction of tref pointing to only an SVG document fragment.
- </p>
- <p>
- <a href="http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/att-0094/26-svg-minutes-last-topic.html#item01">Mountain View F2F 2009 Day 1</a>.
- </p>
- <p>
- Purpose: Allow easier text substitution.
- </p>
- <p>
- Owner: Cameron (Action-3130).
- </p>
+ <p>SVG2 Requirement: Have a way to specify flip-invariant text.</p>
+ <p>Resolution: SVG2 will have a way to specify flip-invariant text.</p>
+ <p><a href="http://www.w3.org/2011/11/17-svg-irc#T22-26-26">Conference call 2011-11-17</a>.</p>
+ <p>Purpose: Keep text readable if image flipped.</p>
+ <p>Owner: Doug.</p>
</div>
<div class="annotation">
- <p>
- SVG2 Requirement: Deprecate baseline-shift and use vertical-align instead
- </p>
- <p>
- Resolution: SVG 2 will deprecate baseline-shift and use vertical-align
- <em>(although we will not actually deprecate baseline-shift, but incorporate
- the vertical-align shorthand and all the baseline properties that css3-linebox
- defines)</em>
- </p>
- <p>
- <a href="http://www.w3.org/2012/01/13-svg-irc#T03-24-06">Sydney F2F 2012 Day 4</a>.
- </p>
- <p>
- Purpose: To align with CSS.
- </p>
- <p>
- Owner: Cameron (ACTION-3281)
- </p>
+ <p>SVG2 Requirement: Allow transforms on tspan.</p>
+ <p>Resolution: SVG2 will allow transforms on tspan.</p>
+ <p><a href="http://www.w3.org/2011/12/01-svg-irc#T21-02-34">Conferene call 2011-12-01</a>.</p>
+ <p>Purpose: Align with other elements such as <a> which already allow transforms.</p>
+ <p>Owner: Cameron.</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Have a DOM method to convert a <text> element to outline path data.</p>
+ <p>Resolution: Add a DOM method to convert a <text> element to outline path data and possible migrate to fx.</p>
+ <p><a href="http://www.w3.org/2012/01/13-svg-irc#T05-07-07">Sydney F2F day 4</a>.</p>
+ <p>Purpose: Allow manipulation of text as a path (while still keeping it as text).</p>
+ <p>Owner: Cameron.</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search.</p>
+ <p>Resolution: SVG 2 will include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search.</p>
+ <p><a href="http://www.w3.org/2012/02/02-svg-minutes.html#action05">Conference call 2012-02-02</a>.</p>
+ <p>Purpose: Include more clear SVG Tiny 1.2 text, no functional change.</p>
+ <p>Owner: Chris (Action-3236).</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG.</p>
+ <p>Resolution: SVG2 will use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG.</p>
+ <p><a href="http://www.w3.org/2011/07/29-svg-minutes.html#item08">Seattle 2011 F2F Day 3</a>.</p>
+ <p>Purpose: Align with CSS3.</p>
+ <p>Owner: Cameron.</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Add text-overflow.</p>
+ <p>Resolution: We will add text-overflow in SVG2.</p>
+ <p><a href="http://www.w3.org/2011/03/03-svg-minutes.html#item04">Conference call 2011-03-03</a>.</p>
+ <p>Purpose: Align with CSS. Indicate that not all text is shown.</p>
+ <p>Owner: Erik.</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Remove the restriction of tref pointing to only an SVG document fragment.</p>
+ <p>Resolution: We agree to remove the restriction of tref pointing to only an SVG document fragment.</p>
+ <p><a href="http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/att-0094/26-svg-minutes-last-topic.html#item01">Mountain View F2F 2009 Day 1</a>.</p>
+ <p> Purpose: Allow easier text substitution.</p>
+ <p>Owner: Cameron (Action-3130).</p>
+</div>
+
+<div class="annotation">
+ <p>SVG2 Requirement: Deprecate baseline-shift and use vertical-align instead</p>
+ <p>Resolution: SVG 2 will deprecate baseline-shift and use vertical-align
+ <em>(although we will not actually deprecate baseline-shift, but incorporate
+ the vertical-align shorthand and all the baseline properties that css3-linebox
+ defines)</em></p>
+ <p><a href="http://www.w3.org/2012/01/13-svg-irc#T03-24-06">Sydney F2F 2012 Day 4</a>.</p>
+ <p>Purpose: To align with CSS.</p>
+ <p>Owner: Cameron (ACTION-3281)</p>
</div>
<h2 id="Introduction">Introduction</h2>
@@ -316,186 +206,206 @@
in other cases a number) along with drawing instructions for rendering that
particular glyph.</p>
- <p>In many cases, there is a one-to-one mapping of Unicode
- characters (i.e., Unicode code points) to glyphs in a font. For
- example, it is common for a font designed for Latin languages
- (where the term <em>Latin</em> is used for European languages
- such as English with alphabets similar to and/or derivative to
- the Latin language) to contain a single glyph for each of the
- standard ASCII characters (i.e., A-to-Z, a-to-z, 0-to-9, plus
- the various punctuation characters found in ASCII). Thus, in
- most situations, the string "XML", which consists of three
- Unicode characters, would be rendered by the three glyphs
- corresponding to "X", "M" and "L", respectively.</p>
- <p>In various other cases, however, there is not a strict
- one-to-one mapping of Unicode characters to glyphs. Some of the
- circumstances when the mapping is not one-to-one:</p>
- <ul>
- <li>Ligatures - For best looking typesetting, it is often
- desirable that particular sequences of characters are
- rendered as a single glyph. An example is the word "office".
- Many fonts will define an "ffi" ligature. When the word
- "office" is rendered, sometimes the user agent will render
- the glyph for the "ffi" ligature instead of rendering
- distinct glyphs (i.e., "f", "f" and "i") for each of the
- three characters. Thus, for ligatures, multiple Unicode
- characters map to a single glyph. (Note that for proper
- rendering of some languages, ligatures are required for
- certain character combinations.)</li>
- <li>Composite characters - In various situations, commonly
- used adornments such as diacritical marks will be stored once
- in a font as a particular glyph and then composed with one or
- more other glyphs to result in the desired character. For
- example, it is possible that a font engine might render the
- <span class="code-fragment">é</span> character by
- first rendering the glyph for <span
- class="code-fragment">e</span> and then rendering the glyph
- for <span class="code-fragment">´</span> (the accent
- mark) such that the accent mark will appear over the <span
- class="code-fragment">e</span>. In this situation, a single
- Unicode character maps to multiple glyphs.</li>
- <li>Glyph substitution - Some typography systems examine the
- nature of the textual content and utilize different glyphs in
- different circumstances. For example, in Arabic, the same
- Unicode character might render as any of four different
- glyphs, depending on such factors as whether the character
- appears at the start, the end or the middle of a sequence of
- cursively joined characters. Different glyphs might be used
- for a punctuation character depending on
- inline-progression-direction (e.g., horizontal vs. vertical).
- In these situations, a single Unicode character might map to
- one of several alternative glyphs.</li>
- <li>In some languages, particular sequences of characters
- will be converted into multiple glyphs such that parts of a
- particular character are in one glyph and the remainder of
- that character is in another glyph.</li>
- <li>Alternative glyph specification - SVG contains a facility
- for the author to explicitly specify that a particular
- sequence of Unicode characters is to be rendered using a
- particular glyph. (See <a
- href="text.html#AlternateGlyphs">Alternate glyphs</a>.) When
- this facility is used, multiple Unicode characters map to a
- single glyph.</li>
- </ul>
- <p>In many situations, the algorithms for mapping from
- characters to glyphs are system-dependent, resulting in the
- possibility that the rendering of text might be (usually
- slightly) different when viewed in different user environments.
- If the author of SVG content requires precise selection of
- fonts and glyphs, then the recommendation is that the necessary
- fonts (potentially subsetted to include only the glyphs needed
- for the given document) be available either as <a
- href="fonts.html#SVGFonts">SVG fonts</a> embedded within the
- SVG content or as <a
- href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#q1">WebFonts</a>
- ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.1)
- posted at the same Web location as the SVG content.</p>
- <p>Throughout this chapter, the term <em>character</em> shall be equivalent to the
- definition of a character in XML [<a
- href="http://www.w3.org/TR/2008/REC-xml-20081126/">XML10</a>].</p>
+<p>In many cases, there is a one-to-one mapping of Unicode
+characters (i.e., Unicode code points) to glyphs in a font. For
+example, it is common for a font designed for Latin languages
+(where the term <em>Latin</em> is used for European languages
+such as English with alphabets similar to and/or derivative to
+the Latin language) to contain a single glyph for each of the
+standard ASCII characters (i.e., A-to-Z, a-to-z, 0-to-9, plus
+the various punctuation characters found in ASCII). Thus, in
+most situations, the string "XML", which consists of three
+Unicode characters, would be rendered by the three glyphs
+corresponding to "X", "M" and "L", respectively.</p>
+
+<p>In various other cases, however, there is not a strict
+one-to-one mapping of Unicode characters to glyphs. Some of the
+circumstances when the mapping is not one-to-one:</p>
+
+<ul>
+ <li>Ligatures - For best looking typesetting, it is often
+ desirable that particular sequences of characters are
+ rendered as a single glyph. An example is the word "office".
+ Many fonts will define an "ffi" ligature. When the word
+ "office" is rendered, sometimes the user agent will render
+ the glyph for the "ffi" ligature instead of rendering
+ distinct glyphs (i.e., "f", "f" and "i") for each of the
+ three characters. Thus, for ligatures, multiple Unicode
+ characters map to a single glyph. (Note that for proper
+ rendering of some languages, ligatures are required for
+ certain character combinations.)</li>
+
+ <li>Composite characters - In various situations, commonly
+ used adornments such as diacritical marks will be stored once
+ in a font as a particular glyph and then composed with one or
+ more other glyphs to result in the desired character. For
+ example, it is possible that a font engine might render the
+ <span class="code-fragment">é</span> character by
+ first rendering the glyph for <span
+ class="code-fragment">e</span> and then rendering the glyph
+ for <span class="code-fragment">´</span> (the accent
+ mark) such that the accent mark will appear over the <span
+ class="code-fragment">e</span>. In this situation, a single
+ Unicode character maps to multiple glyphs.</li>
+
+ <li>Glyph substitution - Some typography systems examine the
+ nature of the textual content and utilize different glyphs in
+ different circumstances. For example, in Arabic, the same
+ Unicode character might render as any of four different
+ glyphs, depending on such factors as whether the character
+ appears at the start, the end or the middle of a sequence of
+ cursively joined characters. Different glyphs might be used
+ for a punctuation character depending on
+ inline-progression-direction (e.g., horizontal vs. vertical).
+ In these situations, a single Unicode character might map to
+ one of several alternative glyphs.</li>
+
+ <li>In some languages, particular sequences of characters
+ will be converted into multiple glyphs such that parts of a
+ particular character are in one glyph and the remainder of
+ that character is in another glyph.</li>
+
+ <li>Alternative glyph specification - SVG contains a facility
+ for the author to explicitly specify that a particular
+ sequence of Unicode characters is to be rendered using a
+ particular glyph. (See <a
+ href="text.html#AlternateGlyphs">Alternate glyphs</a>.) When
+ this facility is used, multiple Unicode characters map to a
+ single glyph.</li>
+</ul>
+
+<p>In many situations, the algorithms for mapping from
+characters to glyphs are system-dependent, resulting in the
+possibility that the rendering of text might be (usually
+slightly) different when viewed in different user environments.
+If the author of SVG content requires precise selection of
+fonts and glyphs, then the recommendation is that the necessary
+fonts (potentially subsetted to include only the glyphs needed
+for the given document) be available either as <a
+href="fonts.html#SVGFonts">SVG fonts</a> embedded within the
+SVG content or as <a
+href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#q1">WebFonts</a>
+([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.1)
+posted at the same Web location as the SVG content.</p>
+
+<p>Throughout this chapter, the term <em>character</em> shall be equivalent to the
+definition of a character in XML [<a
+href="http://www.w3.org/TR/2008/REC-xml-20081126/">XML10</a>].</p>
<h2 id="FontsTablesBaselines">Fonts, font tables and baselines</h2>
- <p>A font consists of a collection of glyphs together with the
- information (the font tables) necessary to use those glyphs to
- present characters on some medium. The combination of the
- collection of glyphs and the font tables is called the <em>font
- data</em>. The font tables include the information necessary to
- map characters to glyphs, to determine the size of glyph areas
- and to position the glyph area. Each font table consists of one
- or more font characteristics, such as the font-weight and
- font-style.</p>
- <p>The geometric font characteristics are expressed in a
- coordinate system based on the EM box. (The EM is a relative
- measure of the height of the glyphs in the font; see <a
- href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#emsq">Coordinate units on the em square</a>;
- in [<a href="refs.html#ref-CSS2">CSS2</a>], section 15.4.3.)
- The box 1 EM high and 1 EM wide is called the
- <em>design space</em>. This space is given a geometric
- coordinates by sub-dividing the EM into a number of <em>units
- per em</em>.</p>
- <p>Note: Units per em is a font characteristic. A typical value
- for units per em is 1000 or 2048.</p>
- <p>The coordinate space of the EM box is called the <em>design
- space coordinate system</em>. For scalable fonts, the curves
- and lines that are used to draw a glyph are represented using
- this coordinate system.</p>
- <p>Note: Most often, the (0,0) point in this coordinate system
- is positioned on the left edge of the EM box, but not at the
- bottom left corner. The Y coordinate of the bottom of a roman
- capital letter is usually zero. And the descenders on lowercase
- roman letters have negative coordinate values.</p>
- <p>SVG assumes that the font tables will provide at least three
- font characteristics: an ascent, a descent and a set of
- baseline-tables. The ascent is the distance to the top of the
- EM box from the (0,0) point of the font; the descent is the
- distance to the bottom of the EM box from the (0.0) point of
- the font. The baseline-table is explained below.</p>
- <p>Note: Within an OpenType font, for horizontal writing-modes,
- the ascent and descent are given by the sTypoAscender and
- sTypoDescender entries in the OS/2 table. For vertical
- writing-modes, the descent (the distance, in this case from the
- (0,0) point to the left edge of the glyph) is normally zero
- because the (0,0) point is on the left edge. The ascent for
- vertical writing-modes is either 1 em or is specified by the
- ideographic top baseline value in the OpenType Base table for
- vertical writing-modes.</p>
- <p>In horizontal writing-modes, the glyphs of a given script
- are positioned so that a particular point on each glyph, the
- <em><a
- href="text.html#AlignmentPoint">alignment-point</a></em>, is
- aligned with the alignment-points of the other glyphs in that
- script. The glyphs of different scripts, for example, Western,
- Northern Indic and Far-Eastern scripts, are typically aligned
- at different points on the glyph. For example, Western glyphs
- are aligned on the bottoms of the capital letters, northern
- indic glyphs are aligned at the top of a horizontal stroke near
- the top of the glyphs and far-eastern glyphs are aligned either
- at the bottom or center of the glyph. Within a script and
- within a line of text having a single font-size, the sequence
- of alignment-points defines, in the inline-
- progression-direction, a geometric line called a
- <em>baseline</em>. Western and most other alphabetic and
- syllabic glyphs are aligned to an "alphabetic" baseline, the
- northern indic glyphs are aligned to a "hanging" baseline and
- the far-eastern glyphs are aligned to an "ideographic"
- baseline.</p>
- <p>A <em>baseline-table</em> specifies the position of one or
- more baselines in the design space coordinate system. The
- function of the baseline table is to facilitate the alignment
- of different scripts with respect to each other when they are
- mixed on the same text line. Because the desired relative
- alignments may depend on which script is dominant in a line (or
- block), there may be a different baseline table for each
- script. In addition, different alignment positions are needed
- for horizontal and vertical writing modes. Therefore, the font
- may have a set of baseline tables: typically, one or more for
- horizontal writing-modes and zero or more for vertical
- writing-modes.</p>
- <p>Note: Some fonts may not have values for the baseline
- tables. Heuristics are suggested for approximating the baseline
- tables when a given font does not supply baseline tables.</p>
- <p>SVG further assumes that for each glyph in the font data for
- a font, there are two width values, two alignment-baselines and
- two alignment-points, one each for horizontal writing-modes and
- the other for vertical writing-modes. (Even though it is
- specified as a width, for vertical writing-modes the width is
- used in the vertical direction.) The script to which a glyph
- belongs determines an alignment-baseline to which the glyph is
- to be aligned. The <a
- href="text.html#InlineProgressionDirection">inline-progression-direction</a>
- position of the alignment-point is on the start-edge of the
- glyph.</p>
- <p>Properties related to baselines are described below under <a
- href="text.html#BaselineAlignmentProperties">Baseline alignment
- properties</a>.</p>
- <p>In addition to the font characteristics required above, a
- font may also supply substitution and positioning tables that
- can be used by a formatter to re-order, combine and position a
- sequence of glyphs to make one or more composite glyphs. The
- combination may be as simple as a ligature, or as complex as an
- indic syllable which combines, usually with some re-ordering,
- multiple consonants and vowel glyphs.</p>
+<p>A font consists of a collection of glyphs together with the
+information (the font tables) necessary to use those glyphs to
+present characters on some medium. The combination of the
+collection of glyphs and the font tables is called the <em>font
+data</em>. The font tables include the information necessary to
+map characters to glyphs, to determine the size of glyph areas
+and to position the glyph area. Each font table consists of one
+or more font characteristics, such as the font-weight and
+font-style.</p>
+
+<p>The geometric font characteristics are expressed in a
+coordinate system based on the EM box. (The EM is a relative
+measure of the height of the glyphs in the font; see <a
+href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#emsq">Coordinate units on the em square</a>;
+in [<a href="refs.html#ref-CSS2">CSS2</a>], section 15.4.3.)
+The box 1 EM high and 1 EM wide is called the
+<em>design space</em>. This space is given a geometric
+coordinates by sub-dividing the EM into a number of <em>units
+per em</em>.</p>
+
+<p>Note: Units per em is a font characteristic. A typical value
+for units per em is 1000 or 2048.</p>
+
+<p>The coordinate space of the EM box is called the <em>design
+space coordinate system</em>. For scalable fonts, the curves
+and lines that are used to draw a glyph are represented using
+this coordinate system.</p>
+
+<p>Note: Most often, the (0,0) point in this coordinate system
+is positioned on the left edge of the EM box, but not at the
+bottom left corner. The Y coordinate of the bottom of a roman
+capital letter is usually zero. And the descenders on lowercase
+roman letters have negative coordinate values.</p>
+
+<p>SVG assumes that the font tables will provide at least three
+font characteristics: an ascent, a descent and a set of
+baseline-tables. The ascent is the distance to the top of the
+EM box from the (0,0) point of the font; the descent is the
+distance to the bottom of the EM box from the (0.0) point of
+the font. The baseline-table is explained below.</p>
+
+<p>Note: Within an OpenType font, for horizontal writing-modes,
+the ascent and descent are given by the sTypoAscender and
+sTypoDescender entries in the OS/2 table. For vertical
+writing-modes, the descent (the distance, in this case from the
+(0,0) point to the left edge of the glyph) is normally zero
+because the (0,0) point is on the left edge. The ascent for
+vertical writing-modes is either 1 em or is specified by the
+ideographic top baseline value in the OpenType Base table for
+vertical writing-modes.</p>
+
+<p>In horizontal writing-modes, the glyphs of a given script
+are positioned so that a particular point on each glyph, the
+<em><a
+href="text.html#AlignmentPoint">alignment-point</a></em>, is
+aligned with the alignment-points of the other glyphs in that
+script. The glyphs of different scripts, for example, Western,
+Northern Indic and Far-Eastern scripts, are typically aligned
+at different points on the glyph. For example, Western glyphs
+are aligned on the bottoms of the capital letters, northern
+indic glyphs are aligned at the top of a horizontal stroke near
+the top of the glyphs and far-eastern glyphs are aligned either
+at the bottom or center of the glyph. Within a script and
+within a line of text having a single font-size, the sequence
+of alignment-points defines, in the inline-
+progression-direction, a geometric line called a
+<em>baseline</em>. Western and most other alphabetic and
+syllabic glyphs are aligned to an "alphabetic" baseline, the
+northern indic glyphs are aligned to a "hanging" baseline and
+the far-eastern glyphs are aligned to an "ideographic"
+baseline.</p>
+
+<p>A <em>baseline-table</em> specifies the position of one or
+more baselines in the design space coordinate system. The
+function of the baseline table is to facilitate the alignment
+of different scripts with respect to each other when they are
+mixed on the same text line. Because the desired relative
+alignments may depend on which script is dominant in a line (or
+block), there may be a different baseline table for each
+script. In addition, different alignment positions are needed
+for horizontal and vertical writing modes. Therefore, the font
+may have a set of baseline tables: typically, one or more for
+horizontal writing-modes and zero or more for vertical
+writing-modes.</p>
+
+<p>Note: Some fonts may not have values for the baseline
+tables. Heuristics are suggested for approximating the baseline
+tables when a given font does not supply baseline tables.</p>
+
+<p>SVG further assumes that for each glyph in the font data for
+a font, there are two width values, two alignment-baselines and
+two alignment-points, one each for horizontal writing-modes and
+the other for vertical writing-modes. (Even though it is
+specified as a width, for vertical writing-modes the width is
+used in the vertical direction.) The script to which a glyph
+belongs determines an alignment-baseline to which the glyph is
+to be aligned. The <a
+href="text.html#InlineProgressionDirection">inline-progression-direction</a>
+position of the alignment-point is on the start-edge of the
+glyph.</p>
+
+<p>Properties related to baselines are described below under <a
+href="text.html#BaselineAlignmentProperties">Baseline alignment
+properties</a>.</p>
+
+<p>In addition to the font characteristics required above, a
+font may also supply substitution and positioning tables that
+can be used by a formatter to re-order, combine and position a
+sequence of glyphs to make one or more composite glyphs. The
+combination may be as simple as a ligature, or as complex as an
+indic syllable which combines, usually with some re-ordering,
+multiple consonants and vowel glyphs.</p>
<h2 id="TextElement">The <span class="element-name">'text'</span> element</h2>
@@ -963,290 +873,296 @@
yes.</span></dd>
</dl>
</div>
- <p>The <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and
- <a>'rotate'</a> on the <a>'tspan'</a> element are useful in
- high-end typography scenarios where individual glyphs require
- exact placement. These attributes are useful for minor
- positioning adjustments between characters or for major
- positioning adjustments, such as moving the <a
- href="text.html#CurrentTextPosition">current text position</a>
- to a new location to achieve the visual effect of a new line of
- text. Multi-line <a>'text'</a> elements are possible by
- defining different <a>'tspan'</a>
- elements for each line of text, with attributes <a>'x'</a>, <a>'y'</a>,
- <a>'dx'</a> and/or <a>'dy'</a> defining the position of each
- <a>'tspan'</a>. (An advantage of
- such an approach is that users will be able to perform
- multi-line <a href="text.html#TextSelection">text
- selection</a>.)</p>
- <p>In situations where micro-level positioning adjustment are
- necessary for advanced typographic control, the SVG content
- designer needs to ensure that the necessary font will be
- available for all viewers of the document (e.g., package up the
- necessary font data in the form of an SVG font or an
- alternative WebFont
- format which is stored at the same Web site as the SVG content)
- and that the viewing software will process the font in the
- expected way (the capabilities, characteristics and font layout
- mechanisms vary greatly from system to system). If the SVG
- content contains <a>'x'</a>, <a>'y'</a>, <a>'dx'</a> or
- <a>'dy'</a> attribute values which are
- meant to correspond to a particular font processed by a
- particular set of viewing software and either of these
- requirements is not met, then the text might display with poor
- quality.</p>
- <p>The following additional rules apply to attributes <a>'x'</a>,
- <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a> when they
- contain a list of numbers:</p>
- <ul>
- <li>When a single XML character maps to a single glyph - In
- this case, the <span class="code-fragment">i</span>-th value for the
- <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
- attributes is applied to the glyph that corresponds to the <span
- class="code-fragment">i</span>-th character.</li>
- <li>When a single XML character maps to multiple glyphs (e.g., when an
- accent glyph is placed on top of a base glyph) - In this case, the
- <span class="code-fragment">i</span>-th value for the <a>'x'</a>,
- <a>'y'</a>, <a>'dx'</a> and <a>'dy'</a> values are applied (i.e., the
- <a href="text.html#CurrentTextPosition">current text position</a> is
- adjusted) before rendering the first glyph. The rotation transformation
- corresponding to the <span class="code-fragment">i</span>-th <a>'rotate'</a>
- value is applied to the glyphs and to the inter-glyph advance values
- corresponding to this character on a group basis (i.e., the rotation
- value creates a temporary new rotated coordinate system, and the glyphs
- orresponding to the character are rendered into this rotated coordinate
- system).</li>
- <li>When multiple XML characters map to a single
- glyph (e.g., when a ligature is used) - Suppose
- that the <span class="code-fragment">i</span>-th
- and <span class="code-fragment">(i+1)</span>-th XML
- characters map to a single glyph. In this case, the <span
- class="code-fragment">i</span>-th value for the <a>'x'</a>,
- <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
- attributes all apply when rendering the glyph. The <span
- class="code-fragment">(i+1)</span>-th values, however, for
- <a>'x'</a>, <a>'y'</a> and <a>'rotate'</a> are ignored (exception:
- the final <a>'rotate'</a> value in the list would still apply to
- subsequent characters), whereas the <a>'dx'</a> and <a>'dy'</a>
- are applied to the subsequent XML character (i.e., the <span
- class="code-fragment">(i+2)</span>-th character), if one exists,
- by translating the <a href="text.html#CurrentTextPosition">current
- text position</a> by the given amounts before rendering the first
- glyph associated with that character.</li>
- <li>When there is a many-to-many mapping of characters to
- glyphs (e.g., when three characters map to two glyphs, such as
- when the first glyph expresses the first character and half
- of the second character, and the second glyph expresses the
- other half of the second character plus the third character)
- - Suppose that the <span class="code-fragment">i</span>-th,
- <span class="code-fragment">(i+1)</span>-th and <span
- class="code-fragment">(i+2)</span>-th XML characters map to two
- glyphs. In this case, the <span class="code-fragment">i</span>-th
- value for the <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>
- and <a>'dy'</a> values are applied (i.e., the <a
- href="text.html#CurrentTextPosition">current text
- position</a> is adjusted) before rendering the first glyph.
- The rotation transformation corresponding to the <span
- class="code-fragment">i</span>-th <a>'rotate'</a> value is
- applied to both the two glyphs and the glyph advance values
- for the first glyph on a group basis (i.e., the rotation value
- creates a temporary new rotated coordinate system, and the
- two glyphs are rendered into the temporary rotated coordinate
- system). The <span class="code-fragment">(i+1)</span>-th and
- <span class="code-fragment">(i+2)</span>-th values, however,
- for the <a>'x'</a>, <a>'y'</a> and <a>'rotate'</a> attributes
- are not applied (exception: the final <a>'rotate'</a> value in
- the list would still apply to subsequent characters), whereas
- the <span class="code-fragment">(i+1)</span>-th and <span
- class="code-fragment">(i+2)</span>-th values for the <a>'dx'</a>
- and <a>'dy'</a> attributes are applied to the subsequent XML
- character (i.e., the <span class="code-fragment">(i+3)</span>-th
- character), if one exists, by translating the <a
- href="text.html#CurrentTextPosition">current text position</a> by
- the given amounts before rendering the first glyph associated with
- that character.</li>
- <li>Relationship to <a href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>
- - As described below in the discussion on
- <a href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>,
- text is laid out in a two-step process, where any
- bidirectional text is first re-ordered into a left-to-right
- string, and then text layout occurs with the re-ordered
- text string. Whenever the character data within a <a>'tspan'</a> element is re-ordered,
- the corresponding elements within the <a>'x'</a>, <a>'y'</a>,
- <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a> are also re-ordered
- to maintain the correspondence. For example, suppose that you have
- the following <a>'tspan'</a> element:
+
+<p>The <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and
+<a>'rotate'</a> on the <a>'tspan'</a> element are useful in
+high-end typography scenarios where individual glyphs require
+exact placement. These attributes are useful for minor
+positioning adjustments between characters or for major
+positioning adjustments, such as moving the <a
+href="text.html#CurrentTextPosition">current text position</a>
+to a new location to achieve the visual effect of a new line of
+text. Multi-line <a>'text'</a> elements are possible by
+defining different <a>'tspan'</a>
+elements for each line of text, with attributes <a>'x'</a>, <a>'y'</a>,
+<a>'dx'</a> and/or <a>'dy'</a> defining the position of each
+<a>'tspan'</a>. (An advantage of
+such an approach is that users will be able to perform
+multi-line <a href="text.html#TextSelection">text
+selection</a>.)</p>
+
+<p>In situations where micro-level positioning adjustment are
+necessary for advanced typographic control, the SVG content
+designer needs to ensure that the necessary font will be
+available for all viewers of the document (e.g., package up the
+necessary font data in the form of an SVG font or an
+alternative WebFont
+format which is stored at the same Web site as the SVG content)
+and that the viewing software will process the font in the
+expected way (the capabilities, characteristics and font layout
+mechanisms vary greatly from system to system). If the SVG
+content contains <a>'x'</a>, <a>'y'</a>, <a>'dx'</a> or
+<a>'dy'</a> attribute values which are
+meant to correspond to a particular font processed by a
+particular set of viewing software and either of these
+requirements is not met, then the text might display with poor
+quality.</p>
+
+<p>The following additional rules apply to attributes <a>'x'</a>,
+<a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a> when they
+contain a list of numbers:</p>
+
+<ul>
+ <li>When a single XML character maps to a single glyph - In
+ this case, the <span class="code-fragment">i</span>-th value for the
+ <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
+ attributes is applied to the glyph that corresponds to the <span
+ class="code-fragment">i</span>-th character.</li>
+
+ <li>When a single XML character maps to multiple glyphs (e.g., when an
+ accent glyph is placed on top of a base glyph) - In this case, the
+ <span class="code-fragment">i</span>-th value for the <a>'x'</a>,
+ <a>'y'</a>, <a>'dx'</a> and <a>'dy'</a> values are applied (i.e., the
+ <a href="text.html#CurrentTextPosition">current text position</a> is
+ adjusted) before rendering the first glyph. The rotation transformation
+ corresponding to the <span class="code-fragment">i</span>-th <a>'rotate'</a>
+ value is applied to the glyphs and to the inter-glyph advance values
+ corresponding to this character on a group basis (i.e., the rotation
+ value creates a temporary new rotated coordinate system, and the glyphs
+ orresponding to the character are rendered into this rotated coordinate
+ system).</li>
+
+ <li>When multiple XML characters map to a single
+ glyph (e.g., when a ligature is used) - Suppose
+ that the <span class="code-fragment">i</span>-th
+ and <span class="code-fragment">(i+1)</span>-th XML
+ characters map to a single glyph. In this case, the <span
+ class="code-fragment">i</span>-th value for the <a>'x'</a>,
+ <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
+ attributes all apply when rendering the glyph. The <span
+ class="code-fragment">(i+1)</span>-th values, however, for
+ <a>'x'</a>, <a>'y'</a> and <a>'rotate'</a> are ignored (exception:
+ the final <a>'rotate'</a> value in the list would still apply to
+ subsequent characters), whereas the <a>'dx'</a> and <a>'dy'</a>
+ are applied to the subsequent XML character (i.e., the <span
+ class="code-fragment">(i+2)</span>-th character), if one exists,
+ by translating the <a href="text.html#CurrentTextPosition">current
+ text position</a> by the given amounts before rendering the first
+ glyph associated with that character.</li>
+
+ <li>When there is a many-to-many mapping of characters to
+ glyphs (e.g., when three characters map to two glyphs, such as
+ when the first glyph expresses the first character and half
+ of the second character, and the second glyph expresses the
+ other half of the second character plus the third character)
+ - Suppose that the <span class="code-fragment">i</span>-th,
+ <span class="code-fragment">(i+1)</span>-th and <span
+ class="code-fragment">(i+2)</span>-th XML characters map to two
+ glyphs. In this case, the <span class="code-fragment">i</span>-th
+ value for the <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>
+ and <a>'dy'</a> values are applied (i.e., the <a
+ href="text.html#CurrentTextPosition">current text
+ position</a> is adjusted) before rendering the first glyph.
+ The rotation transformation corresponding to the <span
+ class="code-fragment">i</span>-th <a>'rotate'</a> value is
+ applied to both the two glyphs and the glyph advance values
+ for the first glyph on a group basis (i.e., the rotation value
+ creates a temporary new rotated coordinate system, and the
+ two glyphs are rendered into the temporary rotated coordinate
+ system). The <span class="code-fragment">(i+1)</span>-th and
+ <span class="code-fragment">(i+2)</span>-th values, however,
+ for the <a>'x'</a>, <a>'y'</a> and <a>'rotate'</a> attributes
+ are not applied (exception: the final <a>'rotate'</a> value in
+ the list would still apply to subsequent characters), whereas
+ the <span class="code-fragment">(i+1)</span>-th and <span
+ class="code-fragment">(i+2)</span>-th values for the <a>'dx'</a>
+ and <a>'dy'</a> attributes are applied to the subsequent XML
+ character (i.e., the <span class="code-fragment">(i+3)</span>-th
+ character), if one exists, by translating the <a
+ href="text.html#CurrentTextPosition">current text position</a> by
+ the given amounts before rendering the first glyph associated with
+ that character.</li>
+
+ <li>
+ <p>Relationship to <a href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>
+ - As described below in the discussion on
+ <a href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>,
+ text is laid out in a two-step process, where any
+ bidirectional text is first re-ordered into a left-to-right
+ string, and then text layout occurs with the re-ordered
+ text string. Whenever the character data within a <a>'tspan'</a> element is re-ordered,
+ the corresponding elements within the <a>'x'</a>, <a>'y'</a>,
+ <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a> are also re-ordered
+ to maintain the correspondence. For example, suppose that you have
+ the following <a>'tspan'</a> element:</p>
+
<pre>
<tspan dx="11 12 13 14 15 0 21 22 23 0 31 32 33 34 35 36">Latin and Hebrew</tspan>
</pre>
- and that the word "Hebrew" will be drawn right-to-left. First, the
- character data and the corresponding values in the <a>'dx'</a>
- list will be reordered, such that the text string will be "Latin
- and werbeH" and the list of values for the <a>'dx'</a> attribute
- will be "11 12 13 14 15 0 21 22 23 0 36 35 34 33 32 31". After
- this re-ordering, the glyphs corresponding to the characters will
- be positioned using standard left-to-right layout rules.</li>
- </ul>
- <p>The following examples show basic use of the <a>'tspan'</a> element.</p>
- <p id="ExampleTSpan01"><span class="example-ref">Example tspan01</span> uses a
- <a>'tspan'</a> element to indicate
- that the word "not" is to use a bold font and have red
- fill.</p>
+
+ <p>and that the word "Hebrew" will be drawn right-to-left. First, the
+ character data and the corresponding values in the <a>'dx'</a>
+ list will be reordered, such that the text string will be "Latin
+ and werbeH" and the list of values for the <a>'dx'</a> attribute
+ will be "11 12 13 14 15 0 21 22 23 0 36 35 34 33 32 31". After
+ this re-ordering, the glyphs corresponding to the characters will
+ be positioned using standard left-to-right layout rules.</li>
+</ul>
+
+<p>The following examples show basic use of the <a>'tspan'</a> element.</p>
+
+<p id="ExampleTSpan01"><span class="example-ref">Example tspan01</span> uses a
+<a>'tspan'</a> element to indicate
+that the word "not" is to use a bold font and have red
+fill.</p>
<edit:example href='images/text/tspan01.svg' name='tspan01' description='using tspan to change visual attributes' image='yes' link='yes'/>
- <p id="ExampleTSpan02"><span class="example-ref">Example tspan02</span>
- uses the <a>'dx'</a> and <a>'dy'</a> attributes on the <a>'tspan'</a>
- element to adjust the <a href="text.html#CurrentTextPosition">current text position</a>
- horizontally and vertically for particular text strings within a
- <a>'text'</a> element.</p>
+<p id="ExampleTSpan02"><span class="example-ref">Example tspan02</span>
+uses the <a>'dx'</a> and <a>'dy'</a> attributes on the <a>'tspan'</a>
+element to adjust the <a href="text.html#CurrentTextPosition">current text position</a>
+horizontally and vertically for particular text strings within a
+<a>'text'</a> element.</p>
<edit:example href='images/text/tspan02.svg' name='tspan02' description="using tspan's dx and dy attributes for incremental positioning adjustments" image='yes' link='yes'/>
- <p id="ExampleTSpan03"><span class="example-ref">Example tspan03</span>
- uses the <a>'x'</a> and <a>'y'</a> attributes on the
- <a>'tspan'</a> element to establish a new absolute
- <a href="text.html#CurrentTextPosition">current text position</a> for each
- glyph to be rendered. The example shows two lines of text within a single
- <a>'text'</a> element. Because both lines of text are within the same
- <a>'text'</a> element, the user will be able to select through both lines
- of text and copy the text to the system clipboard in user agents that
- support <a href="text.html#TextSelection">text selection and clipboard operations</a>.</p>
+<p id="ExampleTSpan03"><span class="example-ref">Example tspan03</span>
+uses the <a>'x'</a> and <a>'y'</a> attributes on the
+<a>'tspan'</a> element to establish a new absolute
+<a href="text.html#CurrentTextPosition">current text position</a> for each
+glyph to be rendered. The example shows two lines of text within a single
+<a>'text'</a> element. Because both lines of text are within the same
+<a>'text'</a> element, the user will be able to select through both lines
+of text and copy the text to the system clipboard in user agents that
+support <a href="text.html#TextSelection">text selection and clipboard operations</a>.</p>
<edit:example href='images/text/tspan03.svg' name='tspan03' description="using tspan's x and y attributes for multiline text and precise glyph positioning" image='yes' link='yes'/>
- <p>
- <span class="example-ref">Example tspan04</span> uses the
- <a>'rotate'</a> attribute on the <a>'tspan'</a> element to rotate the
- glyphs to be rendered. This example shows a single text string in a
- <a>'tspan'</a> element that contains more characters than the number
- of values specified in the <a>'rotate'</a> attribute. In this case the
- last value specified in the <a>'rotate'</a> attribute of the
- <a>'tspan'</a> must be applied to the remaining characters in the
- string.
- </p>
+<p><span class="example-ref">Example tspan04</span> uses the
+<a>'rotate'</a> attribute on the <a>'tspan'</a> element to rotate the
+glyphs to be rendered. This example shows a single text string in a
+<a>'tspan'</a> element that contains more characters than the number
+of values specified in the <a>'rotate'</a> attribute. In this case the
+last value specified in the <a>'rotate'</a> attribute of the
+<a>'tspan'</a> must be applied to the remaining characters in the
+string.</p>
<edit:example href='images/text/tspan04.svg' name='tspan04' description="simple rotation of characters in a tspan element" image='yes' link='yes'/>
- <p>
- <span class="example-ref">Example tspan05</span> specifies the
- <a>'rotate'</a> attribute on the <a>'text'</a> element and on all but
- one of the child <a>'tspan'</a> elements to rotate the glyphs to be
- rendered. The example demonstrates the propagation of the
- <a>'rotate'</a> attribute.
- </p>
+<p><span class="example-ref">Example tspan05</span> specifies the
+<a>'rotate'</a> attribute on the <a>'text'</a> element and on all but
+one of the child <a>'tspan'</a> elements to rotate the glyphs to be
+rendered. The example demonstrates the propagation of the
+<a>'rotate'</a> attribute.</p>
<edit:example href='images/text/tspan05.svg' name='tspan05' description="propagation of rotation values to nested tspan elements" image='yes' link='yes'/>
- <p>
- Rotation of red text inside the <a>'text'</a> element:
- </p>
- <ul>
- <li>
- The <a>'rotate'</a> value will rotate the characters in the text
- <em>"Not "</em> by 5, 15, 25 and 35 degrees respectively.
- </li>
- <li>
- A <a>'rotate'</a> value is applied to the space that follows the
- text <em>"Not"</em>, to the space in between the text in the
- "child1" and "child5" <a>'tspan'</a> elements, and to the space
- before the text <em>"rotation"</em>.
- </li>
- <li>
- The next current <a>'rotate'</a> value specified is 45 followed
- by 55. The current <a>'rotate'</a> value in the <a>'text'</a>
- element is incremented as subsequent characters in the text of the
- child <a>'tspan'</a> elements are processed.
- </li>
- <li>
- The next immediate <a>'tspan'</a> element specifies rotate values
- for the text, hence the current <a>'rotate'</a> value will change to
- the next value in the list (but is not used) as each character is
- processed until the last value of 55 degrees is reached.
- </li>
- <li>
- The last <a>'rotate'</a> value of 55 degrees will be applied to all
- the characters in the text <em>"rotation"</em>.
- </li>
- </ul>
- <p>
- Rotation of the orange text inside the "child1" <a>'tspan'</a>
- element:
- </p>
- <ul>
- <li>
- The <a>'rotate'</a> value will rotate the first 4 characters in the
- text <em>"all characters "</em> by -10, -20, -30 and -40
- respectively.
- </li>
- <li>
- The last <a>'rotate'</a> value of -40 becomes the current
- <a>'rotate'</a> value and will be applied to all subsequent
- characters in the <a>'tspan'</a> element and to any child
- <a>'tspan'</a> elements that do not specify <a>'rotate'</a>
- values.
- </li>
- <li>
- The "child4" <a>'tspan'</a> element does not specify any
- <a>'rotate'</a> values and thus uses the current <a>'rotate'</a> of
- its ancestor ("child1" <a>'tspan'</a> element). All the characters
- in the text <em>"text"</em> specified within the "child4"
- <a>'tspan'</a> element will be rotated by -40 degrees.
- </li>
- <li>
- The last <a>'rotate'</a> value of -40 degrees will be applied to all
- the characters in the text <em>"have a"</em>.
- </li>
- <li>
- A <a>'rotate'</a> value is applied to the space in between the text
- in the "child2" and "child4" <a>'tspan'</a> elements, and to the
- space before the text <em>"have a"</em>.
- </li>
- </ul>
- <p>
- Rotation of the yellow text inside the "child2" <a>'tspan'</a>
- element:
- </p>
- <ul>
- <li>
- The <a>'rotate'</a> value will rotate the characters in the (yellow)
- text <em>"in "</em> by 70, 60, and 50 degrees respectively.
- </li>
- <li>
- A <a>'rotate'</a> value is applied to the space that follows the
- text <em>"in"</em>.
- </li>
- <li>
- There are more <a>'rotate'</a> values specified than characters,
- thus the additional <a>'rotate'</a> values will be applied to the
- "child3" <a>'tspan'</a> element which does not specified any
- <a>'rotate'</a> values.
- </li>
- <li>
- The characters in the text <em>"the"</em> specified within the
- "child3" <a>'tspan'</a> element will be rotated 40, 30 and 20
- degrees respectively.
- </li>
- </ul>
- <p>
- Rotation of the blue text inside the "child5" <a>'tspan'</a> element:
- </p>
- <ul>
- <li>
- The <a>'rotate'</a> value will rotate all the characters in text
- <em>"specified"</em> by -10 degrees.
- </li>
- <li>
- Only one <a>'rotate'</a> value is specified and is thus
- applied to all characters in the <a>'tspan'</a> element.
- </li>
- </ul>
- <p>
- The following diagram illustrates how the rotation values propagate to
- <a>'tspan'</a> elements nested withing a <a>'text'</a> element
- </p>
- <img alt="Image that shows propagation of rotation values"
- src="images/text/tspan05-diagram.png" width="528" height="918" />
+<p>Rotation of red text inside the <a>'text'</a> element:</p>
+
+<ul>
+ <li>
+ The <a>'rotate'</a> value will rotate the characters in the text
+ <em>"Not "</em> by 5, 15, 25 and 35 degrees respectively.
+ </li>
+ <li>
+ A <a>'rotate'</a> value is applied to the space that follows the
+ text <em>"Not"</em>, to the space in between the text in the
+ "child1" and "child5" <a>'tspan'</a> elements, and to the space
+ before the text <em>"rotation"</em>.
+ </li>
+ <li>
+ The next current <a>'rotate'</a> value specified is 45 followed
+ by 55. The current <a>'rotate'</a> value in the <a>'text'</a>
+ element is incremented as subsequent characters in the text of the
+ child <a>'tspan'</a> elements are processed.
+ </li>
+ <li>
+ The next immediate <a>'tspan'</a> element specifies rotate values
+ for the text, hence the current <a>'rotate'</a> value will change to
+ the next value in the list (but is not used) as each character is
+ processed until the last value of 55 degrees is reached.
+ </li>
+ <li>
+ The last <a>'rotate'</a> value of 55 degrees will be applied to all
+ the characters in the text <em>"rotation"</em>.
+ </li>
+</ul>
+
+<p>Rotation of the orange text inside the "child1" <a>'tspan'</a>element:</p>
+
+<ul>
+ <li>
+ The <a>'rotate'</a> value will rotate the first 4 characters in the
+ text <em>"all characters "</em> by -10, -20, -30 and -40
+ respectively.
+ </li>
+ <li>
+ The last <a>'rotate'</a> value of -40 becomes the current
+ <a>'rotate'</a> value and will be applied to all subsequent
+ characters in the <a>'tspan'</a> element and to any child
+ <a>'tspan'</a> elements that do not specify <a>'rotate'</a>
+ values.
+ </li>
+ <li>
+ The "child4" <a>'tspan'</a> element does not specify any
+ <a>'rotate'</a> values and thus uses the current <a>'rotate'</a> of
+ its ancestor ("child1" <a>'tspan'</a> element). All the characters
+ in the text <em>"text"</em> specified within the "child4"
+ <a>'tspan'</a> element will be rotated by -40 degrees.
+ </li>
+ <li>
+ The last <a>'rotate'</a> value of -40 degrees will be applied to all
+ the characters in the text <em>"have a"</em>.
+ </li>
+ <li>
+ A <a>'rotate'</a> value is applied to the space in between the text
+ in the "child2" and "child4" <a>'tspan'</a> elements, and to the
+ space before the text <em>"have a"</em>.
+ </li>
+</ul>
+
+<p>Rotation of the yellow text inside the "child2" <a>'tspan'</a>element:</p>
+
+<ul>
+ <li>
+ The <a>'rotate'</a> value will rotate the characters in the (yellow)
+ text <em>"in "</em> by 70, 60, and 50 degrees respectively.
+ </li>
+ <li>
+ A <a>'rotate'</a> value is applied to the space that follows the
+ text <em>"in"</em>.
+ </li>
+ <li>
+ There are more <a>'rotate'</a> values specified than characters,
+ thus the additional <a>'rotate'</a> values will be applied to the
+ "child3" <a>'tspan'</a> element which does not specified any
+ <a>'rotate'</a> values.
+ </li>
+ <li>
+ The characters in the text <em>"the"</em> specified within the
+ "child3" <a>'tspan'</a> element will be rotated 40, 30 and 20
+ degrees respectively.
+ </li>
+</ul>
+
+<p>Rotation of the blue text inside the "child5" <a>'tspan'</a> element:</p>
+
+<ul>
+ <li>
+ The <a>'rotate'</a> value will rotate all the characters in text
+ <em>"specified"</em> by -10 degrees.
+ </li>
+ <li>
+ Only one <a>'rotate'</a> value is specified and is thus
+ applied to all characters in the <a>'tspan'</a> element.
+ </li>
+</ul>
+
+<p>The following diagram illustrates how the rotation values propagate to
+<a>'tspan'</a> elements nested withing a <a>'text'</a> element:</p>
+
+<img alt="Image that shows propagation of rotation values"
+ src="images/text/tspan05-diagram.png" width="528" height="918" />
</edit:with>
@@ -1254,10 +1170,10 @@
<edit:with element='tref'>
- <p>The textual content for a <a>'text'</a> can be either character data
- directly embedded within the <a>'text'</a> element or the character data
- content of a referenced element, where the referencing is specified with a
- <a>'tref'</a> element.</p>
+<p>The textual content for a <a>'text'</a> can be either character data
+directly embedded within the <a>'text'</a> element or the character data
+content of a referenced element, where the referencing is specified with a
+<a>'tref'</a> element.</p>
<edit:elementsummary name='tref'/>
@@ -1276,24 +1192,25 @@
yes.</span></dd>
</dl>
</div>
- <p>All character data within the referenced element, including
- character data enclosed within additional markup, will be
- rendered.</p>
- <p>The <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
- attributes have the same meanings as for the <a>'tspan'</a> element. The
- attributes are applied as if the <a>'tref'</a> element was replaced by a
- <a>'tspan'</a> with the referenced character data (stripped of all
- supplemental markup) embedded within the hypothetical <a>'tspan'</a> element.</p>
-
- <p id="ExampleTRef01"><span class="example-ref">Example tref01</span> shows
- how to use character data from a different element as the character data
- for a given <a>'tspan'</a> element. The first <a>'text'</a> element (with
- <span class='attr-value'>id="ReferencedText"</span>) will not draw because
- it is part of a <a>'defs'</a> element. The second <a>'text'</a> element
- draws the string "Inline character data". The third <a>'text'</a> element
- draws the string "Reference character data" because it includes a
- <a>'tref'</a> element which is a reference to element "ReferencedText",
- and that element's character data is "Referenced character data".</p>
+
+<p>All character data within the referenced element, including
+character data enclosed within additional markup, will be
+rendered.</p>
+<p>The <a>'x'</a>, <a>'y'</a>, <a>'dx'</a>, <a>'dy'</a> and <a>'rotate'</a>
+attributes have the same meanings as for the <a>'tspan'</a> element. The
+attributes are applied as if the <a>'tref'</a> element was replaced by a
+<a>'tspan'</a> with the referenced character data (stripped of all
+supplemental markup) embedded within the hypothetical <a>'tspan'</a> element.</p>
+
+<p id="ExampleTRef01"><span class="example-ref">Example tref01</span> shows
+how to use character data from a different element as the character data
+for a given <a>'tspan'</a> element. The first <a>'text'</a> element (with
+<span class='attr-value'>id="ReferencedText"</span>) will not draw because
+it is part of a <a>'defs'</a> element. The second <a>'text'</a> element
+draws the string "Inline character data". The third <a>'text'</a> element
+draws the string "Reference character data" because it includes a
+<a>'tref'</a> element which is a reference to element "ReferencedText",
+and that element's character data is "Referenced character data".</p>
<edit:example href='images/text/tref01.svg' name='tref01' description="inline vs reference text content" image='yes' link='yes'/>
@@ -1303,175 +1220,189 @@
<h3 id="TextLayoutIntroduction">Text layout introduction</h3>
- <p>This section describes the text layout features supported by
- SVG, which includes support for various international writing
- directions, such as left-to-right (e.g., Latin scripts) and
- bidirectional (e.g., Hebrew or Arabic) and vertical (e.g.,
- Asian scripts). The descriptions in this section assume
- straight line text (i.e., text that is either strictly
- horizontal or vertical with respect to the current user
- coordinate system). Subsequent sections describe the
- supplemental layout rules for <a
- href="text.html#TextOnAPath">text on a path</a>.</p>
- <p>SVG does not provide for automatic line breaks or word
- wrapping, which makes internationalized text layout for SVG
- relatively simpler than it is for languages which support
- formatting of multi-line text blocks.</p>
- <p id="ReferenceOrientation">For each <a>'text'</a> element, the SVG user
- agent determines the current <dfn>reference
- orientation</dfn>. For standard horizontal or vertical text
- (i.e., no text-on-a-path), the reference orientation is the
- vector pointing towards negative infinity in Y within the
- current user coordinate system. (Note: in the <a
- href="coords.html#InitialCoordinateSystem">initial coordinate
- system</a>, the reference orientation is up.) For <a
- href="text.html#TextOnAPath">text on a path</a>, the reference
- orientation is reset with each character.</p>
- <p id="InlineProgressionDirection">Based on the reference orientation and the value for
- property <a>'writing-mode'</a>, the SVG user agent
- determines the current <dfn>inline-progression-direction</dfn>. For
- left-to-right text, the inline-progression-direction points 90
- degrees clockwise from the reference orientation vector. For
- right-to-left text, the inline progression points 90 degrees
- counter-clockwise from the reference orientation vector. For
- top-to-bottom text, the inline-progression-direction points 180
- degrees from the reference orientation vector.</p>
- <p id="BlockProgressionDirection">Based on the reference orientation and the value for
- property <a>'writing-mode'</a>, the SVG user agent
- determines the current <dfn>block-progression-direction</dfn>. For
- left-to-right and right-to-left text, the
- block-progression-direction points 180 degrees from the
- reference orientation vector because the only available
- horizontal <a>'writing-mode'</a>s are <span
- class="prop-value">lr-tb</span> and <span
- class="prop-value">rl-tb</span>. For top-to-bottom text, the
- block-progression-direction always points 90 degrees
- counter-clockwise from the reference orientation vector because
- the only available top-to-bottom <a>'writing-mode'</a> is <span
- class="prop-value">tb-rl</span>.</p>
- <p id="ShiftDirection">The <dfn>shift direction</dfn> is the
- direction towards which the <a
- href="#FontsTablesBaselines">baseline table</a> moves
- due to positive values for property <a>'baseline-shift'</a>. The shift
- direction is such that a positive value shifts the baseline
- table towards the topmost entry in the parent's <a
- href="#FontsTablesBaselines">baseline table</a>.</p>
- <p id="CurrentTextPosition">In processing a given <a>'text'</a> element, the SVG user
- agent keeps track of the <dfn>current text
- position</dfn>. The initial current text position is
- established by the <a>'text/x'</a> and <a>'text/y'</a> attributes on the <a>'text'</a> element.</p>
- <p>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 <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>,
- glyph-specific advance values corresponding to the <a
- href="text.html#GlyphOrientation">glyph orientation</a> of the
- glyph just rendered, kerning tables in the font and the current
- values of various attributes and properties, such as the <a
- href="text.html#SpacingProperties">spacing properties</a> and
- any <a>'tspan/x'</a>, <a>'tspan/y'</a>, <a>'tspan/dx'</a> and
- <a>'tspan/dy'</a> attributes on <a>'text'</a>, <a>'tspan'</a>,
- <a>'tref'</a> or <a>'altGlyph'</a> elements. If a glyph
- does not provide explicit advance values corresponding to the
- current <a href="text.html#GlyphOrientation">glyph
- orientation</a>, 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>em</em> (see
- <a
- href="fonts.html#FontFaceElementUnitsPerEmAttribute">units-per-em</a>).</p>
- <p id="AlignmentPoint">For each glyph to be rendered, the SVG user agent determines
- an appropriate <dfn>alignment-point</dfn> 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 <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
- and the <a href="text.html#GlyphOrientation">glyph
- orientation</a> relative to the inline-progression-direction.
- For most uses of Latin text (i.e.,
- <span class='attr-value'>writing-mode:lr</span>,
- <span class='attr-value'>text-anchor:start</span> and
- <span class='attr-value'>alignment-baseline:baseline</span>)
- 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 <em>top line</em> (see
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#tline">Top Baseline</a>;
- in [<a href="refs.html#ref-CSS2">CSS2</a>], section 15.4.18). If a glyph does not
- provide explicit origin points corresponding to the current <a
- href="text.html#GlyphOrientation">glyph orientation</a>, 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.</p>
- <p id="TextChunks">Adjustments to the current text position are either
- <dfn id='absolute-position-adjustment'>absolute position adjustments</dfn> or
- <dfn id='relative-position-adjustment'>relative position adjustments</dfn>. An
- absolute position adjustment occurs in the following
- circumstances:</p>
- <ul>
- <li>At the start of a <a>'text'</a> element</li>
- <li>At the start of each <a>'textPath'</a> element</li>
- <li>For each character within a <a>'text'</a>, <a>'tspan'</a>,
- <a>'tref'</a> and <a>'altGlyph'</a> element which has an
- <span class='attr-name'>'x'</span> or <span class='attr-name'>'y'</span>
- attribute value assigned to it explicitly</li>
- </ul>
- <p>All other position adjustments to the current text position
- are relative position adjustments.</p>
- <p id="TextChunk">Each absolute position adjustment defines a new
- <dfn>text chunk</dfn>. Absolute position
- adjustments impact text layout in the following ways:</p>
- <ul>
- <li>Ligatures only occur when a set of characters which might
- map to a ligature are all in the same text chunk.</li>
- <li>Each text chunk represents a separate block of text for
- alignment due to <a>'text-anchor'</a> property
- values.</li>
- <li>Reordering of characters due to <a
- href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>
- only occurs within a text chunk. Reordering does <em>not</em>
- happen across text chunks.</li>
- </ul>
- <p>The following additional rules apply to ligature
- formation:</p>
- <ul>
- <li>As <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#spacing-props">defined in CSS2</a>,
- ([<a href="refs.html#ref-CSS2">CSS2</a>], 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 are non-default values for
- properties <a>'kerning'</a> or <a>'letter-spacing'</a>, the user agent
- should not use ligatures.</li>
- <li>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.</li>
- <li>As mentioned above, ligature formation should not be
- enabled for the glyphs corresponding to characters within
- different text chunks.</li>
- </ul>
+<p>This section describes the text layout features supported by
+SVG, which includes support for various international writing
+directions, such as left-to-right (e.g., Latin scripts) and
+bidirectional (e.g., Hebrew or Arabic) and vertical (e.g.,
+Asian scripts). The descriptions in this section assume
+straight line text (i.e., text that is either strictly
+horizontal or vertical with respect to the current user
+coordinate system). Subsequent sections describe the
+supplemental layout rules for <a
+href="text.html#TextOnAPath">text on a path</a>.</p>
+
+<p>SVG does not provide for automatic line breaks or word
+wrapping, which makes internationalized text layout for SVG
+relatively simpler than it is for languages which support
+formatting of multi-line text blocks.</p>
+
+<p id="ReferenceOrientation">For each <a>'text'</a> element, the SVG user
+agent determines the current <dfn>reference
+orientation</dfn>. For standard horizontal or vertical text
+(i.e., no text-on-a-path), the reference orientation is the
+vector pointing towards negative infinity in Y within the
+current user coordinate system. (Note: in the <a
+href="coords.html#InitialCoordinateSystem">initial coordinate
+system</a>, the reference orientation is up.) For <a
+href="text.html#TextOnAPath">text on a path</a>, the reference
+orientation is reset with each character.</p>
+
+<p id="InlineProgressionDirection">Based on the reference orientation and the value for
+property <a>'writing-mode'</a>, the SVG user agent
+determines the current <dfn>inline-progression-direction</dfn>. For
+left-to-right text, the inline-progression-direction points 90
+degrees clockwise from the reference orientation vector. For
+right-to-left text, the inline progression points 90 degrees
+counter-clockwise from the reference orientation vector. For
+top-to-bottom text, the inline-progression-direction points 180
+degrees from the reference orientation vector.</p>
+
+<p id="BlockProgressionDirection">Based on the reference orientation and the value for
+property <a>'writing-mode'</a>, the SVG user agent
+determines the current <dfn>block-progression-direction</dfn>. For
+left-to-right and right-to-left text, the
+block-progression-direction points 180 degrees from the
+reference orientation vector because the only available
+horizontal <a>'writing-mode'</a>s are <span
+class="prop-value">lr-tb</span> and <span
+class="prop-value">rl-tb</span>. For top-to-bottom text, the
+block-progression-direction always points 90 degrees
+counter-clockwise from the reference orientation vector because
+the only available top-to-bottom <a>'writing-mode'</a> is <span
+class="prop-value">tb-rl</span>.</p>
+
+<p id="ShiftDirection">The <dfn>shift direction</dfn> is the
+direction towards which the <a
+href="#FontsTablesBaselines">baseline table</a> moves
+due to positive values for property <a>'baseline-shift'</a>. The shift
+direction is such that a positive value shifts the baseline
+table towards the topmost entry in the parent's <a
+href="#FontsTablesBaselines">baseline table</a>.</p>
+
+<p id="CurrentTextPosition">In processing a given <a>'text'</a> element, the SVG user
+agent keeps track of the <dfn>current text
+position</dfn>. The initial current text position is
+established by the <a>'text/x'</a> and <a>'text/y'</a> attributes on the <a>'text'</a> element.</p>
+
+<p>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 <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>,
+glyph-specific advance values corresponding to the <a
+href="text.html#GlyphOrientation">glyph orientation</a> of the
+glyph just rendered, kerning tables in the font and the current
+values of various attributes and properties, such as the <a
+href="text.html#SpacingProperties">spacing properties</a> and
+any <a>'tspan/x'</a>, <a>'tspan/y'</a>, <a>'tspan/dx'</a> and
+<a>'tspan/dy'</a> attributes on <a>'text'</a>, <a>'tspan'</a>,
+<a>'tref'</a> or <a>'altGlyph'</a> elements. If a glyph
+does not provide explicit advance values corresponding to the
+current <a href="text.html#GlyphOrientation">glyph
+orientation</a>, 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>em</em> (see
+<a
+href="fonts.html#FontFaceElementUnitsPerEmAttribute">units-per-em</a>).</p>
+<p id="AlignmentPoint">For each glyph to be rendered, the SVG user agent determines
+an appropriate <dfn>alignment-point</dfn> 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 <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
+and the <a href="text.html#GlyphOrientation">glyph
+orientation</a> relative to the inline-progression-direction.
+For most uses of Latin text (i.e.,
+<span class='attr-value'>writing-mode:lr</span>,
+<span class='attr-value'>text-anchor:start</span> and
+<span class='attr-value'>alignment-baseline:baseline</span>)
+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 <em>top line</em> (see
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#tline">Top Baseline</a>;
+in [<a href="refs.html#ref-CSS2">CSS2</a>], section 15.4.18). If a glyph does not
+provide explicit origin points corresponding to the current <a
+href="text.html#GlyphOrientation">glyph orientation</a>, 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.</p>
+
+<p id="TextChunks">Adjustments to the current text position are either
+<dfn id='absolute-position-adjustment'>absolute position adjustments</dfn> or
+<dfn id='relative-position-adjustment'>relative position adjustments</dfn>. An
+absolute position adjustment occurs in the following
+circumstances:</p>
+
+<ul>
+ <li>At the start of a <a>'text'</a> element</li>
+ <li>At the start of each <a>'textPath'</a> element</li>
+ <li>For each character within a <a>'text'</a>, <a>'tspan'</a>,
+ <a>'tref'</a> and <a>'altGlyph'</a> element which has an
+ <span class='attr-name'>'x'</span> or <span class='attr-name'>'y'</span>
+ attribute value assigned to it explicitly</li>
+</ul>
+
+<p>All other position adjustments to the current text position
+are relative position adjustments.</p>
+
+<p id="TextChunk">Each absolute position adjustment defines a new
+<dfn>text chunk</dfn>. Absolute position
+adjustments impact text layout in the following ways:</p>
+
+<ul>
+ <li>Ligatures only occur when a set of characters which might
+ map to a ligature are all in the same text chunk.</li>
+ <li>Each text chunk represents a separate block of text for
+ alignment due to <a>'text-anchor'</a> property values.</li>
+ <li>Reordering of characters due to <a
+ href="text.html#RelationshipWithBiDirectionality">bidirectionality</a>
+ only occurs within a text chunk. Reordering does <em>not</em>
+ happen across text chunks.</li>
+</ul>
+
+<p>The following additional rules apply to ligature formation:</p>
+
+<ul>
+ <li>As <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#spacing-props">defined in CSS2</a>,
+ ([<a href="refs.html#ref-CSS2">CSS2</a>], 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 are non-default values for
+ properties <a>'kerning'</a> or <a>'letter-spacing'</a>, the user agent
+ should not use ligatures.</li>
+
+ <li>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.</li>
+
+ <li>As mentioned above, ligature formation should not be
+ enabled for the glyphs corresponding to characters within
+ different text chunks.</li>
+</ul>
<h3 id="SettingInlineProgressionDirection">Setting the inline-progression-direction</h3>
- <p>The <a>'writing-mode'</a> property specifies whether the initial
- inline-progression-direction for a <a>'text'</a> element shall be
- left-to-right, right-to-left, or top-to-bottom. The <a>'writing-mode'</a>
- property applies only to <a>'text'</a> elements; the property is ignored for
- <a>'tspan'</a>, <a>'tref'</a>, <a>'altGlyph'</a> and <a>'textPath'</a>
- sub-elements. (Note that the inline-progression-direction can change within
- a <a>'text'</a> element due to the Unicode bidirectional algorithm and
- properties <a>'direction'</a> and <a>'unicode-bidi'</a>. For more on
- bidirectional text, see
- <a href="text.html#RelationshipWithBiDirectionality">Relationship with bidirectionality</a>.)</p>
+<p>The <a>'writing-mode'</a> property specifies whether the initial
+inline-progression-direction for a <a>'text'</a> element shall be
+left-to-right, right-to-left, or top-to-bottom. The <a>'writing-mode'</a>
+property applies only to <a>'text'</a> elements; the property is ignored for
+<a>'tspan'</a>, <a>'tref'</a>, <a>'altGlyph'</a> and <a>'textPath'</a>
+sub-elements. (Note that the inline-progression-direction can change within
+a <a>'text'</a> element due to the Unicode bidirectional algorithm and
+properties <a>'direction'</a> and <a>'unicode-bidi'</a>. For more on
+bidirectional text, see
+<a href="text.html#RelationshipWithBiDirectionality">Relationship with bidirectionality</a>.)</p>
<div class="propdef">
<dl>
@@ -1516,48 +1447,52 @@
</dd>
</dl>
</div>
- <dl>
- <dt><span class="attr-value">lr-tb | lr</span></dt>
- <dd>Sets the initial inline-progression-direction to
- left-to-right, as is common in most Latin-based documents.
- For most characters, the <em>current text position</em> is
- advanced from left to right after each glyph is rendered.
- (When the character data includes characters which are
- subject to the Unicode bidirectional algorithm, the text
- advance rules are more complex. See <a
- href="text.html#RelationshipWithBiDirectionality">Relationship
- with bidirectionality</a>).</dd>
- <dt><span class="attr-value">rl-tb | rl</span></dt>
- <dd>Sets the initial inline-progression-direction to
- right-to-left, as is common in Arabic or Hebrew scripts. (See
- <a
- href="text.html#RelationshipWithBiDirectionality">Relationship
- with bidirectionality</a>.)</dd>
- <dt><span class="attr-value">tb-rl | tb</span></dt>
- <dd>Sets the initial inline-progression-direction to
- top-to-bottom, as is common in some Asian scripts, such as
- Chinese and Japanese. Though hardly as frequent as
- horizontal, this type of vertical layout also occurs in Latin
- based documents, particularly in table column or row labels.
- In most cases, the vertical baselines running through the
- middle of each glyph are aligned.</dd>
- </dl>
+
+<dl>
+ <dt><span class="attr-value">lr-tb | lr</span></dt>
+ <dd>Sets the initial inline-progression-direction to
+ left-to-right, as is common in most Latin-based documents.
+ For most characters, the <em>current text position</em> is
+ advanced from left to right after each glyph is rendered.
+ (When the character data includes characters which are
+ subject to the Unicode bidirectional algorithm, the text
+ advance rules are more complex. See <a
+ href="text.html#RelationshipWithBiDirectionality">Relationship
+ with bidirectionality</a>).</dd>
+
+ <dt><span class="attr-value">rl-tb | rl</span></dt>
+ <dd>Sets the initial inline-progression-direction to
+ right-to-left, as is common in Arabic or Hebrew scripts. (See
+ <a
+ href="text.html#RelationshipWithBiDirectionality">Relationship
+ with bidirectionality</a>.)</dd>
+
+ <dt><span class="attr-value">tb-rl | tb</span></dt>
+ <dd>Sets the initial inline-progression-direction to
+ top-to-bottom, as is common in some Asian scripts, such as
+ Chinese and Japanese. Though hardly as frequent as
+ horizontal, this type of vertical layout also occurs in Latin
+ based documents, particularly in table column or row labels.
+ In most cases, the vertical baselines running through the
+ middle of each glyph are aligned.</dd>
+</dl>
<h3 id="GlyphOrientation">Glyph orientation within a text run</h3>
- <p>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.</p>
- <p>Two properties control the glyph orientation relative to the
- reference orientation for each of the two possible
- inline-progression-directions. <a>'glyph-orientation-vertical'</a> controls
- glyph orientation when the inline-progression-direction is
- vertical. <a>'glyph-orientation-horizontal'</a>
- controls glyph orientation when the
- inline-progression-direction is horizontal.</p>
+<p>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.</p>
+
+<p>Two properties control the glyph orientation relative to the
+reference orientation for each of the two possible
+inline-progression-directions. <a>'glyph-orientation-vertical'</a> controls
+glyph orientation when the inline-progression-direction is
+vertical. <a>'glyph-orientation-horizontal'</a>
+controls glyph orientation when the
+inline-progression-direction is horizontal.</p>
<div class="propdef">
<dl>
@@ -1603,120 +1538,129 @@
</dd>
</dl>
</div>
- <dl>
- <dt><span class="prop-value">auto</span></dt>
- <dd>
- <ul>
- <li>
- <p>Fullwidth ideographic and fullwidth Latin text will
- be set with a glyph-orientation of 0-degrees.</p>
- <p>Ideographic punctuation and other ideographic
- characters having alternate horizontal and vertical
- forms will use the vertical form of the glyph.</p>
- </li>
- <li>
- <p>Text which is not fullwidth will be set with a
- glyph-orientation of 90-degrees.</p>
- <p>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.</p>
- <blockquote>
- <b>NOTE:</b>
- <ul>
- <li>
- <p>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.</p>
- <p>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.)</p>
- </li>
- <li>
- <p>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.</p>
- </li>
- </ul>
- </blockquote>
- </li>
- </ul>
- </dd>
- <dt><span class="prop-value"><a
- href="types.html#DataTypeAngle"><angle></a></span></dt>
- <dd>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.<br />
- A value of <span class="prop-value">0deg</span> indicates
- that all glyphs are set with the top of the glyphs oriented
- towards the <a
- href="text.html#ReferenceOrientation">reference
- orientation</a>. A value of <span
- class="prop-value">90deg</span> indicates an orientation of
- 90 degrees clockwise from the <a
- href="text.html#ReferenceOrientation">reference
- orientation</a>.</dd>
- </dl>
- <p>This property is applied only to text written in a vertical
- <a>'writing-mode'</a>.</p>
- <p>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 <a>'glyph-orientation-vertical'</a> 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 <a>'glyph-orientation-vertical'</a> 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.</p>
- <p>The text layout diagrams in this section use the following
- symbols:</p>
- <table>
- <tr><th><img alt="Symbolic wide-cell glyph representation" class="example" width="39" height="39" src="images/text/fullwidth.png" /></th>
- <td>wide-cell glyph (e.g. Han) which is the <em>n</em>-th glyph in the text run</td></tr>
- <tr><th><img alt="Symbolic narrow-cell glyph representation" class="example" width="19" height="39" src="images/text/halfwidth.png" /></th>
- <td>narrow-cell glyph (e.g. Latin) which is the <em>n</em>-th glyph in the text run</td></tr>
- </table>
- <p>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.</p>
- <p>The diagrams below illustrate different uses of <a>'glyph-orientation-vertical'</a>. The
- diagram on the left shows the result of the mixing of
- full-width ideographic glyphs with narrow-cell Latin glyphs
- when <a>'glyph-orientation-vertical'</a> for the
- Latin characters is either <span class="prop-value">auto</span>
- or <span class="prop-value">90</span>. 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 <a>'glyph-orientation-vertical'</a> of <span
- class="prop-value">0</span>.</p>
- <p><img
- alt="Layout of mixed glyphs in vertical-ideographic mode. Wide-cell glyphs are upright, Non-wide-cell glyphs are rotated by 90 degrees."
- class="example" align="top" width="45" height="262"
- src="images/text/lf-vi.png" /><img
- alt="Example of mixed Japanese and English in vertical-ideographic layout. Japanese glyphs are upright, English rotated."
- class="example" align="top" width="40" height="260"
- src="images/text/GlyphOrientAuto.png" />
-
- <img
- alt="Layout of mixed glyphs in vertical mode. All glyphs are upright."
- class="example" align="top" width="42" height="342"
- src="images/text/lf-v.png" /><img
- alt="Example of mixed Japanese and English in vertical layout. All glyphs are upright."
- class="example" align="top" width="38" height="340"
- src="images/text/GlyphOrientZero.png" /></p>
+
+<dl>
+ <dt><span class="prop-value">auto</span></dt>
+ <dd>
+ <ul>
+ <li>
+ <p>Fullwidth ideographic and fullwidth Latin text will
+ be set with a glyph-orientation of 0-degrees.</p>
+ <p>Ideographic punctuation and other ideographic
+ characters having alternate horizontal and vertical
+ forms will use the vertical form of the glyph.</p>
+ </li>
+ <li>
+ <p>Text which is not fullwidth will be set with a
+ glyph-orientation of 90-degrees.</p>
+ <p>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.</p>
+ <blockquote>
+ <b>NOTE:</b>
+ <ul>
+ <li>
+ <p>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.</p>
+ <p>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.)</p>
+ </li>
+ <li>
+ <p>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.</p>
+ </li>
+ </ul>
+ </blockquote>
+ </li>
+ </ul>
+ </dd>
+
+ <dt><span class="prop-value"><a
+ href="types.html#DataTypeAngle"><angle></a></span></dt>
+ <dd>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.<br />
+ A value of <span class="prop-value">0deg</span> indicates
+ that all glyphs are set with the top of the glyphs oriented
+ towards the <a
+ href="text.html#ReferenceOrientation">reference
+ orientation</a>. A value of <span
+ class="prop-value">90deg</span> indicates an orientation of
+ 90 degrees clockwise from the <a
+ href="text.html#ReferenceOrientation">reference
+ orientation</a>.</dd>
+</dl>
+
+<p>This property is applied only to text written in a vertical
+<a>'writing-mode'</a>.</p>
+
+<p>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 <a>'glyph-orientation-vertical'</a> 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 <a>'glyph-orientation-vertical'</a> 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.</p>
+
+<p>The text layout diagrams in this section use the following
+symbols:</p>
+
+<table>
+ <tr><th><img alt="Symbolic wide-cell glyph representation" class="example" width="39" height="39" src="images/text/fullwidth.png" /></th>
+ <td>wide-cell glyph (e.g. Han) which is the <em>n</em>-th glyph in the text run</td></tr>
+ <tr><th><img alt="Symbolic narrow-cell glyph representation" class="example" width="19" height="39" src="images/text/halfwidth.png" /></th>
+ <td>narrow-cell glyph (e.g. Latin) which is the <em>n</em>-th glyph in the text run</td></tr>
+</table>
+
+<p>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.</p>
+
+<p>The diagrams below illustrate different uses of <a>'glyph-orientation-vertical'</a>. The
+diagram on the left shows the result of the mixing of
+full-width ideographic glyphs with narrow-cell Latin glyphs
+when <a>'glyph-orientation-vertical'</a> for the
+Latin characters is either <span class="prop-value">auto</span>
+or <span class="prop-value">90</span>. 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 <a>'glyph-orientation-vertical'</a> of <span
+class="prop-value">0</span>.</p>
+
+<p><img
+alt="Layout of mixed glyphs in vertical-ideographic mode. Wide-cell glyphs are upright, Non-wide-cell glyphs are rotated by 90 degrees."
+ class="example" align="top" width="45" height="262"
+src="images/text/lf-vi.png" /><img
+alt="Example of mixed Japanese and English in vertical-ideographic layout. Japanese glyphs are upright, English rotated."
+ class="example" align="top" width="40" height="260"
+src="images/text/GlyphOrientAuto.png" />
+
+<img
+alt="Layout of mixed glyphs in vertical mode. All glyphs are upright."
+ class="example" align="top" width="42" height="342"
+src="images/text/lf-v.png" /><img
+alt="Example of mixed Japanese and English in vertical layout. All glyphs are upright."
+ class="example" align="top" width="38" height="340"
+src="images/text/GlyphOrientZero.png" /></p>
<div class="propdef">
<dl>
@@ -1762,134 +1706,129 @@
</dd>
</dl>
</div>
- <dl>
- <dt><span class="prop-value"><a
- href="types.html#DataTypeAngle"><angle></a></span></dt>
- <dd>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.<br />
- A value of <span class="prop-value">0deg</span> indicates
- that all glyphs are set with the top of the glyphs oriented
- towards the <a
- href="text.html#ReferenceOrientation">reference
- orientation</a>. A value of <span
- class="prop-value">90deg</span> indicates an orientation of
- 90 degrees clockwise from the <a
- href="text.html#ReferenceOrientation">reference
- orientation</a>.</dd>
- </dl>
- <p>This property is applied only to text written in a
- horizontal <a>'writing-mode'</a>.</p>
- <p>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 <a>'glyph-orientation-horizontal'</a> 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 <a>'glyph-orientation-horizontal'</a> 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.</p>
+
+<dl>
+ <dt><span class="prop-value"><a
+ href="types.html#DataTypeAngle"><angle></a></span></dt>
+ <dd>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.<br />
+ A value of <span class="prop-value">0deg</span> indicates
+ that all glyphs are set with the top of the glyphs oriented
+ towards the <a
+ href="text.html#ReferenceOrientation">reference
+ orientation</a>. A value of <span
+ class="prop-value">90deg</span> indicates an orientation of
+ 90 degrees clockwise from the <a
+ href="text.html#ReferenceOrientation">reference
+ orientation</a>.</dd>
+</dl>
+
+<p>This property is applied only to text written in a
+horizontal <a>'writing-mode'</a>.</p>
+
+<p>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 <a>'glyph-orientation-horizontal'</a> 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 <a>'glyph-orientation-horizontal'</a> 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.</p>
<h3 id="RelationshipWithBiDirectionality">Relationship with bidirectionality</h3>
- <p>
- The characters in certain scripts are written from right to
- left. In some documents, in particular those written with the
- Arabic or Hebrew script, and in some mixed-language contexts,
- text in a single line may appear with mixed directionality.
- This phenomenon is called bidirectionality, or "bidi" for
- short.
- </p>
- <p>
- The Unicode standard ([<a href="refs.html#ref-UNICODE">UNICODE</a>],
- specifically [<a href="refs.html#ref-UAX9">UAX9</a>]) defines a
- complex algorithm for determining the proper directionality of
- text. The algorithm consists of an implicit part based on
- character properties, as well as explicit controls for
- embeddings and overrides. The
- <a>SVG user agent</a>
- applies this bidirectional algorithm when determining the layout of characters within a
- <a>text content block element</a>.
- </p>
-
- <p>The <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- and
- <a href="text.html#DirectionProperty"><span class="attr-name">'unicode-bidi'</span></a>
- properties allow authors to override the inherent directionality
- of the content characters and thus explicitly control how the
- elements and attributes of a document language map to this algorithm. These
- two properties are applicable to all characters whose glyphs are
- perpendicular to the inline-progression-direction.
- </p>
-
- <p> In many cases, the bidirectional algorithm from Unicode
- [<a href="refs.html#ref-UNICODE">UNICODE</a>] 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 the
- <a>'direction'</a> property to the <a>rootmost 'svg' element</a>,
- and allow that direction to inherit to all text elements,
- as in the following example (which may be used as a template):
- </p>
- <edit:example href="images/text/rtl-text.svg" link="yes" image="yes"/>
-
- <p>Below is another example, where where implicit bidi reordering is not sufficient:</p>
- <edit:example href="images/text/rtl-complex.svg" link="yes" image="yes"/>
-
- <p>
- Within
- <a>text content elements</a>,
- the alignment of text with regards to the
- <a href="#TextAnchorProperty"><span class="property">'text-anchor'</span></a> property
- is determined by the value of the
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- property. For example, given a
- <a href="text.html#TextElement"><span class="element-name">'text'</span></a>
- element with a
- <a href="#TextAnchorProperty"><span class="property">'text-anchor'</span></a>
- value of <span class="prop-value">"end"</span>, for a
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- value of <span class="prop-value">"ltr"</span>, the text will
- extend to the left of the position of the
- <a href="text.html#TextElement"><span class="element-name">'text'</span></a>
- element's
- <a href="text.html#TextElementXAttribute"><span class="attr-name">'x'</span></a>
- attribute value, while for
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- value of <span class="prop-value">"rtl"</span>, the text will
- extend to the right of the position of the
- <a href="text.html#TextElement"><span class="element-name">'text'</span></a>
- element's
- <a href="text.html#TextElementXAttribute"><span class="attr-name">'x'</span></a>
- attribute value.
- </p>
-
- <p>A more complete discussion of bidirectionality can be found
- in the <a href="http://www.w3.org/TR/CSS2/visuren.html#direction">Text direction</a>
- section of CSS 2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
- <p>The processing model for bidirectional text is as follows.
- The user agent processes the characters which are provided in
- <em>logical order</em> (i.e., the order
- the characters appear in the original document, either via
- direct inclusion or via indirect reference due a <a href="text.html#TRefElement"><span class="element-name">'tref'</span></a> element). The user agent
- determines the set of independent blocks within each of which
- it should apply the Unicode bidirectional algorithm. Each <a href="text.html#TextChunk">text chunk</a> represents an
- independent block of text. Additionally, any change in glyph
- orientation due to processing of properties <a href="text.html#GlyphOrientationHorizontalProperty"><span class="property">'glyph-orientation-horizontal'</span></a> or
- <a href="text.html#GlyphOrientationVerticalProperty"><span class="property">'glyph-orientation-vertical'</span></a> will
- subdivide the independent blocks of text further. After
- processing the Unicode bidirectional algorithm and properties
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a> and <a href="text.html#UnicodeBidiProperty"><span class="attr-name">'unicode-bidi'</span></a> 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 <a href="text.html#TSpanElementDXAttribute"><span class="attr-name">dx</span></a>, <a href="text.html#TSpanElementDYAttribute"><span class="attr-name">dy</span></a> and <a href="text.html#TSpanElementRotateAttribute"><span class="attr-name">rotate</span></a> attributes on the <a href="text.html#TSpanElement"><span class="element-name">'tspan'</span></a> and <a href="text.html#TRefElement"><span class="element-name">'tref'</span></a> 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.</p>
-
+
+<p>The characters in certain scripts are written from right to
+left. In some documents, in particular those written with the
+Arabic or Hebrew script, and in some mixed-language contexts,
+text in a single line may appear with mixed directionality.
+This phenomenon is called bidirectionality, or "bidi" for
+short.</p>
+
+<p>The Unicode standard ([<a href="refs.html#ref-UNICODE">UNICODE</a>],
+specifically [<a href="refs.html#ref-UAX9">UAX9</a>]) defines a
+complex algorithm for determining the proper directionality of
+text. The algorithm consists of an implicit part based on
+character properties, as well as explicit controls for
+embeddings and overrides. The
+<a>SVG user agent</a>
+applies this bidirectional algorithm when determining the layout of characters within a
+<a>text content block element</a>.</p>
+
+<p>The <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+and <a href="text.html#DirectionProperty"><span class="attr-name">'unicode-bidi'</span></a>
+properties allow authors to override the inherent directionality
+of the content characters and thus explicitly control how the
+elements and attributes of a document language map to this algorithm. These
+two properties are applicable to all characters whose glyphs are
+perpendicular to the inline-progression-direction.</p>
+
+<p>In many cases, the bidirectional algorithm from Unicode
+[<a href="refs.html#ref-UNICODE">UNICODE</a>] 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 the
+<a>'direction'</a> property to the <a>rootmost 'svg' element</a>,
+and allow that direction to inherit to all text elements,
+as in the following example (which may be used as a template):</p>
+
+<edit:example href="images/text/rtl-text.svg" link="yes" image="yes"/>
+
+<p>Below is another example, where where implicit bidi reordering is not sufficient:</p>
+<edit:example href="images/text/rtl-complex.svg" link="yes" image="yes"/>
+
+<p>Within <a>text content elements</a>,
+the alignment of text with regards to the
+<a href="#TextAnchorProperty"><span class="property">'text-anchor'</span></a> property
+is determined by the value of the
+<a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+property. For example, given a
+<a href="text.html#TextElement"><span class="element-name">'text'</span></a>
+element with a
+<a href="#TextAnchorProperty"><span class="property">'text-anchor'</span></a>
+value of <span class="prop-value">"end"</span>, for a
+<a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+value of <span class="prop-value">"ltr"</span>, the text will
+extend to the left of the position of the
+<a href="text.html#TextElement"><span class="element-name">'text'</span></a>
+element's
+<a href="text.html#TextElementXAttribute"><span class="attr-name">'x'</span></a>
+attribute value, while for
+<a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+value of <span class="prop-value">"rtl"</span>, the text will
+extend to the right of the position of the
+<a href="text.html#TextElement"><span class="element-name">'text'</span></a>
+element's
+<a href="text.html#TextElementXAttribute"><span class="attr-name">'x'</span></a>
+attribute value.</p>
+
+<p>A more complete discussion of bidirectionality can be found
+in the <a href="http://www.w3.org/TR/CSS2/visuren.html#direction">Text direction</a>
+section of CSS 2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
+<p>The processing model for bidirectional text is as follows.
+The user agent processes the characters which are provided in
+<em>logical order</em> (i.e., the order
+the characters appear in the original document, either via
+direct inclusion or via indirect reference due a <a href="text.html#TRefElement"><span class="element-name">'tref'</span></a> element). The user agent
+determines the set of independent blocks within each of which
+it should apply the Unicode bidirectional algorithm. Each <a href="text.html#TextChunk">text chunk</a> represents an
+independent block of text. Additionally, any change in glyph
+orientation due to processing of properties <a href="text.html#GlyphOrientationHorizontalProperty"><span class="property">'glyph-orientation-horizontal'</span></a> or
+<a href="text.html#GlyphOrientationVerticalProperty"><span class="property">'glyph-orientation-vertical'</span></a> will
+subdivide the independent blocks of text further. After
+processing the Unicode bidirectional algorithm and properties
+<a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a> and <a href="text.html#UnicodeBidiProperty"><span class="attr-name">'unicode-bidi'</span></a> 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 <a href="text.html#TSpanElementDXAttribute"><span class="attr-name">dx</span></a>, <a href="text.html#TSpanElementDYAttribute"><span class="attr-name">dy</span></a> and <a href="text.html#TSpanElementRotateAttribute"><span class="attr-name">rotate</span></a> attributes on the <a href="text.html#TSpanElement"><span class="element-name">'tspan'</span></a> and <a href="text.html#TRefElement"><span class="element-name">'tref'</span></a> 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.</p>
<div class="propdef">
<dl>
@@ -1933,24 +1872,27 @@
</dd>
</dl>
</div>
- <p>This property specifies the base writing direction of text
- and the direction of embeddings and overrides (see <a>'unicode-bidi'</a>) for the Unicode
- bidirectional algorithm. For the <a>'direction'</a> property to have any
- effect on an element that does not by itself establish a new <a href="text.html#TextChunks">text chunk</a>
- (such as a <a>'tspan'</a> element without absolute position adjustments due to <a>'tspan/x'</a> or <a>'tspan/y'</a> attributes),
- the <a>'unicode-bidi'</a> property's value
- must be <span class='prop-value'>embed</span> or <span class='prop-value'>bidi-override</span>.</p>
- <p>Except for any additional information provided in this
- specification, the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/visuren.html#propdef-direction">normative definition</a>
- of the <a>'direction'</a> property is in CSS2
- ([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
- <p>The <a>'direction'</a> property
- applies only to glyphs oriented perpendicular to the <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>,
- 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.</p>
+
+<p>This property specifies the base writing direction of text
+and the direction of embeddings and overrides (see <a>'unicode-bidi'</a>) for the Unicode
+bidirectional algorithm. For the <a>'direction'</a> property to have any
+effect on an element that does not by itself establish a new <a href="text.html#TextChunks">text chunk</a>
+(such as a <a>'tspan'</a> element without absolute position adjustments due to <a>'tspan/x'</a> or <a>'tspan/y'</a> attributes),
+the <a>'unicode-bidi'</a> property's value
+must be <span class='prop-value'>embed</span> or <span class='prop-value'>bidi-override</span>.</p>
+
+<p>Except for any additional information provided in this
+specification, the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/visuren.html#propdef-direction">normative definition</a>
+of the <a>'direction'</a> property is in CSS2
+([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
+
+<p>The <a>'direction'</a> property
+applies only to glyphs oriented perpendicular to the <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>,
+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.</p>
<div class="propdef">
<dl>
@@ -1995,24 +1937,26 @@
</dd>
</dl>
</div>
- <p>Except for any additional information provided in this
- specification, the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/visuren.html#propdef-unicode-bidi">normative definition</a>
- of the <a>'unicode-bidi'</a> property is in CSS2
- ([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
+
+<p>Except for any additional information provided in this
+specification, the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/visuren.html#propdef-unicode-bidi">normative definition</a>
+of the <a>'unicode-bidi'</a> property is in CSS2
+([<a href="refs.html#ref-CSS2">CSS2</a>], section 9.10).</p>
<h2 id="TextRenderingOrder">Text rendering order</h2>
- <p>The glyphs associated with the characters within a <a>'text'</a> 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.</p>
- <p>Additionally, each distinct glyph is rendered in its
- entirety (i.e., it is filled and stroked as specified by the <a>'fill'</a>
- and <a>'stroke'</a> properties) before the
- next glyph gets rendered.</p>
+<p>The glyphs associated with the characters within a <a>'text'</a> 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.</p>
+
+<p>Additionally, each distinct glyph is rendered in its
+entirety (i.e., it is filled and stroked as specified by the <a>'fill'</a>
+and <a>'stroke'</a> properties) before the
+next glyph gets rendered.</p>
<h2 id='AlignmentProperties'>Alignment properties</h2>
@@ -2073,281 +2017,298 @@
</dd>
</dl>
</div>
- <p>Values have the following meanings:</p>
- <dl>
- <dt><span class="attr-value">start</span></dt>
- <dd>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
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- property value of <span class="prop-value">"ltr"</span>
- (typical for most European languages),
- the left side of the text is rendered at the initial text
- position. For an element with a
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- property value of <span class="prop-value">"rtl"</span>
- (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.
- </dd>
- <dt><span class="attr-value">middle</span></dt>
- <dd>The rendered characters are aligned such that the geometric middle
- of the resulting rendered text is at the initial current text position.</dd>
- <dt><span class="attr-value">end</span></dt>
- <dd>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
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- property value of <span class="prop-value">"ltr"</span>
- (typical for most European languages),
- the right side of the text is rendered at the initial text
- position. For an element with a
- <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
- property value of <span class="prop-value">"rtl"</span>
- (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.
- </dd>
- </dl>
+
+<p>Values have the following meanings:</p>
+
+<dl>
+ <dt><span class="attr-value">start</span></dt>
+ <dd>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
+ <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+ property value of <span class="prop-value">"ltr"</span>
+ (typical for most European languages),
+ the left side of the text is rendered at the initial text
+ position. For an element with a
+ <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+ property value of <span class="prop-value">"rtl"</span>
+ (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.
+ </dd>
+
+ <dt><span class="attr-value">middle</span></dt>
+ <dd>The rendered characters are aligned such that the geometric middle
+ of the resulting rendered text is at the initial current text position.</dd>
+
+ <dt><span class="attr-value">end</span></dt>
+ <dd>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
+ <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+ property value of <span class="prop-value">"ltr"</span>
+ (typical for most European languages),
+ the right side of the text is rendered at the initial text
+ position. For an element with a
+ <a href="text.html#DirectionProperty"><span class="attr-name">'direction'</span></a>
+ property value of <span class="prop-value">"rtl"</span>
+ (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.
+ </dd>
+</dl>
<h3 id="BaselineAlignmentProperties">Baseline alignment properties</h3>
- <p>An overview of baseline alignment and baseline tables can be
- found above in <a href="text.html#FontsTablesBaselines">Fonts,
- font tables and baselines</a>.</p>
- <p>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.</p>
- <p>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 [<a
- href="http://www.microsoft.com/typography/otspec/">OPENTYPE</a>]
- fonts have a Baseline table (BASE) [<a
- href="http://www.microsoft.com/typography/otspec/base.htm">OPENTYPE-BASETABLE</a>]
- that specifies the offsets of the alternative baselines from
- the current baseline.</p>
- <p>SVG uses a similar baseline table model that assumes one
- script (at one font-size) is the "dominant run" during
- processing of a <a>'text'</a> 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
- <dfn>dominant baseline</dfn>. 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.</p>
- <p>The baseline table established at the start of processing of
- a <a>'text'</a> element is called the
- <dfn>dominant baseline table</dfn>.</p>
- <p>Because the value of the <a>'font-family'</a> property is a list
- of fonts, to insure a consistent choice of baseline table we
- define the <em>nominal font</em> 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.</p>
- <p>The value of the <a>'font-size'</a> property on the <a>'text'</a> element establishes the
- <dfn>dominant baseline table font size</dfn>.</p>
- <p>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 <a
- href="text.html#AlignmentBaselineProperty"><span
- class="property">'alignment-baseline'</span></a> property uses
- the baseline identifier associated with the given glyph.
- Alternate values for <a
- href="text.html#AlignmentBaselineProperty"><span
- class="property">'alignment-baseline'</span></a> can be useful
- for glyphs such as a "*" which are ambiguous with respect to
- script membership.</p>
- <p>The model assumes that the font from which the glyph is
- drawn also has a baseline table, the
- <dfn>font baseline table</dfn>. 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'.</p>
- <p>The offset values in the baseline table are in "design
- units" which means fractional units of the EM. CSS calls these
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#unitsperem">"units-per-em"</a>
- ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.3.4).
- Thus, the current <a>'font-size'</a> is used to determine
- the actual offset from the dominant baseline to the alternate
- baselines.</p>
- <p>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.</p>
- <p>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 <a href="text.html#ShiftDirection">shift
- direction</a>. Both offsets are computed by multiplying the
- baseline value from the baseline table times the appropriate
- font size value.</p>
- <p>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.</p>
- <p>The baseline-identifiers below are used in this
- specification. Some of these are determined by baseline-tables
- contained in a font
- <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#font-model">as described in XSL</a>
- ([<a href="refs.html#ref-XSL">XSL</a>], section 7.9.1). Others
- are computed from other font characteristics as described
- below.</p>
- <dl>
- <dt><b>alphabetic</b></dt>
- <dd>
- <p>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.</p>
- </dd>
- <dt><b>ideographic</b></dt>
- <dd>
- <p>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.</p>
- </dd>
- <dt><b>hanging</b></dt>
- <dd>
- <p>This identifies the baseline used by certain Indic
- scripts. These scripts include Devanagari, Gurmukhi and
- Bengali.</p>
- </dd>
- <dt><b>mathematical</b></dt>
- <dd>
- <p>This identifies the baseline used by mathematical
- symbols.</p>
- </dd>
- <dt><b>central</b></dt>
- <dd>
- <p>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.</p>
- <blockquote>
- <b>NOTE:</b>
- <p>For ideographic fonts, this baseline is often used to
- align the glyphs; it is an alternative to the ideographic
- baseline.</p>
- </blockquote>
- </dd>
- <dt><b>middle</b></dt>
- <dd>
- <p>This identifies a baseline that is offset from the
- alphabetic baseline in the <b>shift-direction</b> 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.</p>
- </dd>
- <dt><b>text-before-edge</b></dt>
- <dd>
- <p>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.</p>
- <blockquote>
- <b>NOTE:</b>
- <p>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 <b>shift-direction</b> 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.</p>
- </blockquote>
- </dd>
- <dt><b>text-after-edge</b></dt>
- <dd>
- <p>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.</p>
- <blockquote>
- <b>NOTE:</b>
- <p>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.</p>
- </blockquote>
- </dd>
- </dl>
- <p>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:</p>
- <dl>
- <dt><b>before-edge</b></dt>
- <dd>For SVG, this is equivalent to
- <b>text-before-edge</b>.</dd>
- <dt><b>after-edge</b></dt>
- <dd>For SVG, this is equivalent to
- <b>text-after-edge</b>.</dd>
- </dl>
- <p>There are also four baselines that are defined only for
- horizontal writing-modes.</p>
- <dl>
- <dt><b>top</b></dt>
- <dd>
- <p>This baseline is the same as the "before-edge" baseline
- in a horizontal writing-mode and is undefined in a vertical
- writing mode.</p>
- </dd>
- <dt id="TextTopBaselineDefinition"><b>text-top</b></dt>
- <dd>
- <p>This baseline is the same as the "text-before-edge"
- baseline in a horizontal writing-mode and is undefined in a
- vertical writing mode.</p>
- </dd>
- <dt><b>bottom</b></dt>
- <dd>
- <p>This baseline is the same as the "after-edge" baseline
- in a horizontal writing-mode and is undefined in a vertical
- writing mode.</p>
- </dd>
- <dt id="TextBottomBaselineDefinition"><b>text-bottom</b></dt>
- <dd>
- <p>This baseline is the same as the "text-after-edge"
- baseline in a horizontal writing-mode and is undefined in a
- vertical writing mode.</p>
- </dd>
- </dl>
- <p>The baseline-alignment properties follow.</p>
+<p>An overview of baseline alignment and baseline tables can be
+found above in <a href="text.html#FontsTablesBaselines">Fonts,
+font tables and baselines</a>.</p>
+
+<p>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.</p>
+
+<p>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 [<a
+href="http://www.microsoft.com/typography/otspec/">OPENTYPE</a>]
+fonts have a Baseline table (BASE) [<a
+href="http://www.microsoft.com/typography/otspec/base.htm">OPENTYPE-BASETABLE</a>]
+that specifies the offsets of the alternative baselines from
+the current baseline.</p>
+
+<p>SVG uses a similar baseline table model that assumes one
+script (at one font-size) is the "dominant run" during
+processing of a <a>'text'</a> 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
+<dfn>dominant baseline</dfn>. 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.</p>
+
+<p>The baseline table established at the start of processing of
+a <a>'text'</a> element is called the
+<dfn>dominant baseline table</dfn>.</p>
+
+<p>Because the value of the <a>'font-family'</a> property is a list
+of fonts, to insure a consistent choice of baseline table we
+define the <em>nominal font</em> 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.</p>
+
+<p>The value of the <a>'font-size'</a> property on the <a>'text'</a> element establishes the
+<dfn>dominant baseline table font size</dfn>.</p>
+<p>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 <a
+href="text.html#AlignmentBaselineProperty"><span
+class="property">'alignment-baseline'</span></a> property uses
+the baseline identifier associated with the given glyph.
+Alternate values for <a
+href="text.html#AlignmentBaselineProperty"><span
+class="property">'alignment-baseline'</span></a> can be useful
+for glyphs such as a "*" which are ambiguous with respect to
+script membership.</p>
+
+<p>The model assumes that the font from which the glyph is
+drawn also has a baseline table, the
+<dfn>font baseline table</dfn>. 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'.</p>
+
+<p>The offset values in the baseline table are in "design
+units" which means fractional units of the EM. CSS calls these
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#unitsperem">"units-per-em"</a>
+([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.3.4).
+Thus, the current <a>'font-size'</a> is used to determine
+the actual offset from the dominant baseline to the alternate
+baselines.</p>
+
+<p>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.</p>
+
+<p>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 <a href="text.html#ShiftDirection">shift
+direction</a>. Both offsets are computed by multiplying the
+baseline value from the baseline table times the appropriate
+font size value.</p>
+
+<p>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.</p>
+
+<p>The baseline-identifiers below are used in this
+specification. Some of these are determined by baseline-tables
+contained in a font
+<a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#font-model">as described in XSL</a>
+([<a href="refs.html#ref-XSL">XSL</a>], section 7.9.1). Others
+are computed from other font characteristics as described
+below.</p>
+
+<dl>
+ <dt><b>alphabetic</b></dt>
+ <dd>
+ <p>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.</p>
+ </dd>
+ <dt><b>ideographic</b></dt>
+ <dd>
+ <p>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.</p>
+ </dd>
+ <dt><b>hanging</b></dt>
+ <dd>
+ <p>This identifies the baseline used by certain Indic
+ scripts. These scripts include Devanagari, Gurmukhi and
+ Bengali.</p>
+ </dd>
+ <dt><b>mathematical</b></dt>
+ <dd>
+ <p>This identifies the baseline used by mathematical
+ symbols.</p>
+ </dd>
+ <dt><b>central</b></dt>
+ <dd>
+ <p>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.</p>
+ <blockquote>
+ <b>NOTE:</b>
+ <p>For ideographic fonts, this baseline is often used to
+ align the glyphs; it is an alternative to the ideographic
+ baseline.</p>
+ </blockquote>
+ </dd>
+ <dt><b>middle</b></dt>
+ <dd>
+ <p>This identifies a baseline that is offset from the
+ alphabetic baseline in the <b>shift-direction</b> 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.</p>
+ </dd>
+ <dt><b>text-before-edge</b></dt>
+ <dd>
+ <p>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.</p>
+ <blockquote>
+ <b>NOTE:</b>
+ <p>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 <b>shift-direction</b> 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.</p>
+ </blockquote>
+ </dd>
+ <dt><b>text-after-edge</b></dt>
+ <dd>
+ <p>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.</p>
+ <blockquote>
+ <b>NOTE:</b>
+ <p>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.</p>
+ </blockquote>
+ </dd>
+</dl>
+<p>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:</p>
+<dl>
+ <dt><b>before-edge</b></dt>
+ <dd>For SVG, this is equivalent to
+ <b>text-before-edge</b>.</dd>
+ <dt><b>after-edge</b></dt>
+ <dd>For SVG, this is equivalent to
+ <b>text-after-edge</b>.</dd>
+</dl>
+<p>There are also four baselines that are defined only for
+horizontal writing-modes.</p>
+<dl>
+ <dt><b>top</b></dt>
+ <dd>
+ <p>This baseline is the same as the "before-edge" baseline
+ in a horizontal writing-mode and is undefined in a vertical
+ writing mode.</p>
+ </dd>
+ <dt id="TextTopBaselineDefinition"><b>text-top</b></dt>
+ <dd>
+ <p>This baseline is the same as the "text-before-edge"
+ baseline in a horizontal writing-mode and is undefined in a
+ vertical writing mode.</p>
+ </dd>
+ <dt><b>bottom</b></dt>
+ <dd>
+ <p>This baseline is the same as the "after-edge" baseline
+ in a horizontal writing-mode and is undefined in a vertical
+ writing mode.</p>
+ </dd>
+ <dt id="TextBottomBaselineDefinition"><b>text-bottom</b></dt>
+ <dd>
+ <p>This baseline is the same as the "text-after-edge"
+ baseline in a horizontal writing-mode and is undefined in a
+ vertical writing mode.</p>
+ </dd>
+</dl>
+<p>The baseline-alignment properties follow.</p>
<div class="propdef">
<dl>
@@ -2393,135 +2354,149 @@
</dd>
</dl>
</div>
- <p>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, <span class='prop-value'>auto</span>, would
- give an undesired result, this property can be used to
- explicitly set the desire scaled-baseline-table.</p>
- <p>Values for the property have the following meaning:</p>
- <dl>
- <dt><span class="attr-value">auto</span></dt>
- <dd>
- <p>If this property occurs on a <a>'text'</a> element, then the
- computed value depends on the value of the <a>'writing-mode'</a> 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'.</p>
- <p>If this property occurs on a <a>'tspan'</a>, <a>'tref'</a>,
- <a>'altGlyph'</a> or <a>'textPath'</a> element, then
- the dominant-baseline and the baseline-table components
- remain the same as those of the parent <a>text content element</a>. If the computed <a>'baseline-shift'</a> value
- actually shifts the baseline, then the baseline-table
- font-size component is set to the value of the <a>'font-size'</a> property on the
- element on which the <a>'dominant-baseline'</a> property
- occurs, otherwise the baseline-table font-size remains the
- same as that of the element. If there is no parent <a>text content element</a>, the scaled-baseline-table value is constructed
- as above for <a>'text'</a> elements.</p>
- </dd>
- <dt><span class="attr-value">use-script</span></dt>
- <dd>The dominant-baseline and the baseline-table components
- are set by determining the predominant script of the
- character data content. The <a>'writing-mode'</a>, 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 <a>'font-size'</a> property on the
- element on which the <a>'dominant-baseline'</a> property
- occurs.</dd>
- <dt><span class="attr-value">no-change</span></dt>
- <dd>The dominant-baseline, the baseline-table, and the
- baseline-table font-size remain the same as that of the
- parent <a>text content element</a>.</dd>
- <dt><span class="attr-value">reset-size</span></dt>
- <dd>The dominant-baseline and the baseline-table remain the
- same, but the baseline-table font-size is changed to the
- value of the <a>'font-size'</a> property on this
- element. This re-scales the baseline-table for the current <a>'font-size'</a>.</dd>
- <dt><span class="attr-value">ideographic</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">alphabetic</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">hanging</span></dt>
- <dd>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
- <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">mathematical</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">central</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">middle</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.</dd>
- <dt><span class="attr-value">text-after-edge</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.<br />
- <br />
- NOTE: 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.</dd>
- <dt><span class="attr-value">text-before-edge</span></dt>
- <dd>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 <a>'font-size'</a> property on this
- element.<br />
- <br />
- NOTE: 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.</dd>
- </dl>
- <p>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.</p>
+
+<p>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, <span class='prop-value'>auto</span>, would
+give an undesired result, this property can be used to
+explicitly set the desire scaled-baseline-table.</p>
+<p>Values for the property have the following meaning:</p>
+
+<dl>
+ <dt><span class="attr-value">auto</span></dt>
+ <dd>
+ <p>If this property occurs on a <a>'text'</a> element, then the
+ computed value depends on the value of the <a>'writing-mode'</a> 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'.</p>
+ <p>If this property occurs on a <a>'tspan'</a>, <a>'tref'</a>,
+ <a>'altGlyph'</a> or <a>'textPath'</a> element, then
+ the dominant-baseline and the baseline-table components
+ remain the same as those of the parent <a>text content element</a>. If the computed <a>'baseline-shift'</a> value
+ actually shifts the baseline, then the baseline-table
+ font-size component is set to the value of the <a>'font-size'</a> property on the
+ element on which the <a>'dominant-baseline'</a> property
+ occurs, otherwise the baseline-table font-size remains the
+ same as that of the element. If there is no parent <a>text content element</a>, the scaled-baseline-table value is constructed
+ as above for <a>'text'</a> elements.</p>
+ </dd>
+
+ <dt><span class="attr-value">use-script</span></dt>
+ <dd>The dominant-baseline and the baseline-table components
+ are set by determining the predominant script of the
+ character data content. The <a>'writing-mode'</a>, 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 <a>'font-size'</a> property on the
+ element on which the <a>'dominant-baseline'</a> property
+ occurs.</dd>
+
+ <dt><span class="attr-value">no-change</span></dt>
+ <dd>The dominant-baseline, the baseline-table, and the
+ baseline-table font-size remain the same as that of the
+ parent <a>text content element</a>.</dd>
+
+ <dt><span class="attr-value">reset-size</span></dt>
+ <dd>The dominant-baseline and the baseline-table remain the
+ same, but the baseline-table font-size is changed to the
+ value of the <a>'font-size'</a> property on this
+ element. This re-scales the baseline-table for the current <a>'font-size'</a>.</dd>
+
+ <dt><span class="attr-value">ideographic</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">alphabetic</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">hanging</span></dt>
+ <dd>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
+ <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">mathematical</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">central</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">middle</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.</dd>
+
+ <dt><span class="attr-value">text-after-edge</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.<br />
+ <br />
+ NOTE: 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.</dd>
+
+ <dt><span class="attr-value">text-before-edge</span></dt>
+ <dd>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 <a>'font-size'</a> property on this
+ element.<br />
+ <br />
+ NOTE: 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.</dd>
+</dl>
+
+<p>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.</p>
<div class="propdef">
<dl>
@@ -2567,57 +2542,71 @@
</dd>
</dl>
</div>
- <p>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
- <b>block-progression-direction</b> is the position of the
- "ideographic" baseline in the baseline-table of the object
- being aligned.</p>
- <p>Values have the following meanings:</p>
- <dl>
- <dt><b>auto</b></dt>
- <dd>The value is the dominant-baseline of the script to which
- the character belongs - i.e., use the dominant-baseline of
- the parent.</dd>
- <dt><b>baseline</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the dominant-baseline of the parent <a>text content element</a>.</dd>
- <dt><b>before-edge</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "before-edge" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>text-before-edge</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "text-before-edge" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>middle</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "middle" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>central</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "central" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>after-edge</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "after-edge" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>text-after-edge</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "text-after-edge" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>ideographic</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "ideographic" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>alphabetic</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "alphabetic" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>hanging</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "hanging" baseline of the parent <a>text content element</a>.</dd>
- <dt><b>mathematical</b></dt>
- <dd>The alignment-point of the object being aligned is
- aligned with the "mathematical" baseline of the parent <a>text content element</a>.</dd>
- </dl>
+
+<p>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
+<b>block-progression-direction</b> is the position of the
+"ideographic" baseline in the baseline-table of the object
+being aligned.</p>
+
+<p>Values have the following meanings:</p>
+
+<dl>
+ <dt><b>auto</b></dt>
+ <dd>The value is the dominant-baseline of the script to which
+ the character belongs - i.e., use the dominant-baseline of
+ the parent.</dd>
+
+ <dt><b>baseline</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the dominant-baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>before-edge</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "before-edge" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>text-before-edge</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "text-before-edge" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>middle</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "middle" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>central</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "central" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>after-edge</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "after-edge" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>text-after-edge</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "text-after-edge" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>ideographic</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "ideographic" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>alphabetic</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "alphabetic" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>hanging</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "hanging" baseline of the parent <a>text content element</a>.</dd>
+
+ <dt><b>mathematical</b></dt>
+ <dd>The alignment-point of the object being aligned is
+ aligned with the "mathematical" baseline of the parent <a>text content element</a>.</dd>
+</dl>
<div class="propdef">
<dl>
@@ -2665,88 +2654,98 @@
</dd>
</dl>
</div>
- <p>The <a>'baseline-shift'</a> property
- allows repositioning of the dominant-baseline relative to the
- dominant-baseline of the parent <a>text content element</a>. 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 <a>text content element</a>, the sub- or superscript offset from the nominal
- font of the parent <a>text content element</a>, percent of the "line-height" of the parent <a>text content element</a> or an absolute value.</p>
- <p>In SVG, the <a>'baseline-shift'</a>
- property represents a supplemental adjustment to the baseline
- tables. The <a>'baseline-shift'</a>
- 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.</p>
- <p><a>'baseline-shift'</a> properties
- can nest. Each nested <a>'baseline-shift'</a> is added to previous
- baseline shift values.</p>
- <p>Values for the property have the following meaning:</p>
- <dl>
- <dt><strong>baseline</strong></dt>
- <dd>There is no baseline shift; the dominant-baseline remains
- in its original position.</dd>
- <dt><strong>sub</strong></dt>
- <dd>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.</dd>
- <dt><strong>super</strong></dt>
- <dd>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.</dd>
- <dt><strong><percentage></strong></dt>
- <dd>The computed value of the property is this percentage
- multiplied by the computed "line-height" of the <a>'text'</a> element. The
- dominant-baseline is shifted in the <a
- href="text.html#ShiftDirection">shift direction</a> (positive
- value) or opposite to the <a
- href="text.html#ShiftDirection">shift direction</a> (negative
- value) of the parent <a>text content element</a> by the computed value. A value of "0%" is
- equivalent to "baseline".</dd>
- <dt><strong><length></strong></dt>
- <dd>The dominant-baseline is shifted in the <a
- href="text.html#ShiftDirection">shift direction</a> (positive
- value) or opposite to the <a
- href="text.html#ShiftDirection">shift direction</a> (negative
- value) of the parent <a>text content element</a> by the <length> value. A value of "0cm" is
- equivalent to "baseline".</dd>
- </dl>
+
+<p>The <a>'baseline-shift'</a> property
+allows repositioning of the dominant-baseline relative to the
+dominant-baseline of the parent <a>text content element</a>. 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 <a>text content element</a>, the sub- or superscript offset from the nominal
+font of the parent <a>text content element</a>, percent of the "line-height" of the parent <a>text content element</a> or an absolute value.</p>
+
+<p>In SVG, the <a>'baseline-shift'</a>
+property represents a supplemental adjustment to the baseline
+tables. The <a>'baseline-shift'</a>
+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.</p>
+
+<p><a>'baseline-shift'</a> properties
+can nest. Each nested <a>'baseline-shift'</a> is added to previous
+baseline shift values.</p>
+
+<p>Values for the property have the following meaning:</p>
+
+<dl>
+ <dt><strong>baseline</strong></dt>
+ <dd>There is no baseline shift; the dominant-baseline remains
+ in its original position.</dd>
+
+ <dt><strong>sub</strong></dt>
+ <dd>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.</dd>
+
+ <dt><strong>super</strong></dt>
+ <dd>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.</dd>
+
+ <dt><strong><percentage></strong></dt>
+ <dd>The computed value of the property is this percentage
+ multiplied by the computed "line-height" of the <a>'text'</a> element. The
+ dominant-baseline is shifted in the <a
+ href="text.html#ShiftDirection">shift direction</a> (positive
+ value) or opposite to the <a
+ href="text.html#ShiftDirection">shift direction</a> (negative
+ value) of the parent <a>text content element</a> by the computed value. A value of "0%" is
+ equivalent to "baseline".</dd>
+
+ <dt><strong><length></strong></dt>
+ <dd>The dominant-baseline is shifted in the <a
+ href="text.html#ShiftDirection">shift direction</a> (positive
+ value) or opposite to the <a
+ href="text.html#ShiftDirection">shift direction</a> (negative
+ value) of the parent <a>text content element</a> by the <length> value. A value of "0cm" is
+ equivalent to "baseline".</dd>
+</dl>
<h2 id="FontPropertiesUsedBySVG">Font selection properties</h2>
- <p>SVG uses the following font specification properties. Except
- for any additional information provided in this specification,
- the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-specification">normative definition of these properties</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], chapter section 15.2).
- Any SVG-specific notes about these properties are contained in
- the descriptions below.</p>
- <p>Note also <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/about.html#property-defs">the rules for expressing the syntax of CSS property values</a>
- ([<a href="refs.html#ref-CSS2">CSS2</a>], section 1.3.2).</p>
+<p>SVG uses the following font specification properties. Except
+for any additional information provided in this specification,
+the <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-specification">normative definition of these properties</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], chapter section 15.2).
+Any SVG-specific notes about these properties are contained in
+the descriptions below.</p>
+<p>Note also <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/about.html#property-defs">the rules for expressing the syntax of CSS property values</a>
+([<a href="refs.html#ref-CSS2">CSS2</a>], section 1.3.2).</p>
+
<div class="propdef">
<dl>
<dt id="FontFamilyProperty"><span class="propdef-title property">'font-family'</span></dt>
@@ -2792,14 +2791,15 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-family">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.2).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-family">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.2).</p>
<div class="propdef">
<dl>
@@ -2843,11 +2843,12 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-style">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-style">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
<div class="propdef">
<dl>
@@ -2891,12 +2892,13 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-variant">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-variant">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
<div class="propdef">
<dl>
@@ -2943,12 +2945,13 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-weight">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-weight">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
<div class="propdef">
<dl>
@@ -2996,11 +2999,12 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-stretch">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-stretch">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.3).</p>
<div class="propdef">
<dl>
@@ -3047,27 +3051,30 @@
</dd>
</dl>
</div>
- <p>This property refers to the size of the font from baseline
- to baseline when multiple lines of text are set solid in a
- multiline layout environment. For SVG, if a <span
- class="prop-value"><length></span> is provided without a
- unit identifier (e.g., an unqualified number such as <span
- class="attr-value">128</span>), the SVG user agent processes
- the <span class="prop-value"><length></span> as a height
- value in the current user coordinate system.</p>
- <p>If a <span class="prop-value"><length></span> is
- provided with one of the <a
- href="coords.html#Units">unit identifiers</a> (e.g.,
- <span class="attr-value">12pt</span> or <span
- class="attr-value">10%</span>), then the SVG user agent
- converts the <span class="prop-value"><length></span>
- into a corresponding value in the current user coordinate
- system by applying the rules described in <a
- href="coords.html#Units">Units</a>.</p>
- <p>Except for any additional information provided in this
- specification, the
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-size">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.4).</p>
+
+<p>This property refers to the size of the font from baseline
+to baseline when multiple lines of text are set solid in a
+multiline layout environment. For SVG, if a <span
+class="prop-value"><length></span> is provided without a
+unit identifier (e.g., an unqualified number such as <span
+class="attr-value">128</span>), the SVG user agent processes
+the <span class="prop-value"><length></span> as a height
+value in the current user coordinate system.</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided with one of the <a
+href="coords.html#Units">unit identifiers</a> (e.g.,
+<span class="attr-value">12pt</span> or <span
+class="attr-value">10%</span>), then the SVG user agent
+converts the <span class="prop-value"><length></span>
+into a corresponding value in the current user coordinate
+system by applying the rules described in <a
+href="coords.html#Units">Units</a>.</p>
+
+<p>Except for any additional information provided in this
+specification, the
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-size">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.4).</p>
<div class="propdef">
<dl>
@@ -3111,12 +3118,13 @@
</dd>
</dl>
</div>
- <p>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
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-size-adjust">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.4).</p>
+
+<p>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
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font-size-adjust">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.4).</p>
<div class="propdef">
<dl>
@@ -3173,39 +3181,43 @@
</dd>
</dl>
</div>
- <p>Shorthand property for setting <a>'font-style'</a>, <a>'font-variant'</a>,
- <a>'font-weight'</a>, <a>'font-size'</a>, <span class='property'>'line-height'</span> and <a>'font-family'</a>.
- The <span class='property'>'line-height'</span> property has no effect on text layout in SVG.
- For the purposes of the <a>'font property'</a>
- property, <span class='property'>'line-height'</span> is assumed to be equal to the value of
- the <a>'font-size'</a> property. <a
- href="conform.html#ConformingSVGViewers">Conforming SVG
- Viewers</a> 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.</p>
- <p>Except for any additional information provided in this
- specification, the
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.5).</p>
+
+<p>Shorthand property for setting <a>'font-style'</a>, <a>'font-variant'</a>,
+<a>'font-weight'</a>, <a>'font-size'</a>, <span class='property'>'line-height'</span> and <a>'font-family'</a>.
+The <span class='property'>'line-height'</span> property has no effect on text layout in SVG.
+For the purposes of the <a>'font property'</a>
+property, <span class='property'>'line-height'</span> is assumed to be equal to the value of
+the <a>'font-size'</a> property. <a
+href="conform.html#ConformingSVGViewers">Conforming SVG
+Viewers</a> 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.</p>
+
+<p>Except for any additional information provided in this
+specification, the
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#propdef-font">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 15.2.5).</p>
<h2 id="SpacingProperties">Spacing properties</h2>
- <p>Three properties affect the space between characters and
- words:</p>
- <ul>
- <li><a>'kerning'</a> indicates whether the
- user agent should adjust inter-glyph spacing based on kerning
- tables that are included in the relevant font (i.e., enable
- auto-kerning) or instead disable auto-kerning and instead set
- inter-character spacing to a specific length (typically,
- zero).</li>
- <li><a>'letter-spacing'</a> indicates an
- amount of space that is to be added between text characters
- supplemental to any spacing due to the <a>'kerning'</a> property.</li>
- <li><a>'word-spacing'</a> indicates the
- spacing behavior between words.</li>
- </ul>
+<p>Three properties affect the space between characters and words:</p>
+
+<ul>
+ <li><a>'kerning'</a> indicates whether the
+ user agent should adjust inter-glyph spacing based on kerning
+ tables that are included in the relevant font (i.e., enable
+ auto-kerning) or instead disable auto-kerning and instead set
+ inter-character spacing to a specific length (typically,
+ zero).</li>
+
+ <li><a>'letter-spacing'</a> indicates an
+ amount of space that is to be added between text characters
+ supplemental to any spacing due to the <a>'kerning'</a> property.</li>
+
+ <li><a>'word-spacing'</a> indicates the
+ spacing behavior between words.</li>
+</ul>
<div class="propdef">
<dl>
@@ -3249,36 +3261,41 @@
</dd>
</dl>
</div>
- <p>The value of <span class="prop-value">auto</span> indicates
- that the user agent should adjust inter-glyph spacing based on
- kerning tables that are included in the font that will be used
- (i.e., enable auto-kerning).</p>
- <p>If a <span class="prop-value"><length></span> is
- provided, then auto-kerning is disabled. Instead,
- inter-character spacing is set to the given <span
- class="prop-value"><length></span>. The most common
- scenario, other than <span class="prop-value">auto</span>, is
- to set <a>'kerning'</a> to a value of
- <span class="prop-value">0</span> so that auto-kerning is
- disabled.</p>
- <p>If a <span class="prop-value"><length></span> is
- provided without a unit identifier (e.g., an unqualified number
- such as <span class="attr-value">128</span>), the SVG user
- agent processes the <span
- class="prop-value"><length></span> as a width value in
- the current user coordinate system.</p>
- <p>If a <span class="prop-value"><length></span> is
- provided with one of the <a
- href="coords.html#Units">unit identifiers</a> (e.g.,
- <span class="attr-value">.25em</span> or <span
- class="attr-value">1%</span>), then the SVG user agent converts
- the <span class="prop-value"><length></span> into a
- corresponding value in the current user coordinate system by
- applying the rules described in <a
- href="coords.html#Units">Units</a>.</p>
- <p>When a <span class="prop-value"><length></span> is
- provided, its value is added to the inter-character spacing
- value specified by the <a>'letter-spacing'</a> property.</p>
+
+<p>The value of <span class="prop-value">auto</span> indicates
+that the user agent should adjust inter-glyph spacing based on
+kerning tables that are included in the font that will be used
+(i.e., enable auto-kerning).</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided, then auto-kerning is disabled. Instead,
+inter-character spacing is set to the given <span
+class="prop-value"><length></span>. The most common
+scenario, other than <span class="prop-value">auto</span>, is
+to set <a>'kerning'</a> to a value of
+<span class="prop-value">0</span> so that auto-kerning is
+disabled.</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided without a unit identifier (e.g., an unqualified number
+such as <span class="attr-value">128</span>), the SVG user
+agent processes the <span
+class="prop-value"><length></span> as a width value in
+the current user coordinate system.</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided with one of the <a
+href="coords.html#Units">unit identifiers</a> (e.g.,
+<span class="attr-value">.25em</span> or <span
+class="attr-value">1%</span>), then the SVG user agent converts
+the <span class="prop-value"><length></span> into a
+corresponding value in the current user coordinate system by
+applying the rules described in <a
+href="coords.html#Units">Units</a>.</p>
+
+<p>When a <span class="prop-value"><length></span> is
+provided, its value is added to the inter-character spacing
+value specified by the <a>'letter-spacing'</a> property.</p>
<div class="propdef">
<dl>
@@ -3322,27 +3339,31 @@
</dd>
</dl>
</div>
- <p>This property specifies spacing behavior between text
- characters supplemental to any spacing due to the <a>'kerning'</a> property.</p>
- <p>For SVG, if a <span class="prop-value"><length></span>
- is provided without a unit identifier (e.g., an unqualified
- number such as <span class="attr-value">128</span>), the SVG
- user agent processes the <span
- class="prop-value"><length></span> as a width value in
- the current user coordinate system.</p>
- <p>If a <span class="prop-value"><length></span> is
- provided with one of the <a
- href="coords.html#Units">unit identifiers</a> (e.g.,
- <span class="attr-value">.25em</span> or <span
- class="attr-value">1%</span>), then the SVG user agent converts
- the <span class="prop-value"><length></span> into a
- corresponding value in the current user coordinate system by
- applying the rules described in <a
- href="coords.html#Units">Units</a>.</p>
- <p>Except for any additional information provided in this
- specification, the
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-letter-spacing">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.4).</p>
+
+<p>This property specifies spacing behavior between text
+characters supplemental to any spacing due to the <a>'kerning'</a> property.</p>
+
+<p>For SVG, if a <span class="prop-value"><length></span>
+is provided without a unit identifier (e.g., an unqualified
+number such as <span class="attr-value">128</span>), the SVG
+user agent processes the <span
+class="prop-value"><length></span> as a width value in
+the current user coordinate system.</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided with one of the <a
+href="coords.html#Units">unit identifiers</a> (e.g.,
+<span class="attr-value">.25em</span> or <span
+class="attr-value">1%</span>), then the SVG user agent converts
+the <span class="prop-value"><length></span> into a
+corresponding value in the current user coordinate system by
+applying the rules described in <a
+href="coords.html#Units">Units</a>.</p>
+
+<p>Except for any additional information provided in this
+specification, the
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-letter-spacing">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.4).</p>
<div class="propdef">
<dl>
@@ -3386,26 +3407,29 @@
</dd>
</dl>
</div>
- <p>This property specifies spacing behavior between words. For
- SVG, if a <span class="prop-value"><length></span> is
- provided without a unit identifier (e.g., an unqualified number
- such as <span class="attr-value">128</span>), the SVG user
- agent processes the <span
- class="prop-value"><length></span> as a width value in
- the current user coordinate system.</p>
- <p>If a <span class="prop-value"><length></span> is
- provided with one of the <a
- href="coords.html#Units">unit identifiers</a> (e.g.,
- <span class="attr-value">.25em</span> or <span
- class="attr-value">1%</span>), then the SVG user agent converts
- the <span class="prop-value"><length></span> into a
- corresponding value in the current user coordinate system by
- applying the rules described in <a
- href="coords.html#Units">Units</a>.</p>
- <p>Except for any additional information provided in this
- specification, the
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-word-spacing">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.4).</p>
+
+<p>This property specifies spacing behavior between words. For
+SVG, if a <span class="prop-value"><length></span> is
+provided without a unit identifier (e.g., an unqualified number
+such as <span class="attr-value">128</span>), the SVG user
+agent processes the <span
+class="prop-value"><length></span> as a width value in
+the current user coordinate system.</p>
+
+<p>If a <span class="prop-value"><length></span> is
+provided with one of the <a
+href="coords.html#Units">unit identifiers</a> (e.g.,
+<span class="attr-value">.25em</span> or <span
+class="attr-value">1%</span>), then the SVG user agent converts
+the <span class="prop-value"><length></span> into a
+corresponding value in the current user coordinate system by
+applying the rules described in <a
+href="coords.html#Units">Units</a>.</p>
+
+<p>Except for any additional information provided in this
+specification, the
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-word-spacing">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.4).</p>
<h2 id="TextDecorationProperties">Text decoration</h2>
@@ -3452,71 +3476,75 @@
</dd>
</dl>
</div>
- <p>This property describes decorations that are added to the
- text of an element. <a
- href="conform.html#ConformingSVGViewers">Conforming SVG
- Viewers</a> are not required to support the
- <strong>blink</strong> value.</p>
- <p>Except for any additional information provided in this
- specification, the
- <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-text-decoration">normative definition of the property</a>
- is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.3.1).</p>
- <p>The CSS2 specification defines the
- behavior of the <a>'text-decoration'</a> property using the
- terminology "block-level elements" and "inline elements". For
- the purposes of the <a>'text-decoration'</a> property and SVG, a
- <a>'text'</a> element represents a
- block-level element and any of the potential children of a <a>'text'</a>
- element (e.g., a <a>'tspan'</a>) represent inline elements.</p>
- <p>Also, the CSS2 definition of <a>'text-decoration'</a> 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 <a
- href="painting.html">Painting: Filling, Stroking and Marker
- Symbols</a>) to both the interior (i.e., the "fill") and the
- outline (i.e., the "stroke") of text, for SVG the <a>'text-decoration'</a> property is defined
- such that, for an element which has a specified value for the
- <a>'text-decoration'</a> 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 <a>'text-decoration'</a> property is
- specified on a descendant, then that overrides the
- ancestor.</p>
- <p>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:</p>
- <ul>
- <li>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.</li>
- <li>Line-through should be drawn after the text is filled and
- stroked; thus, the line-through is rendered on top of the
- text.</li>
- </ul>
- <a id="ExampleTextDecoration01"
- name="ExampleTextDecoration01"></a>
- <p><span class="example-ref">Example textdecoration01</span>
- provides examples for <a>'text-decoration'</a>. The first line of
- text has no value for <a>'text-decoration'</a>, so the initial
- value of <span class="prop-value">text-decoration:none</span>
- is used. The second line shows <span
- class="prop-value">text-decoration:line-through</span>. The
- third line shows <span
- class="prop-value">text-decoration:underline</span>. 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 <a>'text-decoration'</a> is specified. Since
- <a>'text-decoration'</a> is specified
- on the <a>'text'</a> element, all text within
- the <a>'text'</a> element has its
- underline rendered with the same fill and stroke properties as
- exist on the <a>'text'</a> 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 <a>'text-decoration'</a>; thus, its underline
- is rendered using the fill and stroke properties as the <a>'tspan'</a> element that surrounds
- the word "different" (i.e., yellow fill, darkgreen stroke):</p>
+
+<p>This property describes decorations that are added to the
+text of an element. <a
+href="conform.html#ConformingSVGViewers">Conforming SVG
+Viewers</a> are not required to support the
+<strong>blink</strong> value.</p>
+
+<p>Except for any additional information provided in this
+specification, the
+<a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#propdef-text-decoration">normative definition of the property</a>
+is in CSS2 ([<a href="refs.html#ref-CSS2">CSS2</a>], section 16.3.1).</p>
+
+<p>The CSS2 specification defines the
+behavior of the <a>'text-decoration'</a> property using the
+terminology "block-level elements" and "inline elements". For
+the purposes of the <a>'text-decoration'</a> property and SVG, a
+<a>'text'</a> element represents a
+block-level element and any of the potential children of a <a>'text'</a>
+element (e.g., a <a>'tspan'</a>) represent inline elements.</p>
+
+<p>Also, the CSS2 definition of <a>'text-decoration'</a> 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 <a
+href="painting.html">Painting: Filling, Stroking and Marker
+Symbols</a>) to both the interior (i.e., the "fill") and the
+outline (i.e., the "stroke") of text, for SVG the <a>'text-decoration'</a> property is defined
+such that, for an element which has a specified value for the
+<a>'text-decoration'</a> 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 <a>'text-decoration'</a> property is
+specified on a descendant, then that overrides the
+ancestor.</p>
+
+<p>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:</p>
+<ul>
+ <li>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.</li>
+ <li>Line-through should be drawn after the text is filled and
+ stroked; thus, the line-through is rendered on top of the
+ text.</li>
+</ul>
+
+<p id="ExampleTextDecoration01"><span class="example-ref">Example textdecoration01</span>
+provides examples for <a>'text-decoration'</a>. The first line of
+text has no value for <a>'text-decoration'</a>, so the initial
+value of <span class="prop-value">text-decoration:none</span>
+is used. The second line shows <span
+class="prop-value">text-decoration:line-through</span>. The
+third line shows <span
+class="prop-value">text-decoration:underline</span>. 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 <a>'text-decoration'</a> is specified. Since
+<a>'text-decoration'</a> is specified
+on the <a>'text'</a> element, all text within
+the <a>'text'</a> element has its
+underline rendered with the same fill and stroke properties as
+exist on the <a>'text'</a> 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 <a>'text-decoration'</a>; thus, its underline
+is rendered using the fill and stroke properties as the <a>'tspan'</a> element that surrounds
+the word "different" (i.e., yellow fill, darkgreen stroke):</p>
<edit:example href='images/text/textdecoration01.svg' name='textdecoration01' description="behavior of 'text-decoration' property" image='yes' link='yes'/>
@@ -3633,16 +3661,18 @@
yes.</span></dd>
</dl>
</div>
- <p>The path data coordinates within the referenced <a>'path'</a>
- element are assumed to be in the same coordinate system as the
- current <a>'text'</a> element, not in the coordinate system where
- the <a>'path'</a> element is defined. The <a>'transform'</a>
- attribute on the referenced <a>'path'</a> element represents a
- supplemental transformation relative to the current user coordinate
- system for the current <a>'text'</a> element, including any
- adjustments to the current user coordinate system due to a possible
- <a>'transform'</a> attribute on the current <a>'text'</a> element.
- For example, the following fragment of SVG content:</p>
+
+<p>The path data coordinates within the referenced <a>'path'</a>
+element are assumed to be in the same coordinate system as the
+current <a>'text'</a> element, not in the coordinate system where
+the <a>'path'</a> element is defined. The <a>'transform'</a>
+attribute on the referenced <a>'path'</a> element represents a
+supplemental transformation relative to the current user coordinate
+system for the current <a>'text'</a> element, including any
+adjustments to the current user coordinate system due to a possible
+<a>'transform'</a> attribute on the current <a>'text'</a> element.
+For example, the following fragment of SVG content:</p>
+
<pre>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
@@ -3659,7 +3689,9 @@
</text>
</svg>
</pre>
- <p>should have the same effect as the following:</p>
+
+<p>should have the same effect as the following:</p>
+
<pre>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
@@ -3675,247 +3707,273 @@
</g>
</svg>
</pre>
- <p>Note that the <code
- style="font-weight:bold; color:red">transform="translate(25,25)"</code>
- has no effect on the <a>'textPath'</a> element, whereas the
- <code
- style="font-weight:bold; color:blue">transform="rotate(45)"</code>
- applies to both the <a>'text'</a>
- and the use of the <a>'path'</a>
- element as the referenced shape for text on a path.</p>
-
- <p id="ExampleToap01"><span class="example-ref">Example toap01</span> provides a
- simple example of text on a path:</p>
+
+<p>Note that the <code
+style="font-weight:bold; color:red">transform="translate(25,25)"</code>
+has no effect on the <a>'textPath'</a> element, whereas the
+<code
+style="font-weight:bold; color:blue">transform="rotate(45)"</code>
+applies to both the <a>'text'</a>
+and the use of the <a>'path'</a>
+element as the referenced shape for text on a path.</p>
+
+<p id="ExampleToap01"><span class="example-ref">Example toap01</span> provides a
+simple example of text on a path:</p>
<edit:example href='images/text/toap01.svg' name='toap01' description="simple text on a path" image='yes' link='yes'/>
- <p id="ExampleToap02"><span class="example-ref">Example toap02</span> shows how <a>'tspan'</a> elements can be
- included within <a>'textPath'</a>
- 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 <a>'tspan/dy'</a> is used to lift the word "up"
- from the baseline.</p>
+<p id="ExampleToap02"><span class="example-ref">Example toap02</span> shows how <a>'tspan'</a> elements can be
+included within <a>'textPath'</a>
+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 <a>'tspan/dy'</a> is used to lift the word "up"
+from the baseline.</p>
<edit:example href='images/text/toap02.svg' name='toap02' description="tspan within textPath" image='yes' link='yes'/>
- <p id="ExampleToap03"><span class="example-ref">Example toap03</span> demonstrates
- the use of the <a>'startOffset'</a>
- attribute on the <a>'textPath'</a>
- 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 <a
- href="text.html#TextpathLayoutRules">text on a path layout
- rules</a>).</p>
+<p id="ExampleToap03"><span class="example-ref">Example toap03</span> demonstrates
+the use of the <a>'startOffset'</a>
+attribute on the <a>'textPath'</a>
+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 <a
+href="text.html#TextpathLayoutRules">text on a path layout
+rules</a>).</p>
<edit:example href='images/text/toap03.svg' name='toap03' description="text on a path with startOffset attribute" image='yes' link='yes'/>
<h3 id="TextpathLayoutRules">Text on a path layout rules</h3>
- <p>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 <a href="text.html#TextLayout">text layout</a> rules
- are applied to the hypothetical straight line segment and the
- result is mapped back onto the target path. Vertical and
- bidirectional <a href="text.html#TextLayout">text layout</a>
- rules also apply to text on a path.</p>
- <p>The <a href="text.html#ReferenceOrientation">reference
- orientation</a> 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.</p>
-
- <p id="ExampleToap04"><span class="example-ref">Example toap04</span> will be used
- to illustrate the particular layout rules for text on a path
- that supplement the basic <a href="text.html#TextLayout">text
- layout</a> rules for straight line horizontal or vertical
- text.</p>
+<p>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 <a href="text.html#TextLayout">text layout</a> rules
+are applied to the hypothetical straight line segment and the
+result is mapped back onto the target path. Vertical and
+bidirectional <a href="text.html#TextLayout">text layout</a>
+rules also apply to text on a path.</p>
+<p>The <a href="text.html#ReferenceOrientation">reference
+orientation</a> 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.</p>
+
+<p id="ExampleToap04"><span class="example-ref">Example toap04</span> will be used
+to illustrate the particular layout rules for text on a path
+that supplement the basic <a href="text.html#TextLayout">text
+layout</a> rules for straight line horizontal or vertical
+text.</p>
<edit:example href='images/text/toap04.svg' name='toap04' description="text on a path layout rules" image='yes' link='yes'/>
- <p>The following picture does an initial zoom in on the first
- glyph in the <a>'text'</a> element.</p>
- <img alt="Image that shows text on a path"
- src="images/text/toap05.png" width="288" height="91" />
- <p>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
- <dfn id="CharWidth">charwidth</dfn> (i.e., the amount which
- the current text position advances horizontally when the glyph
- is drawn using horizontal text layout).</p>
- <p>The next picture zooms in further to demonstrate the
- detailed layout rules.</p>
- <img alt="Image that shows text on a path"
- src="images/text/toap06.png" width="288" height="176" />
- <p>For left-to-right horizontal text layout along a path (i.e.,
- when the glyph orientation is perpendicular to the <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>),
- the layout rules are as follows:</p>
- <ul>
- <li>Determine the <dfn id="StartPointOnPath">startpoint-on-the-path</dfn> for the
- first glyph using attribute <a>'startOffset'</a> and property
- <a>'text-anchor'</a>. For <span class='prop-value'>text-anchor:start</span>,
- startpoint-on-the-path is the point on the path which
- represents the point on the path which is <a>'startOffset'</a> distance along the
- path from the start of the path, calculated using the user
- agent's <a href="paths.html#DistanceAlongAPath">distance
- along the path</a> algorithm. For <span class="prop-value">text-anchor:middle</span>,
- startpoint-on-the-path is the point on the path which
- represents the point on the path which is [ <a>'startOffset'</a> minus half of the
- total advance values for all of the glyphs in the <a>'textPath'</a> element ] distance
- along the path from the start of the path, calculated using
- the user agent's <a
- href="paths.html#DistanceAlongAPath">distance along the
- path</a> algorithm. For <span class="prop-value">text-anchor:end</span>,
- startpoint-on-the-path is the point on the path which
- represents the point on the path which is [ <a>'startOffset'</a> minus the total
- advance values for all of the glyphs in the <a>'textPath'</a> 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 <a>'tspan/dx'</a> attribute value on a <a>'tspan'</a> element. (In the
- picture above, the startpoint-on-the-path is the leftmost dot
- on the path.)</li>
- <li>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.)</li>
- <li>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 <a
- href="paths.html#DistanceAlongAPath">distance along the
- path</a> algorithm. This point is the <dfn id="EndPointOnPath">endpoint-on-the-path</dfn> for the
- glyph. (In the picture above, the endpoint-on-the-path for
- the glyph is the rightmost dot on the path.)</li>
- <li>Determine the <dfn id="MidPointOnPath">midpoint-on-the-path</dfn>, 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.)</li>
- <li>Determine the <dfn id="GlyphMidline">glyph-midline</dfn>, 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.)</li>
- <li>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.</li>
- <li>Align the glyph vertically relative to the
- midpoint-on-the-path based on property <a>'alignment-baseline'</a> and any
- specified values for attribute <a>'tspan/dy'</a> on a <a>'tspan'</a> element. In the
- example above, the <a>'alignment-baseline'</a> property is
- unspecified, so the initial value of <span class="prop-value">alignment-baseline:baseline</span>
- will be used. There are no <a>'tspan'</a> elements; thus, the
- baseline of the glyph is aligned to the
- midpoint-on-the-path.</li>
- <li>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 <a
- href="text.html#SpacingProperties">spacing properties</a> and
- <a>'tspan'</a> elements with values
- provided for attributes <a>'tspan/dx'</a> and <a>'tspan/dy'</a>. All adjustments are
- calculated as distance adjustments along the path, calculated
- using the user agent's <a
- href="paths.html#DistanceAlongAPath">distance along the
- path</a> algorithm.</li>
- <li>Glyphs whose midpoint-on-the-path are off either end of
- the path are not rendered.</li>
- <li>Continue rendering glyphs until there are no more
- glyphs.</li>
- </ul>
- <p>Comparable rules are used for top-to-bottom vertical text
- layout along a path (i.e., when the glyph orientation is
- parallel with the <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>),
- the layout rules are as follows:</p>
- <ul>
- <li>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 <a>'tspan/dy'</a> attribute value on a <a>'tspan'</a> element.</li>
- <li>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).</li>
- <li>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 <a
- href="paths.html#DistanceAlongAPath">distance along the
- path</a> algorithm. This point is the endpoint-on-the-path
- for the glyph.</li>
- <li>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.</li>
- <li>Determine the glyph-midline, which is the horizontal line
- in the glyph's coordinate system that goes through the
- glyph's y-axis midpoint.</li>
- <li>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.</li>
- <li>Align the glyph horizontally (where horizontal is
- relative to the glyph's coordinate system) relative to the
- midpoint-on-the-path based on property <a>'alignment-baseline'</a> and any
- specified values for attribute <a>'tspan/dx'</a> on a <a>'tspan'</a> element.</li>
- <li>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 <a
- href="text.html#SpacingProperties">spacing properties</a> and
- <a>'tspan'</a> elements with values
- provided for attributes <a>'tspan/dx'</a> and <a>'tspan/dy'</a>. All adjustments are
- calculated as distance adjustments along the path, calculated
- using the user agent's <a
- href="paths.html#DistanceAlongAPath">distance along the
- path</a> algorithm.</li>
- <li>Glyphs whose midpoint-on-the-path are off either end of
- the path are not rendered.</li>
- <li>Continue rendering glyphs until there are no more
- glyphs.</li>
- </ul>
- <p>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.</p>
- <p>When the <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
- is horizontal, then any <span class="attr-name">'x'</span> attributes on
- <a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements represent
- new absolute offsets along the path, thus providing explicit
- new values for startpoint-on-the-path. Any <span class="attr-name">'y'</span> attributes on
- <a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements are
- ignored. When the <a
- href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
- is vertical, then any <span class="attr-name">'y'</span> attributes on
- <a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements represent
- new absolute offsets along the path, thus providing explicit
- new values for startpoint-on-the-path. Any <span class="attr-name">'x'</span>
- attributes on <a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or
- <a>'altGlyph'</a> elements are ignored.</p>
+<p>The following picture does an initial zoom in on the first
+glyph in the <a>'text'</a> element.</p>
+<img alt="Image that shows text on a path"
+src="images/text/toap05.png" width="288" height="91" />
+
+<p>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
+<dfn id="CharWidth">charwidth</dfn> (i.e., the amount which
+the current text position advances horizontally when the glyph
+is drawn using horizontal text layout).</p>
+
+<p>The next picture zooms in further to demonstrate the
+detailed layout rules.</p>
+<img alt="Image that shows text on a path"
+src="images/text/toap06.png" width="288" height="176" />
+
+<p>For left-to-right horizontal text layout along a path (i.e.,
+when the glyph orientation is perpendicular to the <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>),
+the layout rules are as follows:</p>
+<ul>
+ <li>Determine the <dfn id="StartPointOnPath">startpoint-on-the-path</dfn> for the
+ first glyph using attribute <a>'startOffset'</a> and property
+ <a>'text-anchor'</a>. For <span class='prop-value'>text-anchor:start</span>,
+ startpoint-on-the-path is the point on the path which
+ represents the point on the path which is <a>'startOffset'</a> distance along the
+ path from the start of the path, calculated using the user
+ agent's <a href="paths.html#DistanceAlongAPath">distance
+ along the path</a> algorithm. For <span class="prop-value">text-anchor:middle</span>,
+ startpoint-on-the-path is the point on the path which
+ represents the point on the path which is [ <a>'startOffset'</a> minus half of the
+ total advance values for all of the glyphs in the <a>'textPath'</a> element ] distance
+ along the path from the start of the path, calculated using
+ the user agent's <a
+ href="paths.html#DistanceAlongAPath">distance along the
+ path</a> algorithm. For <span class="prop-value">text-anchor:end</span>,
+ startpoint-on-the-path is the point on the path which
+ represents the point on the path which is [ <a>'startOffset'</a> minus the total
+ advance values for all of the glyphs in the <a>'textPath'</a> 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 <a>'tspan/dx'</a> attribute value on a <a>'tspan'</a> element. (In the
+ picture above, the startpoint-on-the-path is the leftmost dot
+ on the path.)</li>
+
+ <li>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.)</li>
+
+ <li>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 <a
+ href="paths.html#DistanceAlongAPath">distance along the
+ path</a> algorithm. This point is the <dfn id="EndPointOnPath">endpoint-on-the-path</dfn> for the
+ glyph. (In the picture above, the endpoint-on-the-path for
+ the glyph is the rightmost dot on the path.)</li>
+
+ <li>Determine the <dfn id="MidPointOnPath">midpoint-on-the-path</dfn>, 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.)</li>
+
+ <li>Determine the <dfn id="GlyphMidline">glyph-midline</dfn>, 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.)</li>
+
+ <li>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.</li>
+
+ <li>Align the glyph vertically relative to the
+ midpoint-on-the-path based on property <a>'alignment-baseline'</a> and any
+ specified values for attribute <a>'tspan/dy'</a> on a <a>'tspan'</a> element. In the
+ example above, the <a>'alignment-baseline'</a> property is
+ unspecified, so the initial value of <span class="prop-value">alignment-baseline:baseline</span>
+ will be used. There are no <a>'tspan'</a> elements; thus, the
+ baseline of the glyph is aligned to the
+ midpoint-on-the-path.</li>
+
+ <li>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 <a
+ href="text.html#SpacingProperties">spacing properties</a> and
+ <a>'tspan'</a> elements with values
+ provided for attributes <a>'tspan/dx'</a> and <a>'tspan/dy'</a>. All adjustments are
+ calculated as distance adjustments along the path, calculated
+ using the user agent's <a
+ href="paths.html#DistanceAlongAPath">distance along the
+ path</a> algorithm.</li>
+
+ <li>Glyphs whose midpoint-on-the-path are off either end of
+ the path are not rendered.</li>
+
+ <li>Continue rendering glyphs until there are no more
+ glyphs.</li>
+</ul>
+
+<p>Comparable rules are used for top-to-bottom vertical text
+layout along a path (i.e., when the glyph orientation is
+parallel with the <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>),
+the layout rules are as follows:</p>
+
+<ul>
+ <li>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 <a>'tspan/dy'</a> attribute value on a <a>'tspan'</a> element.</li>
+
+ <li>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).</li>
+
+ <li>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 <a
+ href="paths.html#DistanceAlongAPath">distance along the
+ path</a> algorithm. This point is the endpoint-on-the-path
+ for the glyph.</li>
+
+ <li>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.</li>
+
+ <li>Determine the glyph-midline, which is the horizontal line
+ in the glyph's coordinate system that goes through the
+ glyph's y-axis midpoint.</li>
+
+ <li>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.</li>
+
+ <li>Align the glyph horizontally (where horizontal is
+ relative to the glyph's coordinate system) relative to the
+ midpoint-on-the-path based on property <a>'alignment-baseline'</a> and any
+ specified values for attribute <a>'tspan/dx'</a> on a <a>'tspan'</a> element.</li>
+
+ <li>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 <a
+ href="text.html#SpacingProperties">spacing properties</a> and
+ <a>'tspan'</a> elements with values
+ provided for attributes <a>'tspan/dx'</a> and <a>'tspan/dy'</a>. All adjustments are
+ calculated as distance adjustments along the path, calculated
+ using the user agent's <a
+ href="paths.html#DistanceAlongAPath">distance along the
+ path</a> algorithm.</li>
+
+ <li>Glyphs whose midpoint-on-the-path are off either end of
+ the path are not rendered.</li>
+
+ <li>Continue rendering glyphs until there are no more
+ glyphs.</li>
+</ul>
+
+<p>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.</p>
+
+<p>When the <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
+is horizontal, then any <span class="attr-name">'x'</span> attributes on
+<a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements represent
+new absolute offsets along the path, thus providing explicit
+new values for startpoint-on-the-path. Any <span class="attr-name">'y'</span> attributes on
+<a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements are
+ignored. When the <a
+href="text.html#SettingInlineProgressionDirection">inline-progression-direction</a>
+is vertical, then any <span class="attr-name">'y'</span> attributes on
+<a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or <a>'altGlyph'</a> elements represent
+new absolute offsets along the path, thus providing explicit
+new values for startpoint-on-the-path. Any <span class="attr-name">'x'</span>
+attributes on <a>'text'</a>, <a>'tspan'</a>, <a>'tref'</a> or
+<a>'altGlyph'</a> elements are ignored.</p>
</edit:with>
@@ -4254,11 +4312,10 @@
<p id="XMLSpaceAttribute">SVG supports the standard XML attribute
<a>'xml:space'</a> to specify the handling of white space characters
within a given <a>'text'</a> element's character data.
- Note that any child element of a <a>'text'</a> element may also
- have an <a>'xml:space'</a> attribute which will apply to that
- child element's text content.
-The SVG user
-agent has special processing rules associated with this attribute
+Note that any child element of a <a>'text'</a> element may also
+have an <a>'xml:space'</a> 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 [<a href="http://www.w3.org/TR/2008/REC-xml-20081126/">XML10</a>]
and any construction of a DOM.</p>
@@ -4370,10 +4427,10 @@
after the white space characters have been removed per the rules in this
section.</p>
-<p>
-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 <a href="http://www.unicode.org/faq/unsup_char.html">display of unsupported characters</a> [<a href="refs.html#ref-UNICODE">UNICODE</a>].
-</p>
+<p>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 <a href="http://www.unicode.org/faq/unsup_char.html">display of
+unsupported characters</a> [<a href="refs.html#ref-UNICODE">UNICODE</a>].</p>
<p>The <a>'xml:space'</a> attribute is:</p>
<p> <span class="anim-target"><a