SVG allows text to be inserted into the drawing. All of the same styling attributes available for paths and vector graphic shapes are also available for text. (See Filling, Stroking and Paint Servers.)
The <text> element adds text to a drawing.
SVG requires that all text data be specified within a <text> element. This allows the SVG processor to know unambiguously how to render the text. Furthermore, it provides enough information to the SVG processor to allow it to stitch together separately drawn strings of text into textflows. (See Defining Text Flows: the <textflow> element.)
You have three choices for how to specify the text strings to be drawn:
If combinations of the three choices are used on the same <text> element, then the text data will be stitched together as follows: the string will appear first, followed by the character data and text retrieved via <src href="..." /> subelements, which are added in relation to their order in the file.
In the example below, the first <text> element (with id="TextToUse") will not draw because it is part of a <defs> element. The second <text> element draws the string "ABC". The third text element draws the string "DEF". The fourth text element draws the string "XYZ" because it includes a <src> element which is a reference to element "TextToUse", and that element's character data is "XYZ":
<g>
<defs>
<text id="TextToUse">XYZ</text>
</defs>
<text>ABC</text>
<text string="DEF"/>
<text>
<src xml:link="simple" show="embed" actuate="auto" href="#TextToUse"/>
</text>
</g>
<text> elements have optional attributes x= and y= (default values are zero in the user coordinate system) which represents the location in user coordinates (or Transformed CSS units or a percentage of the current viewport) for the initial current text position. For left-aligned characters, the character origin (??? need to define this better) of the first character in the string will be positioned exactly at the current text position and the character will be rendered based on the current set of text and font properties. After the character is rendered, the current text position is advanced based on the metrics of the character and the current set of text and font properties. For Roman text, the current text position is advanced along the x-axis by the width of that character. The cycle repeats for all characters in the <text> element.
(Internationalization issues need to be addressed.)
SVG provides a <textflow> element to allow generators of SVG to specify text selection order, even when the contents of a text flow are distributed throughout the canvas. When feasible, generators of SVG should attempt to use this facility to order their text strings to facilitate properly ordered text selection within SVG viewing applications such as Web browsers.
The <textflow> element defines the selection order for multiple <text> elements within a given SVG document. The following example illustrates how <textflow> works:
<g>
<defs>
<textflow id="TF1">
<t xml:link="simple" href="T1"/>
<t xml:link="simple" href="T3"/>
</textflow>
<textflow id="TF2">
<t xml:link="simple" href="T2"/>
<t xml:link="simple" href="T4"/>
</textflow>
</defs>
<text x="100" y="100" id="T1"><tf xml:link="simple" href="TF1"/>123</text>
<text x="100" y="200" id="T2"><tf xml:link="simple" href="TF2"/>ABC</text>
<text x="150" y="100" id="T3"><tf xml:link="simple" href="TF1"/>456</text>
<text x="150" y="200" id="T4"><tf xml:link="simple" href="TF2"/>DEF</text>
</g>
(??? Insert drawing here)
The above example contains four text strings. Text strings T1 (with string "123") and T3 (with string "456") belong to the same textflow, whereas text strings T2 (with string "ABC") and T4 (with string "DEF") belong to a different textflow.
Within an SVG viewing application which supports text selection, the following behavior should exist. When the mouse is clicked over an SVG character and then the mouse is dragged, whenever the mouse goes over another character within the same <textflow>, all characters whose selection order is between the initial character and the current character should be highlighted, no matter where they might be located on the canvas.
(Descriptions (or references to the CSS2 spec) for all of the text and font properties from CSS2 go here.)
There are situations such as ligatures, special-purpose fonts (e.g., a font for music symbols) or alternate glyphs for Asian text strings where you want the text string as presented to search engines to be different than the characters drawn on the display. To allow for ligatures or for glyphs that do not correspond to the Unicode[??? add link] characters that appear within the character data, the <text> element offers the <altglyph> subelement. The four alternative formats for the <altglyph> subelement are as follows:
<altglyph unicode="..." [(font attributes)] /> <altglyph glyphname="..." [(font attributes)] /> <altglyph glyphid="..." [(font attributes)] /> <altglyph ROS="..." cid="..." [(font attributes)] />
where:
Multiple <altglyph> subelements can appear within a <text> element. The SVG processor will search for each alternate glyph in order. If none of the alternate glyphs are found, the SVG processor will render the character data as if no <altglyph> elements were present.
In the example below, the ligature whose glyph name is "FFL-Ligature" from font Protruda will be used to draw characters "ffl" in the word "waffle":
<text x="100" y="100">wa</text> <text x="120" y="100"> <altglyph glyphname="FFL-Ligature" font-family="Protruda"/>ffl</text> <text x="140" y="100">e</text>
(The working group has had considerable discussion about the best approach to providing a text on a path facility in SVG. The details haven't been worked out yet.
The current thinking is that the text on a path, just like all other SVG text data, would be expressible as character data so that the text can be found by search engines and "Find" commands within Web browsers. Somehow this text data would be mapped to a path object and the individual characters of the text string would be positioned and rotated along that path such that the center of the baseline for each character would be parallel to the tangent to the path.
There would be a simple, default, well-specified text-on-a-path layout algorithm which offers reasonable text layout in common cases. This layout algorithm could be adjusted on a single character basis to achieve custom kerning effects. The character placement algorithm would be based on the width of the glyph, not the width of the character.)