11. テキスト — Text

11.1.1. 各種 定義

`文字@ ◎ character

文字は、 `XML$r に定義される，~textの不可分な単位を成す。 ◎ A character is an atomic unit of text as defined in XML [XML].

注記： 本質的には，~Unicode符号位置。 文字には、次に挙げるものもある ⇒＃ 制御~文字（ `tab^en, `carriage return^en, `line feed^en など）, 描画-可能なもの（字l, 数字, 約物, その他の記号）, 他の文字を改変するもの（ `modifier^en — `combining accent^en など）。 ◎ Essentially, a Unicode code point. A character may be a control instruction (such as a tab, carriage return, or line feed), a renderable mark (letter, digit, punctuation or other symbol), or a modifier (such as a combining accent).

`~address可能な文字@ ◎ addressable character

［ ~text位置決め属性／~SVG~DOM~text~method ］から~address可能な`文字$。 ［ `縮約-可能な空白$などの，~layoutの間に破棄される文字 ］や［ `display$p ~propが `none^v にされた要素の中の文字 ］は、~address可能でない。 ~address可能な文字は，~indexにより~addressされる。 ~indexは、 `text-transform$p による変換を適用するに先立って決定される — `SVGTextContentElement$I ~interfaceの各種~method用に述べられるように。 ~indexを文字に対応付ける手法には、次の 2 つがある — どちらを選ぶかは、その目的に依存する： ◎ A character that is addressable by text positioning attributes and SVG DOM text methods. Characters discarded during layout such as collapsed white space characters are not addressable, neither are characters within an element with a value of none for the display property. Addressable characters are addressed by their index. Indexes are determined prior to applying any text-transform conversions, as described for the methods in the SVGTextContentElement interface. There are two methods to map an index to a character; the choice of which to use depends on purpose:

1. ~text位置決め属性による対応付けの目的においては、 ~indexは，~Unicode符号位置の個数に基づく（したがって，並び［ `u^l, ` ̈^l （ `combining diaeresis^en 【トレマ／分音符】） ］は 2 個の文字と数えられる一方で、 組成済み文字 `ü^l は 1 個の文字に数えられる）。 ◎ For the purposes of mapping text positioning attributes, the index is measured in Unicode code points (thus a 'u' followed by the combining diaeresis ' ̈' is counted as two characters while the precomposed character 'ü' is counted as one character).
2. ~SVG~DOM~text~methodの目的においては、 ~indexは、~UTF-16符号単位の個数に基づく （したがって， `FFFF^U を超える単独の~Unicode符号位置は、 2 個の~address可能な文字に対応付けられる — ~UTF-16符号単位は 16 ~bitなので）。 ◎ For the purposes of SVG DOM text methods, the index is measured in UTF-16 code units (thus, a single Unicode code point above U+FFFF will map to two addressable characters as a UTF-16 code unit consists of 16 bits).

注記： これら 2 つの手法は、 ~SVG-11と後方-互換である。 ~SVG~DOM~text~method用の~UTF-16符号単位の利用は、 ~DOM仕様による `DOMString^I の定義から要求される。 【！DOM 2】 ◎ The different methods are backwards compatible with SVG 1.1. The use of UTF-16 code units for SVG DOM text methods is required from the definition of DOMString in the DOM 2 specification.

~SVG~WGは、［ ~text位置決め属性の対応付けにおける~Unicode符号位置 ］を置換するべく，［ `Unicode Standard Annex #29^cite に定義される書記素~cluster ］を利用する可能性について，実装者からの~feedbackに関心がある。 何が文字を成すとされるかは，文脈（行l分断法, 単語~分断法, 等々）に依存し得るので、 ~CSS`~typographic文字$の利用は適切でないことに注意。 ◎ The SVG working group is interested in implementer feedback on the possibility of using grapheme clusters as defined by the Unicode Standard Annex #29 to replace Unicode code points in mapping text positioning attributes. Note, the use of the CSS typographic character is not appropriate as what constitutes a character can depend on context (line-breaking, word-breaking, etc.).

注記： 将来に~CSS生成d内容~text用の~supportが導入された場合、 それも，~address可能な文字が成す配列~内に含まれることになる。 ◎ If support for CSS generated-content text is introduced in the future, it would be included in the array of addressable characters.

`~typographic文字@ （ `typographic character^en ）

書記体系を成す単位であって，特定0の~typographic演算（ 行-分断法（ `line-breaking^en ）, 先頭字（ `first-letter^en ）効果, 字l↔間のアキ（ `tracking^en ）, 両端揃え（ `justification^en ）, 縦方向の~~配置, 等々）に関して分割-不能なもの — ~Latin~alphabetic字l（発音区別符~付きも含む）, ~Hangul音節, 中国語~ideographic文字, ~Myanmar音節~cluster, 等々。 規範的な定義, および これと~Unicode書記素~clusterとの関係性については、 `~typographic文字~単位$ `css-text-3$r を見よ。 ◎ A unit of a writing system— such as a Latin alphabetic letter (including its diacritics), Hangul syllable, Chinese ideographic character, Myanmar syllable cluster— that is indivisible with respect to a particular typographic operation (line-breaking, first-letter effects, tracking, justification, vertical arrangement, etc.). For the normative definition and the relationship between this and a Unicode grapheme cluster, see CSS Text Module Level 3, ([css-text-3]).

`~font@ （ `font^en ）

~fontは、［ 様々な~glyph表現が特定0の外観や~style付けを共有する ］ような，一連の`~glyph$からなる組織化された~collectionを表現する。 ◎ A font represents an organized collection of glyphs in which the various glyph representations will share a particular appearance or styling.

`~glyph@ （ `glyph^en ）

~glyphは、`~font$の中の描画される内容が成す単位を表現する。 描かれる文字と~glyphは，一対一に対応することが多いが （例：文字 "A" は，通例的に単独の~glyphを利用して描画される）、 単独の文字を描画するのに複数の~glyphが利用されることもあれば（例：~accentを伴う文字）， 複数の文字を描画するのに単独の~glyphが利用されることもある（例：合字）。 ~glyphは概して， `~path＠~SVGpaths$などの 1 個以上の`図形~要素$により定義され、 場合によっては — 小さい~sizeにおいて判読可能な~textを生産するため — ~font~engineを補助する描画~hintなど，追加的な情報も伴う。 ◎ A glyph represents a unit of rendered content within a font. Often, there is a one-to-one correspondence between characters to be drawn and corresponding glyphs (e.g., usually the character "A" is rendered using a single glyph), but other times multiple glyphs are used to render a single character (e.g., characters with accents) or a single glyph can be used to render multiple characters (e.g., ligatures). Typically, a glyph is defined by one or more shapes such as a path, possibly with additional information such as rendering hints that help a font engine to produce legible text in small sizes.

`~text内容~要素@ ◎ text content element

~text文字列を~canvasに描画させる~SVG要素。 次に挙げるもの ⇒＃ `text$e, `textPath$e, `tspan$e ◎ A text content element is an SVG element that causes a text string to be rendered onto the canvas. The SVG text content elements are: ‘text’, ‘textPath’ and ‘tspan’.

`~text内容~子~要素@ （ `text content child element^en ）

別の`~text内容~要素$の子孫に許容される`~text内容~要素$。 ~SVGにおいては、次に挙げるもの ⇒＃ `textPath$e, `tspan$e ◎ A text content child element is a text content element that is allowed as a descendant of another text content element. In SVG the text content child elements are: ‘textPath’ and ‘tspan’.

`~text内容~塊~要素@ （ `text content block element^en ）

~text内容~塊~要素は、 `~text内容~要素$であって，~textを成す単位~用の自立的な要素として~serveする — 任意選択で，一定の子`~text内容~要素$（例： `tspan$e ）も包含できる。 ~SVG-2が定義する~text内容~塊~要素は、 `text$e だけである。 ◎ A text content block element is a text content element that serves as a standalone element for a unit of text, and which may optionally contain certain child text content elements (e.g. ‘tspan’). SVG 2 defines a single text content block element: ‘text’.

`内容~区画@ （ `content area^en ）

通常は~textが~lay-outされる区画。 これは、`~CSS内容~区画$と等価である。 ~text~layoutが生じる実際の領域は、 ~paddingや排他体に因り，狭められ得る。 【`§ 内容~区画＠#TextLayoutContentArea$を見よ。】 ◎ The area in which the text is normally laid out. This is equivalent to the CSS content area. The actual region where text layout occurs may be smaller due to padding and/or exclusions.

`包装~文脈@ （ `wrapping context^en, “包装している文脈” ）

~text~layoutの間に内容~区画から排他される 1 個以上の領域（図形）。 これは、`~CSS回込み文脈$と等価である。 ◎ One or more regions (shapes) to be excluded from the content area during text layout. This is the same as the CSS wrapping context.

`包装~区画@ （ `wrapping area^en, “包装されている区画” ）

【内容~区画から】［ ~padding, および排他~区画（`包装~文脈$） ］を減算した区画 — ~textは、この区画に~lay-outされる。 これは、`~CSS回込み区画$と等価である。 ◎ The area in which the text is laid out after subtracting any padding or exclude areas (wrapping context). This is the same as the CSS wrapping area.

`行l~box@ （ `line box^en ）

~textが成す単独の行lを~layoutするために利用される，すべての内容を包含している矩形な区画。 これは`~CSS行l~box$と同じである。 ◎ The rectangular area containing all the content used to layout a single line of text. This is the same as the CSS line box.

様々な~CSS 3 ~text~layout仕様がこの用語を利用するが、 現時点では どれも正式な定義を確立していない。 したがって，~linkは~CSS 2.1 を指しており、 ~CSS~WGに課題が申請されている （`~~参照先＠~CSSissue/363$）。 ◎ Although various CSS 3 text layout specs use the term, none current establish a formal definition. The link is therefore to CSS 2.1, and an issue has been filed with CSS WG .

`行内-基底~方向@ （ `inline-base direction^en ）

~textを成す［ 行lまたは その一部 ］の中で，内容が順序付けられる首な方向。 それは、［ 行lまたは その一部 ］の中の［ 始端, 終端 ］側を定義する（例えば `text-anchor$p ~propがどう適用されるかに関連な）。 それは、 `direction$p ~propにより決定される （注記：行lを成す文字たちの順序付けを首に制御するのは、行内-基底~方向ではなく，~Unicode双向性~algoである。） ◎ The primary direction in which content is ordered within a line or part of a line of text. It defines the start and end sides of a line or part of a line of text (relevant, for example to how the text-anchor property is applied). It is determined by the direction property. (Note: the ordering of characters in a line of text is primary controlled by the Unicode bidi algorithm and not the inline-base direction.)

`塊-~flow方向@ （ `block-flow direction^en ）

`行l~box$が堆積されていく方向。 `writing-mode$p ~propにより決定される。 ◎ The direction in which line boxes are stacked. It is determined by the writing-mode property.

`整列~点@ （ `alignment point^en ）

`現在の~text位置$に整列されるベキ，~typographic文字~上の点。 それは、~glyph~cell計量により決定され，用字系や`行内-基底~方向$に依存することもある。 ◎ The point on a typographic character that should be aligned with the current text position. It is determined by the glyph cell metrics and may depend on the script and inline-base direction.

`現在の~text位置@ （ `current text position^en ）

~typographic文字を描画するとき、 その`整列~点$が，現在の利用元~空間~内で配置されるべき点。 ◎ The point in the current user space where the alignment point of the next typographic character to be rendered should be placed.

`~text~chunk@ （ `text chunk^en ）

ある独立な ~text塊 — それを成す すべての文字は、この塊~内に一緒に位置される。 （ `x$a ／ `y$a 属性や強制d行l分断に因る ）各~新たな絶対~位置決め調整は、 新たな`~text~chunk$を作成する。 ［ 合字~代用／双向-並替ng ］は、 複数の`~text~chunk$にまたがることはない。 `~text~chunk$が関連するのは、 整形済み~textに限られる。 ◎ An independent block of text in which all characters are positioned together. Each new absolute positioning adjustment (due to an ‘x’ or ‘y’ attribute, or forced line break) creates a new text chunk. Ligature substitution and bidi-reordering only occur within a text chunk. Text chunks are only relevant to pre-formatted text.

`空白~文字@ （ `white space characters^en ）

次に挙げる文字が空白~文字と見なされる ⇒＃ `0009^U `CHARACTER TABULATION^cn, `000C^U `FORM FEED^cn (FF), `000D^U `CARRIAGE RETURN^cn (CR), `000A^U `LINE FEED^cn (LF), `0020^U `SPACE^cn ◎ The following characters are considered white space characters: U+0009 CHARACTER TABULATION, U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR), U+000A LINE FEED (LF) and U+0020 SPACE.

`塊~要素@

~CSSにおける`塊~容器$を生成する要素を意味する。 ~SVGにおいては、 `~text内容~塊~要素$が該当する。

【 この項目と次の項目は、この訳による補完。 原文では，塊~要素と同じ意味を表す語として “塊~levelの要素” が用いられている箇所もあるが、 これは誤用なので（要素の`外側^emは塊~整形~文脈ではない），単に “塊~要素” と記している。 】

`行内~要素@

~CSSにおける行内~boxを生成する要素を意味する。 ~SVGにおいては、`~text内容~塊~要素$の子孫のうち描画されるものが該当する。

11.1.2. ~fontと~glyph

~fontは、~glyphたちの~collection, および それと一緒にされた［ それらの~glyphを利用して，文字を何らかの視覚的な媒体に呈示するために必要yな他の情報 ］（~font~tableと総称される）からなる。 ~glyphたちの~collectionと~font~tableの組合nは、 `~font~data^em と呼ばれる。 ◎ A font consists of a collection of glyphs together with other information (collectively, the font tables) necessary to use those glyphs to present characters on some visual medium. The combination of the collection of glyphs and the font tables is called the font data.

~fontは、~glyphの［ 代用／位置決め ］用の~tableを給することもある — 整形器（ `text shaper^en とも呼ばれる）が、 この~tableを利用して，~glyph並びを［ 並替えて, 組合せて, 位置して ］ 1 個以上の組成-~glyphを形成できるような。 この結合-法は、 合字のような単純なものから， ~indic音節のような複階的なものまである — 後者は、通例的に何らかの並替ngも伴って，複数の子音~glyphと母音~glyphを組合せる。 この~tableは、言語に依存する，言語に適切な字l形の利用を許容することもある。 ◎ A font may supply substitution and positioning tables that can be used by a formatter (text shaper) to re-order, combine and position a sequence of glyphs to form one or more composite glyphs. The combining 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. The tables may be language dependent, allowing the use of language appropriate letter forms.

~glyphは — 単純か組成-かを問わず — 植字~目的において分割-不能な単位を表現するとき，`~typographic文字$と呼ばれる。 ◎ When a glyph, simple or composite, represents an indivisible unit for typesetting purposes, it is know as a typographic character.

合字は、高度な~text~layoutにおいて重要な特能である。 合字には、随意のものもあれば，必須のもの（例：~Arabic）もある。 合字の形成には、次に明示的に挙げる規則が適用される： ◎ Ligatures are an important feature of advance text layout. Some ligatures are discretionary while others (e.g. in Arabic) are required. The following explicit rules apply to ligature formation:

• 異なる~DOM~text~node内にある文字どうしによる合字~形成は、 可能化されるベキでない。 したがって，~markupにより分離された文字たちには、 合字は利用されるベキでない。 ◎ Ligature formation should not be enabled when characters are in different DOM text nodes; thus, characters separated by markup should not use ligatures.
• 文字たちが異なる`~text~chunk$にあっても、 合字~形成は可能化されるベキである。 ◎ Ligature formation should not be enabled when characters are in different text chunks.

• 随意~合字は、 文字~間のアキが既定の空間と同じでないときには，利用されるベキでない （例： `letter-spacing$p が既定でない値にされているとき／ `text-align$p の値が `justify^v で `text-justify$p の値が `distribute^v されているとき）。 `css-text-3$r ◎ Discretionary ligatures should not be used when the spacing between two characters is not the same as the default space (e.g. when letter-spacing has a non-default value, or text-align has a value of justify and text-justify has a value of distribute). (See CSS Text Module Level 3, ([css-text-3]).

  ［ `dx$a, `textLength$a, `textPath$e の `spacing$a ］などの~SVG属性のうち， `~typographic文字$を位置し直し得るものは、 随意~合字を分断しない。 随意~合字が欲されない場合、 `font-variant-ligatures$p ~propを利用して不能化できる。 ◎ SVG attributes such as ‘dx’, ‘textLength’, and ‘spacing’ (in ‘textPath’) that may reposition typographic characters do not break discretionary ligatures. If discretionary ligatures are not desired they can be turned off by using the font-variant-ligatures property.

  ~OpenType~font用には、 随意~合字は［ `liga^tag ／ `clig^tag ／ `dlig^tag ／ `hlig^tag ／ `cala^tag ］特能により可能化されるものを含む。 必須~合字は `rlig^tag 特能に見出される。 【これらの特能については `font-variant-ligatures$p を見よ。】 ◎ For OpenType fonts, discretionary ligatures include those enabled by the liga, clig, dlig, hlig, and cala features; required ligatures are found in the rlig feature.

適正な~text描画は、 著作~時に利用したものと同じ~fontを利用することに依存することもある。 この理由から、 ~SVGには `css-fonts-3$r `§ ~font資源＠~CSSFONT#font-resources$ にて定義される，~download可能な~font用の~supportが要求される。 特に， `WOFF$r 用の~supportは要求される。 ◎ Proper text rendering may depend on using the same font as used during authoring. For this reason SVG requires support for downloadable fonts as defined in the Font Resources section of the CSS Fonts Module. In particular, support for the Web Open Font Format [WOFF] is required.

注記： ~SVG-2にて新たに~~導入された~WOFFは、 内容を適正に描画するために必要な~fontを供することを，作者に許容する。 これには、［ 当の~fontが［ 複階的な用字系, 随意~合字, `swash^en, `old-style number^en, 等々 ］を~supportするための適正な~OpenType~tableを備える ］ことを確保することも含まれる。 ~WOFFはまた、 ~fontが［ 圧縮される／ `subset^en される／ 許諾~情報を含む ］ことも許容する。 ◎ New in SVG 2, WOFF allows authors to provide the fonts needed to properly render their content. This includes ensuring that the fonts have the proper OpenType tables to support complex scripts, discretionary ligatures, swashes, old-style numbers, and so on. WOFF also allows the fonts to be compressed, subsetted, and include licensing information.

11.1.3. ~glyph計量と~layout

~glyph［ 選定と位置決め ］は、 通常は，~CSSの規則に則って取扱われる。 しかしながら，一部の事例では、 ~SVGにおける~textの最終的な~layoutに個々の~glyphの幾何~propについての知識が要求される。 ◎ Glyph selection and positioning is normally handled according to the rules of CSS. In some cases, however, the final layout of text in SVG requires knowledge of the geometry properties of individual glyphs.

~fontの幾何的な特性は、 ~EM~boxに基づく座標系~内で表出される。 （~EMは、~font内の~glyphの縦幅に相対的な測度である。） 高さ, 幅とも 1 ~EMの~boxは、 `~design空間^em と呼ばれる。 この空間の幾何-座標は、 ~EMを`~emあたりの単位~数^dfn（ `units per em^en ）に細分することにより与えられる。 ◎ 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.) The box 1 EM high and 1 EM wide is called the design space. This space is given a geometric coordinates by sub-dividing the EM into a number of units per em.

注記： ~emあたりの単位~数は、~font特性である。 代表的な値には 1000, 2048 がある。 ◎ Units per em is a font characteristic. A typical value for units per em is 1000 or 2048.

~EM~boxが成す座標~空間は、 `~design空間~座標系^em と呼ばれる。 拡縮-可能な~font用の~glyphを描くときに利用される曲線や直線は、 この座標系を利用して表現される。 ◎ The coordinate space of the EM box is called the design space coordinate system. For scalable fonts, the curves and lines that are used to draw a glyph are represented using this coordinate system.

注記： この座標系における原点 ( 0, 0 ) は、 ~EM~boxの左下隅ではない左端~辺に位置することが最も多い。 ~~大文字の下端の~y座標は通例的に 0 になり、 ~~小文字の~descenderの座標~値は負になる。 ◎ 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. The descenders on lowercase roman letters have negative coordinate values.

~SVGは、~font~tableが少なくとも 3 つの~font特性 — ~ascent, ~descent, 基底線~tableの集合 — を供するものと見做す。 ~fontの［ ~ascent／~descent ］は、 点 ( 0, 0 ) から~EM~boxの［ 上端／下端 ］までの距離を与える。 基底線~tableは下に説明される。 ◎ 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.

注記： ~OpenType~font `OPENTYPE$r の中では、 横組み用の［ ~ascent ／ ~descent ］は， OS/2 ~table内の［ `sTypoAscender^en ／ `sTypoDescender^en ］~entryが与える。 縦組み用の~descent（この事例においては点 ( 0, 0 ) から~glyphの左端~辺までの距離）は、 通常は 0 になる — 点 ( 0, 0 ) は左端~辺にあるので。 縦組み用の~ascentは、 `1em^v か，または［ `OpenType Base^en ~table内の縦組み用の~ideographic上端~基底線~値 ］により指定される。 ◎ Within an OpenType font ([OPENTYPE]), 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.

各~glyphには，`整列~点$と呼ばれる【~EM~box内の】特定0の点が結付けられる。 ~glyphたちは、 各自の`整列~点$に相対的に位置される — 横組み用の`整列~点$は縦に【すなわち，~y座標が】整列され、 縦組み用の`整列~点$は横に【すなわち，~x座標が】整列される。 `整列~点$の位置は、用字系に依存する。 例えば［ 西欧~glyphは，~~大文字の下端 ／ 北方~indic~glyphは，~glyphの上端に近い横方向~strokeの上端／ 極東-~glyphは，~glyphの下端か中心 ］に整列される。 ◎ Glyphs are positioned relative to a particular point on each glyph known as the alignment point. For horizontal writing-modes, the glyphs' alignment points are vertically aligned while for vertical writing-modes, they are horizontally aligned. The position of the alignment point depends on the script. For example, Western glyphs are aligned at the bottom of 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.

同じ用字系, 同じ `font-size^p の~textが成す行lの中では、 `行内-基底~方向$における整列~点の並びは `基底線@ と呼ばれる幾何的な線を定義する。 ［［ 西欧~その他のほとんどの［ ~alphabetic／~syllabic ］~glyph ］は `~alphabetic^i 基底線／ 北方~indic~glyphは `~hanging^i 基底線／ 極東-~glyphは `~ideographic^i 基底線 ］に整列される ◎ Within a script and within a line of text having a single font-size, the sequence of alignment points defines, in the inline-base direction, a geometric line called a baseline. 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.

一連の~glyphは基底線に沿って連列的に配置されるので、 各~glyphの`整列~点$は，概して`現在の~text位置$に位置する （この位置決めは、 `vertical-align$p などの何らかの~propにより改められることもある）。 各~glyphが配置された後、 `現在の~text位置$は，~glyphの`送幅^em （概して，横書き~text用には横幅 ／ 縦書き~text用には縦幅） だけ送する — ~kerning その他によるアキ調整, および 新たな行lにおける［ 整形済み~text／自動折返d~text ］があれば それらも伴って。 初期-, および最終-現在の~text位置は整列~用に利用される（例： `text-anchor$p 値が `middle^v ／ `end^v のとき）。 ~glyphの送幅は、 ~pathに沿う~textを配置するときにも必要になる。 ◎ As glyphs are sequentially placed along a baseline, the alignment point of a glyph is typically positioned at the current text position (some properties such as vertical-align may alter the positioning). After each glyph is placed, the current text position is advanced by the glyph's advance value (typically the width for horizontal text or height for vertical text) with any correction for kerning or other spacing adjustment as well as for new lines in pre-formatted or auto-wrapped text. The initial and final current text positions are used for alignment (e.g. when the text-anchor value is either 'middle' or 'end'). The glyph's advance is needed when placing text along a path.

~glyphが現在の~glyph方位に対応する送幅を明示的に供さない場合、 適切な近似が利用されるベキである。 縦書き~text用に示唆される近似は `~em^em ~sizeである。 ◎ If a glyph does not provide explicit advance values corresponding to the current glyph orientation, then an appropriate approximation should be used. For vertical text, a suggested approximation is the em size.

初期-`現在の~text位置$は、［ 整形済み~text ／ `inline-size$p ~propにより`内容~区画$が決定される自動折返d~text ］用には，［ `text$e 要素，または最初に描画される `tspan$e 要素 ］上の［ `x$a, `y$a ］属性により確立される。 他の自動折返d~text用の初期-`現在の~text位置$は、 ~CSS行l折返ng~algoを適用した後の，最初に描画される~glyphの位置により決定される。 ◎ The initial current text position is established by the ‘x’ and ‘y’ attributes on the ‘text’ element or first rendered ‘tspan’ element for pre-formatted text, or auto-wrapped text when the content area is determined by the inline-size property. For other auto-wrapped text, the initial current text position is determined by the position of the first rendered glyph after applying the CSS line wrapping algorithm.

`基底線~table@ は、 1 本以上の基底線の位置を~design空間~座標系~内で指定する。 基底線~tableの機能は、 同じ~text行l内に異なる用字系が混在するとき，互いの整列を手助けする。 欲される相対的な整列は、 行l（または塊）内で どの用字系が支配的になるかに依存するであろうから、 用字系ごとに異なる基底線~tableがあり得る。 加えて、横組み用, 縦組み用それぞれに異なる整列~位置が必要になる。 したがって，~fontは、複数の基底線~tableを備え得る — 概して、横組み用に 1 個以上，縦組み用には 0 個以上。 ◎ A baseline-table 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.

注記： 一部の~fontには、基底線~table用の値が無いものもある。 所与の~fontが基底線~tableを給さないときには、 `基底線の合成-法＠~CSSINLINE#baseline-synthesis-fonts$ `css-inline-3$r による，基底線~tableを近似する経験則が示唆される。 ◎ Some fonts may not have values for the baseline tables. Heuristics are suggested for approximating the baseline tables in CSS Inline Layout Module Level 3 [css-inline-3] when a given font does not supply baseline tables.

`支配的~基底線@ は、 ~text連なりの途中で，異なる~font（または 異なる~font~size）が指定されたときに， 新たな~font（新たな~size）内の~glyphと それまでの~font内の~glyphとを整列するために利用する基底線を決定する。 支配的~基底線は、 `dominant-baseline$p ~propを利用して設定される。 ◎ When a different font (or change in font size) is specified in the middle of a run of text, the dominant baseline determines the baseline used to align glyphs in the new font (new size) to those in the previous font. The dominant-baseline property is used to set the dominant baseline.

その親に相対的な~objの整列は、 `整列~基底線@ により決定される。 通常は，支配的~基底線と同じ基底線になるが、［ `vertical-align$p 略式~prop, その下位prop `alignment-baseline$p ］（前者が選好される）を利用すれば，別の基底線を選べる。 ◎ Alignment between an object relative to its parent is determined by the alignment baseline. It is normally the same baseline as the dominant baseline but by using the shorthand vertical-align property (preferred) or the longhand alignment-baseline another baseline can be chosen.

支配的~基底線は、［ `vertical-align$p 略式~prop, または その下位prop `baseline-shift$p （前者が選好される） ］を利用して，一時的にズラせる（［ 下付文字／上付文字 ］用に必要になる）。 ズラシは入子にできることに注意 — 各ズレは それまでのズレに加算される。 ◎ The dominant baseline can be temporarily shifted (as needed for superscripts or subscripts) by using either the shorthand vertical-align property (preferred) or the longhand baseline-shift property. Note that shifts can be nested, each shift added to the previous shift.

~SVGにおいては、~fontの~font~dataを成す各~glyphには，［ 横組み用, 縦組み用 ］それぞれに［ 横幅~値（横書き用）または縦幅~値（縦書き用）, 整列~基底線, 整列~点 ］が備わるものと見做す。 `行内-基底~方向$における整列~点の位置は、 ~glyphの始端~辺にある。 ◎ 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 inline-base direction position of the alignment point is on the start-edge of the glyph.

基底線についての追加的な情報は、 `行l高さと基底線~整列＠~CSSINLINE#line-height$ `css-inline-3$r にて見出される（ `css-writing-modes-3$r も見よ）。 ◎ Additional information on baselines can be found in the CSS Inline Layout Module Level 3 specification. [css-inline-3] (Also see: CSS Writing Modes Level 3 specification. [css-writing-modes-3])

~textが成す各~行lは、 `行l~box$の内側に~lay-outされる。 複数行の~textは、 これらの~boxを堆積することにより生産される。 `行l~box$の縦幅は、 `line-height$p ~propの効果を適用した後に， 行lを成す~text内のすべての~glyphの［ 最大~ascent, 最大~descent ］見出すことにより決定される。 【横書きの下では、】`行l~box$の横幅は、 通常は，包含している~text塊の横幅になる。 ~SVGにおいては、 包含している~text塊の幾何が固定的でない場合（整形済み~textのときなど）、 `行l~box$は，~boxの中の~glyph~boxたちを緊密に包装する。 ◎ A single line of text is laid out inside a line box. Multi-line text is produced by stacking these boxes. The height of a line box is determined by finding the maximum ascent and the maximum descent of all the glyphs in a line of text after applying the effect of the line-height property. The width of a line box is normally the width of the containing text block. In SVG, when the containing text block does not have a fixed geometry (as with pre-formatted text), the line box tightly wraps the glyph boxes within the box.

様々な国際的な書記体系を~supportするため、 `行l~box$は［ 横, 縦 ］どちらの方向にも方位し得る。 縦書き`行l~box$の中の~textは、 下向きへ~flowする。 横書き`行l~box$の中の~textは、［ 右向き（例：現代の~Latin用字系）, 左向き（例：~Hebrewや~Arabic）, この両者の混成（双方向-~text） ］いずれにも~flowし得る。 ◎ In order to support various international writing systems, line boxes may be orientated in a horizontal or vertical direction. Text within a vertical line box flows from top to bottom. Text within a horizontal line box may flow left-to-right (e.g., modern Latin scripts), right-to-left (e.g., Hebrew or Arabic), or a mixture of left-to-right and right-to-left (bidirectional text).

双方向-~text用の処理~modelは、次に従う： ◎ The processing model for bidirectional text is as follows:

• 以下では、供された文字~並びを`論理-順序^em（元の文書~内に文字が現れる順序）で処理する。 ◎ The user agent processes the characters which are provided in logical order (i.e., the order the characters appear in the original document).
• `描画されない要素$を除外する。 ◎ The user agent excludes non-rendered elements＼
• `空白を縮約する＠#WhiteSpace$。 ◎ and collapses white space.

• 互いに独立な塊の集合を決定する。 ~UAは、~Unicode双方向-~algoを塊ごとに適用するベキである。 ◎ The user agent determines the set of independent blocks within each of which it should apply the Unicode bidirectional algorithm.

  • 各`~text~chunk$は、 互いに独立な~text塊を表現する。 ◎ Each text chunk represents an independent block of text.
  • 双方向-目的においては、［ `text-orientation$p ／ 廃用にされた `glyph-orientation-vertical$p ］~propの処理に因る~glyph方位の変化は，新たな独立な~text塊を開始させることになる。 ◎ Any change in glyph orientation due to processing of the text-orientation or obsoleted glyph-orientation-vertical properties will start a new independent blocks of text for bi-directional purposes.
• 各~独立な~text塊に対し、 ~Unicode双方向-~algo, および［ `direction$p, `unicode-bidi$p ］~propを処理して，［ 並替えられ，右向き描画~順序にされた文字たち ］からなる~listを得る。 文字の並替ngと同時に，［ `text$e ／ `tspan$e ］要素~上の［ `dx$a, `dy$a, `rotate$a ］属性も［ 各 文字と属性~値を成す各成分との間で，元の対応関係を保守する ］よう並替えられる。 ◎ After processing the Unicode bidirectional algorithm and properties direction and unicode-bidi on each of the independent text blocks, the user agent will have a potentially re-ordered list of characters which are now in left-to-right rendering order. Simultaneous with re-ordering of the characters, the ‘dx’, ‘dy’, and ‘rotate’ attributes on the ‘text’ and ‘tspan’ elements are also re-ordered to maintain the original correspondence between characters and attribute values.

~kerningや合字の処理は~fontに特有かもしれないが、［ ~kerning／合字 ］の処理~modelとしては，［ 文字が並替えられてから，文字や~glyphどうしを組合せるまでの合間 ］に生じることが選好される。 ◎ 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.

`行l~box$の方位, および それらが堆積される方向（`塊-~flow方向$）は、 `writing-mode$p ~propにより決定される。 `行l~box$たちは、 横書き~text（ `writing-mode$p 値 `horizontal-tb^v ）用には下向きへ堆積され、 縦書き~text用には［ 左向き（ `writing-mode$p 値 `vertical-rl^v ）／ 右向き（ `writing-mode$p 値 `vertical-lr^v ） ］へ堆積される。 ◎ The orientation of line boxes as well as the direction in which they are stacked (block-flow direction) is determined by the writing-mode property. For horizontal text (writing-mode value horizontal-tb) line boxes are stacked from top to bottom. For vertical text, line boxes are stacked from right-to-left (writing-mode value vertical-rl) or left-to-right (writing-mode value vertical-lr).

11.2.1. 属性

◎属名 `x@a, `y@a ◎属値 [ [ `length-percentage$t | `number$t ]+ ]# ◎属初 `text$e に対しては 0 ／ `tspan$e に対してはナシ ◎属ア 可 ◎表終 ◎ Name Value Initial value Animatable x, y [ [ <length-percentage> | <number> ]+ ]# 0 for ‘text’; (none) for ‘tspan’ yes

以下では，もっぱら `x$a 属性について述べるが、 `y$a 属性についても， "x" を "y" に読み替える下で同様に適用されるとする。 ◎ ↓

`x^a 属性に供された［ ~commaや~spaceで分離された~list ］を成す %n 個目の長さ値 【すなわち， `percentage^t や `number^t は `length^t に解決した結果】 は、［ この要素や その子孫 ］の中の［ %n 個目の［ `~address可能な文字$に対応する~glyph（たち） ］の描画~用の`現在の~text位置$ ］用の新たな絶対~x座標を表現する。 ◎ If a single <length> is provided, then the value represents the new absolute X (Y) coordinate for the current text position for rendering the glyphs that correspond to the first character within this element or any of its descendants. ◎ If a comma- or space-separated list of n <length>s is provided, then the values represent new absolute X (Y) coordinates for the current text position for rendering the glyphs corresponding to each of the first n addressable characters within this element or any of its descendants.

供された長さ値の個数が文字~数を超える場合、 余分な長さ値による~glyph位置決めに対する効果は無い。 ◎ If more <length>s are provided than characters, then the extra <length>s will have no effect on glyph positioning.

供された各~長さ値は、 先祖に指定された `x$a 属性から供される長さ値より優先される。 ◎ ↓

供された長さ値が文字~数に満たないか，または属性は指定されていない場合、 残りの各~文字に対応する~glyph（たち）の描画に利用する~x座標は — 当の文字~用の値が先祖の `x$a 属性から供されていない限り — 描画する直前における`現在の~text位置$（現在の `text$e 要素~用に直前に描画された~glyphがあれば，それによる結果の現在の~text位置）の~x座標になる。 ◎ If more characters exist than <length>s, or if the attribute is not specified on a ‘tspan’, then for each additional character: • if an ancestor ‘text’ or ‘tspan’ element specifies an absolute X (Y) coordinate for the given character via an ‘x’ (‘y’) attribute (nearest ancestor has precedence), then that absolute X (Y) coordinate is used as the starting X (Y) coordinate for that character, else • if an ancestor ‘text’ or ‘tspan’ element specifies an absolute X (Y) coordinate for the given character via an ‘x’ (‘y’) attribute (nearest ancestor has precedence), then that absolute X (Y) coordinate is used as the starting X (Y) coordinate for that character, else

注記： ~SVG-2においては、［ `text$e ／ `tspan$e ］の［ `x$a, `y$a ］属性は，呈示~属性ではないので、 ~CSSを介しては設定できない。 ~SVGの将来~versionにおいては、 これは変更され得る。 ◎ In SVG 2, the ‘text’ and ‘tspan’ ‘x’ and ‘y’ attributes are not presentation attributes and cannot be set via CSS. This may change in a future version of SVG.

◎属名 `dx@a, `dy@a ◎属値 [ [ `length-percentage$t | `number$t ]+ ]# ◎属初 ナシ ◎属ア 可 ◎表終 ◎ Name Value Initial value Animatable dx, dy [ [ <length-percentage> | <number> ]+ ]# (none) yes

以下では，もっぱら `dx$a 属性について述べるが、 `dy$a 属性についても， "x" を "y" に読み替える下で同様に適用されるとする。 ◎ ↓

`dx^a 属性に供された［ ~commaや~spaceで分離された~list ］を成す %n 個目の長さ値 【すなわち， `percentage^t や `number^t は `length^t に解決した結果】 は、［ この要素や その子孫 ］の中の［ %n 個目の［ `~address可能な文字$に対応する~glyph（たち） ］を描画する直前における`現在の~text位置$ ］からの~x軸~沿いの~~追加のズレを表現する。 したがって，~glyph（たち）が描画される前に、 （現在の `text$e 要素の中で それまでの文字~用の~glyphを描いた結果の） `現在の~text位置$は，現在の利用元~座標系の~x軸に沿って長さ値だけズラされる。 ◎ If a single <length> is provided, this value represents the new relative X (Y) coordinate for the current text position for rendering the glyphs corresponding to the first character within this element or any of its descendants. The current text position is shifted along the x-axis (y-axis) of the current user coordinate system by <length> before the first character's glyphs are rendered. ◎ If a comma- or space-separated list of n <length>s is provided, then the values represent incremental shifts along the x-axis (y-axis) for the current text position before rendering the glyphs corresponding to the first n addressable characters within this element or any of its descendants. Thus, before the glyphs are rendered corresponding to each character, the current text position resulting from drawing the glyphs for the previous character within the current ‘text’ element is shifted along the x-axis (y-axis) of the current user coordinate system by <length>.

供された長さ値が文字~数を超える場合、 余分な長さ値による~glyph位置決めに対する効果は無い。 ◎ If more <length>s are provided than characters, then any extra <length>s will have no effect on glyph positioning.

供された各~長さ値は、 先祖に指定された `dx$a 属性から供される長さ値より優先される。 ◎ ↓

供された長さ値が文字~数に満たないか，または属性は指定されていない場合、［ 残りの各~文字のうち，それ用の長さ値が先祖の `dx$a 属性から供されていないもの ］については，~~追加のズレは無い。 ◎ If more characters exist than <length>s, or if the attribute is not specified, then for each additional character: • if an ancestor ‘text’ or ‘tspan’ element specifies a relative X (Y) coordinate for the given character via a ‘dx’ (‘dy’) attribute (nearest ancestor has precedence), then the current text position is shifted along the x-axis (y-axis) of the current user coordinate system by that amount, else • no extra shift along the x-axis (y-axis) occurs.

◎属名 `rotate@a ◎属値 [ `number$t+ ]# ◎属初 ナシ ◎属ア 可（`加法的でない$） ◎表終 ◎ Name Value Initial value Animatable rotate [ <number>+ ]# (none) yes (non-additive).

この要素の中の各~文字に対応する~glyph（たち）に適用されることになる，`現在の~text位置$を中心とする `deg^u 単位による補足的な回転を与える。 ◎ The supplemental rotation, in degrees, about the current text position that will be applied to all of the glyphs corresponding to each character within this element.

供された［ ~commaや~spaceで分離された~list ］を成す %n 個目の `number$t 値は、［ この要素や その子孫 ］の中の［ %n 個目の［ `~address可能な文字$に対応する~glyph（たち） ］に対する補足的な回転を表現する。 ◎ If a comma- or space-separated list of <number>s is provided, then the first <number> represents the supplemental rotation for the glyphs corresponding to the first character within this element or any of its descendants, the second <number> represents the supplemental rotation for the glyphs that correspond to the second character, and so on.

供された `number^t 値の個数が文字~数を超える場合、 余分な `number^t 値は無視されることになる。 ◎ If more <number>s are provided than there are characters, then the extra <number>s will be ignored.

供された `number^t 値の個数が文字~数に満たない場合、 残りの各~文字には，最後の `number^t により指定された回転~値を利用するモノトスル。 ◎ If more characters are provided than <number>s, then for each of these extra characters the rotation value specified by the last number must be used.

この要素に（妥当な） `rotate$a 属性~値が指定されている場合、 先祖の `rotate$a 属性は，［ この要素や その子孫 ］の中の文字には適用されないモノトスル。 ◎ If the attribute is not specified and if an ancestor of a ‘tspan’ element specifies a supplemental rotation for a given character via a ‘rotate’ attribute (nearest ancestor has precedence), then the given supplemental rotation is applied to the given character. If there are more characters than <number>s specified in the ancestor's ‘rotate’ attribute, then for each of these extra characters the rotation value specified by the last number must be used.

この補足的な回転は、［ ~glyphたちを描画するに伴い，`現在の~text位置$を改変する規則【送幅によるものなど】 ］に対する影響iは無い — `~path上の~text$に因る どの回転に対しても, および［ `text-orientation$p, `glyph-orientation-horizontal$p, `glyph-orientation-vertical$p ］に対しても補足的である。 ◎ This supplemental rotation has no impact on the rules by which current text position is modified as glyphs get rendered and is supplemental to any rotation due to text on a path and to text-orientation, glyph-orientation-horizontal, or glyph-orientation-vertical.

◎属名 `textLength@a ◎属値 `length-percentage$t | `number$t ◎属初 下を見よ ◎属ア 可 ◎表終 ◎ Name Value Initial value Animatable textLength <length-percentage> | <number> See below yes

作者の算出による【作者が定義する】［ この要素の中の文字~dataに対応するすべての送幅の~~総和 ］を与える。 この値は、~UAによる自前の計算を作者の手によるそれで較正するために利用される。 この計算には次も含まれる：

• 各~glyphの［ 横方向／縦方向 ］送幅
• ［ `letter-spacing$p, `word-spacing$p ］~propによる効果
• ［ この要素または その子孫 ］の［ `dx$a ／ `dy$a ］属性に因る調整

◎ The author's computation of the total sum of all of the advance values that correspond to character data within this element, including the advance value on the glyph (horizontal or vertical), the effect of properties letter-spacing and word-spacing and adjustments due to attributes ‘dx’ and ‘dy’ on this ‘text’ or ‘tspan’ element or any descendants. This value is used to calibrate the user agent's own calculations with that of the author.

この属性の目的は、 双方向-並替ngの後における視覚的な描画~順序において［ この要素に対応する最初, 最後に描画される~glyph用に，正確な整列を達成する ］ことを，作者に許容することである。 したがって,［［ （双方向-並替ngの後における視覚的な描画~順序における）最後に描画される文字 ］用の通常の~glyph送幅を超える，補足的な文字~間のアキ ］は、［ ~UAが， ~text文字列を `textLength$a の長さの中に収めるために［ 延張する／圧縮する ］適切な量を決定するとき ］には，（ほとんどの事例では）無視される。 ◎ The purpose of this attribute is to allow the author to achieve exact alignment, in visual rendering order after any bidirectional reordering, for the first and last rendered glyphs that correspond to this element; thus, for the last rendered character (in visual rendering order after any bidirectional reordering), any supplemental inter-character spacing beyond normal glyph advances are ignored (in most cases) when the user agent determines the appropriate amount to expand/compress the text string to fit within a length of ‘textLength’.

`textLength$a 属性が この要素にも先祖にも指定されている場合、 この要素の中のすべての文字~dataに対する調整は、 この要素の `textLength$a の値により排他的に制御される。 ただし、［ この要素の内容~用の調整~比率 ］が［ 同じ先祖 %先祖 を共有する他の内容~用に利用される調整~比率 ］と異なる副作用もあり得る。 ~UAは、［ %先祖 の中の他の内容~用の送幅~値の~~総和 ］は［ %先祖 上の送幅と この要素~用の送幅~値 ］との差を与えていると見做すモノトスル。 ◎ If attribute ‘textLength’ is specified on a given element and also specified on an ancestor, the adjustments on all character data within this element are controlled by the value of ‘textLength’ on this element exclusively, with the possible side-effect that the adjustment ratio for the contents of this element might be different than the adjustment ratio used for other content that shares the same ancestor. The user agent must assume that the total advance values for the other content within that ancestor is the difference between the advance value on that ancestor and the advance value for this element.

注記： この属性は、 ~textを［ 縮短する／延張する ］するなどの効果を得する利用に意図されるものではない。 ◎ This attribute is not intended for use to obtain effects such as shrinking or expanding text.

負な値は~errorになる（`~error処理$secを見よ）。 ◎ A negative value is an error (see Error processing).

`textLength$a 属性は、［ `shape-inside$p ／ `inline-size$p ］~propにより`包装~区画$が定義されていないときに限り適用される。 また、 （ `white-space$p 値が `pre^v ／ `pre-line^v にされていることに因り）強制d行l分断がある どの［ `text$e ／ `tspan$e ］要素にも適用されない。 ◎ The ‘textLength’ attribute is only applied when the wrapping area is not defined by the shape-inside or the inline-size properties. It is also not applied for any ‘text’ or ‘tspan’ element that has forced line breaks (due to a white-space value of pre or pre-line).

この属性が `text$e 要素の中のどこにも指定されていない場合、［ 作者の算出は，~UAにより計算された値に正確に合致している ］かのような効果になり、 送幅の調整は施されない。 ~DOM内の属性を`反映する$目的においては、 `初期~値$は，~UAにより計算された現在の長さを暗黙的な`利用元~単位$で表出した結果になる。 ◎ If the attribute is not specified anywhere within a ‘text’ element, the effect is as if the author's computation exactly matched the value calculated by the user agent; thus, no advance adjustments are made. For the purpose of reflecting the attribute in the DOM, the initial value is the current user-agent calculated length, expressed in implicit user units.

◎属名 `lengthAdjust@a ◎属値 `spacing^v | `spacingAndGlyphs^v ◎属初 `spacing^v ◎属ア 可 ◎表終 ◎ Name Value Initial value Animatable lengthAdjust spacing | spacingAndGlyphs spacing yes

`spacing^v

送幅のみ調整する一方で，~glyph自体は［ 伸張しない／圧縮しない ］ことを指示する。 ◎ Indicates that only the advance values are adjusted. The glyphs themselves are not stretched or compressed.

`spacingAndGlyphs^v

送幅を調整した上で，~glyph自体も`行内-基底~方向$において［ 伸張する／圧縮する ］ことを指示する。 ◎ Indicates that the advance values are adjusted and the glyphs themselves stretched or compressed in one axis (i.e., a direction parallel to the inline-base direction).

~UAには、当の~text文字列~用に正しい［ 始端, 終端 ］位置を達成することが要求されるが、 途中にある~glyphの所在は予測-可能でない — ~UAは、~text文字列を［ 伸張する／圧縮する ］高度な~algoを使役して［ 始端, 終端 ］の正しい位置決めと最適な~typographyの兼ね合いをとるかもしれないので。 ◎ The user agent is required to achieve correct start and end positions for the text strings, but the locations of intermediate glyphs are not predictable because user agents might employ advanced algorithms to stretch or compress text strings in order to balance correct start and end positioning with optimal typography.

当の~text文字列を成す最後の文字には、 送幅に対する調整は生じないことが多いが（ `textLength$a 属性の記述を見よ），~glyph自体の［ 伸張-法／圧縮-法 ］は適用されることに注意。 ◎ Note that, for a text string that contains n characters, the adjustments to the advance values often occur only for n−1 characters (see description of attribute ‘textLength’), whereas stretching or compressing of the glyphs will be applied to all n characters.

11.2.2. `x^a, `y^a, `dx^a, `dy^a, `rotate^a に対する注記

［ `text$e ／ `tspan$e ］要素~上の［ `x$a, `y$a, `dx$a, `dy$a, `rotate$a ］属性は、 個々の~glyphに正確な配置が要求される，最高品質の~typography局面において有用になる。 これらの属性は、 ~textの新たな行lの視覚-効果を達成するために有用になる — 文字どうしの細かい位置決め調整~用にも，~textの一節を新たな所在へ移動するなどの主だった位置決め調整~用にも（~SVG-11に互換）。 これらの属性は、 自動折返d~textにおいては無視されることに注意 （`内容~区画$が `inline-size$p ~propにより指定されたときの初期-`現在の~text位置$を除いて）。 ◎ The ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ on the ‘text’ and ‘tspan’ elements 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 a section of text to a new location to achieve the visual effect of a new line of text (compatible with SVG 1.1). Note that the ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ attributes are ignored for auto-wrapped text (except for the initial current text position when the content area is specified by the inline-size property).

Sydney 2015 会合にて、［ `dx^a, `dy^a, `rotate^a ］属性は，自動折返d~textにおいては無視するものと裁定された （それらを適用することは、技術的には困難でないが，本当に有用とは見えない）。 ◎ It was decided at the 2015 Sydney F2F that 'dx', 'dy', and 'rotate' would be ignored for auto-wrapped text. (Technically, it is not difficult to apply them but it was not seen as being really useful.)

高度な~typographic制御~用に~~微細な位置決め調整が必要yな状況では、 ~SVG内容~設計者は，文書に必要yな~fontが どこの~viewerからも可用になり （例：必要yな~font~dataを，当の~SVG内容と同じ~Web~siteに格納された［ ~SVG~font【~SVG-2では廃された】／代替~Web~font形式 ］の形に梱包する）、 それらの~viewerが当の~fontを期待される仕方で処理することを確保する必要がある （~systemの［ 能力／特性／~font~layoutの仕組み ］は、~systemごとに大きく変わる）。 ~SVG内容が［［ 特定0の種の~viewerにより処理される特定0の~font ］に対応することが意味される［ `x$a ／ `y$a ／ `dx$a ／ `dy$a ］属性~値 ］を包含していて，これらの要件いずれかが満たされない場合、 ~textは拙い品質で表示されるかもしれない。 ◎ 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 ‘x’, ‘y’, ‘dx’, or ‘dy’ attribute values which are meant to correspond to a particular font processed by a particular set of viewing software and either of these requirements is not met, then the text might display with poor quality.

［ `x$a ／ `y$a ／ `dx$a ／ `dy$a ／ `rotate$a ］属性に指定された一連の値 — 以下、 “当の~list” と総称する — には、次に挙げる追加的な規則も適用される： ◎ The following additional rules apply to attributes ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ when they contain a list of numbers:

• 1 個の文字 — %n 個目とする — が 1 個の~glyphに対応付けられるとき — この事例では、 当の~listを成す %n 個目の値が その~glyphに適用される。 ◎ When a single character maps to a single glyph – In this case, the n-th value for the ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ attributes is applied to the glyph that corresponds to the n-th character.
• 1 個の文字 — %n 個目とする — が複数個の~glyphに対応付けられるとき（例：基底~glyphの上端に~accent~glyphが配置されるとき） — この事例では、 `rotate$a 以外の当の~listを成す %n 個目の値は， 1 個目の~glyphを描画する前に適用される （すなわち，`現在の~text位置$を調整する）。 `rotate$a 値を成す %n 個目の値による回転~変形nは、 当の~glyphたちにひとまとめに — ~glyph間の送幅も含め — 適用される （すなわち，当の~glyphたちは，回転された一時的な座標系の中に描画される）。 ◎ When a single character maps to multiple glyphs (e.g., when an accent glyph is placed on top of a base glyph) – In this case, the n-th value for the ‘x’, ‘y’, ‘dx’, and ‘dy’ values are applied (i.e., the current text position is adjusted) before rendering the first glyph. The rotation transformation corresponding to the n-th ‘rotate’ 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 corresponding to the character are rendered into this rotated coordinate system).
• 複数個の文字が 1 個の~glyphに対応付けられるとき（例：合字）： この事例では — %n 個目, ( %n ~PLUS 1 ) 個目の文字が 1 個の~glyphに対応付けられるとするなら — 当の~listを成す %n 個目の値は，その~glyphに適用されるが、［ `x$a ／ `y$a ／ `rotate$a ］用の ( %n ~PLUS 1 ) 個目の値は無視され（例外: ~list内の最終- `rotate$a 値は依然として後続な文字に適用されることになる）、［ `dx$a, `dy$a ］用の ( %n ~PLUS 1 ) 個目の値は，後続な文字（すなわち， ( %n ~PLUS 2 ) 個目の文字）が在れば それに適用される — その文字に対応する~glyphを描画する前に，`現在の~text位置$を所与の量だけ並進することにより。 ◎ When multiple characters map to a single glyph (e.g., when a ligature is used) – Suppose that the n-th and (n+1)-th characters map to a single glyph. In this case, the n-th value for the ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ attributes all apply when rendering the glyph. The (n+1)-th values, however, for ‘x’, ‘y’, and ‘rotate’ are ignored (exception: the final ‘rotate’ value in the list would still apply to subsequent characters), whereas the ‘dx’ and ‘dy’ are applied to the subsequent character (i.e., the (n+2)-th character), if one exists, by translating the current text position by the given amounts before rendering the first glyph associated with that character.
• 複数個の文字が複数個の~glyphに一対一でないように対応付けられるとき（例： 3 個の文字が次のように 2 個の~glyphに対応付けられる — 1 個目の~glyphは 1 個目の文字と 2 個目の文字の片割れを表出する, 2 個目の~glyphは 2 個目の文字のもう片割れと 3 個目の文字を表出するときなど）： この事例では — %n 個目, ( %n ~PLUS 1 ) 個目, ( %n ~PLUS 2 ) 個目の文字が 2 個の~glyphに対応付けられるとするなら — `rotate$a 値を除く当の~listを成す %n 個目の値は， 1 個目の~glyphを描画する前に適用される （すなわち，`現在の~text位置$を調整する）。 `rotate$a 値を成す %n 個目の値による回転~変形nは、 2 個の~glyphにひとまとめに — その合間の送幅も含めて — 適用される （すなわち，当の~glyphたちは，回転された一時的な座標系の中に描画される）。 しかしながら，［ `x$a ／ `y$a ／ `rotate$a ］属性~用の ( %n ~PLUS 1 ), ( %n ~PLUS 2 ) 個目の値は適用されない （例外：~list内の最終- `rotate$a 値は、 依然として後続な文字に適用されることになる） 一方で［ `dx$a, `dy$a ］属性~用の ( %n ~PLUS 1 ), ( %n ~PLUS 2 ) 個目の値は、 後続な文字（すなわち， ( %n ~PLUS 3 ) 個目の文字）が存在するならば， その文字に対応する最初の~glyphを描画する前に — 所与の量だけ`現在の~text位置$を並進することにより — その~glyphに適用される。 ◎ 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 n-th, (n+1)-th and (n+2)-th characters map to two glyphs. In this case, the n-th value for the ‘x’, ‘y’, ‘dx’, and ‘dy’ values are applied (i.e., the current text position is adjusted) before rendering the first glyph. The rotation transformation corresponding to the n-th ‘rotate’ 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 (n+1)-th and (n+2)-th values, however, for the ‘x’, ‘y’, and ‘rotate’ attributes are not applied (exception: the final ‘rotate’ value in the list would still apply to subsequent characters), whereas the (n+1)-th and (n+2)-th values for the ‘dx’ and ‘dy’ attributes are applied to the subsequent character (i.e., the (n+3)-th character), if one exists, by translating the current text position by the given amounts before rendering the first glyph associated with that character.

• 双方向性との関係性： ~textは、 2 ~~段階の処理-で~lay-outされる — 双方向-~textは、 まず，右向き文字列に並替えられ、 ~text~layoutは結果の~text文字列の中で生じる。 `tspan$e 要素の中の文字~dataが並替えられたときは、 当の~listも文字との対応関係を保守するよう並替えられる。 例えば、次の `tspan$e 要素があって： ◎ Relationship to bidirectionality – 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 ‘tspan’ element is re-ordered, the corresponding elements within the ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ are also re-ordered to maintain the correspondence. For example, suppose that there is the following ‘tspan’ element:

  <tspan dx="11 12 13 14 15 0 21 22 23 0 31 32 33 34 35 36">Latin and Hebrew</tspan>
  

  単語 `Hebrew^l は左向きへ描かれることになるとするとき、 まず，文字~dataが `Latin and werbeH^l に並替えられ、 それに伴い `dx$a 属性~値を成す~listも "11 12 13 14 15 0 21 22 23 0 36 35 34 33 32 31" に並替えられる。 この並替ngの後、 各~文字に対応する~glyphたちが標準な右向き~layout規則を利用して位置される。 ◎ and that the word "Hebrew" will be drawn right-to-left. First, the character data and the corresponding values in the ‘dx’ list will be reordered, such that the text string will be "Latin and werbeH" and the list of values for the ‘dx’ attribute will be "11 12 13 14 15 0 21 22 23 0 36 35 34 33 32 31". After this re-ordering, the glyphs corresponding to the characters will be positioned using standard left-to-right layout rules.


<?xml version="1.0" standalone="no"?>
<svg
  width="10cm" height="3cm"
  viewBox="0 0 1000 300"
  xmlns="http://www.w3.org/2000/svg"
  version="1.1"
>
  <desc>
例 `tspan04^xl
— `rotate^a 値を成す値の個数が文字列を成す文字~数より少ないとき
◎
Example tspan04 - The number of rotate values is less than the number of characters in the string.
</desc>
  <text font-family="Verdana" font-size="55" fill="blue" >
    <tspan x="250" y="150" rotate="-30,0,30">
      Hello, out there
    </tspan>
  </text>
  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="998" height="298"
  fill="none" stroke="blue" stroke-width="2" />
</svg>

<?xml version="1.0" standalone="no"?>
<svg
  width="100%" height="100%"
  viewBox="0 0 500 120"
  xmlns="http://www.w3.org/2000/svg"
  version="1.1"
>
  <desc>
例 `tspan05^xl
— 入子な `tspan^e 要素への回転~値の伝播
◎
Example tspan05 - propagation of rotation values to nested tspan elements.
</desc>
  <text id="parent" font-family="Arial, sans-serif" font-size="32" fill="red" x="40" y="40"
    rotate="5,15,25,35,45,55">
    Not

    <tspan id="child1" rotate="-10,-20,-30,-40" fill="orange">
      all characters

      <tspan id="child2" rotate="70,60,50,40,30,20,10" fill="yellow">
        in
        <tspan id="child3">
          the
        </tspan>
      </tspan>

      <tspan id="child4" fill="orange" x="40" y="90">
        text
      </tspan>

      have a
    </tspan>

    <tspan id="child5" rotate="-10" fill="blue">
      specified
    </tspan>

    rotation
  </text>

  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="498" height="118" fill="none"
        stroke="blue" stroke-width="2" />
</svg>

11.4.1. `inline-size^p ~prop

Sydney 2015 会合の解決により， `extent^v を追加した （`~~参照先＠http://www.w3.org/2015/02/12-svg-minutes.html#action17$）。 `extent^v は、［ `width^a, `height^a ］属性を置換する。 June 27th, 2013 解決により追加された。 Linkoping F2F, June 11, 2015 の解決により， `inline-size^p 呈示~属性により置換された （`~~参照先＠http://www.w3.org/2015/06/11-svg-minutes.html#item09$）。 ◎ 'extent' added by resolution from February 12th, 2015. 'extent' replaces the 'width' and 'height' attributes, added by resolution from June 27th, 2013. Replaced by 'inline-size' presentation attribute per resolution from Linkoping F2F, June 11, 2015 .

`inline-size$p ~propは、 `包装~区画$を矩形な図形に設定することを許容する。 この~propの算出d値は、 この矩形の`行内~size$ — 横書き~text用には横幅／縦書き~text用には縦幅 — を設定する。 `塊~size$は無限になる。 値 0 は`包装~区画$の作成を不能化する。 ◎ The inline-size property allows one to set the wrapping area to a rectangular shape. The computed value of the property sets the width of the rectangle for horizontal text and the height of the rectangle for vertical text. The other dimension (height for horizontal text, width for vertical text) is of infinite length. A value of zero disables the creation of a wrapping area.

初期-`現在の~text位置$は、 `text$e 要素の［ `x$a, `y$a ］属性からとられる （または， `text$e 要素に与えられていない場合は、 最初の子 `tspan$e 要素の属性）。 初期-`現在の~text位置$は［ 右向き~text用には 矩形の左端／ 左向き~text用には 矩形の右端／ 縦書き~text用には 矩形の上端 ］にある。 ◎ The initial current text position is taken from the ‘x’ and ‘y’ attributes of the ‘text’ element (or first child ‘tspan’ element if the attributes are not given on the ‘text’ element). For left-to-right text, the initial current text position is at the left of the rectangle. For right-to-left text it is at the right of the rectangle. For vertical text, the initial current text position is at the top of the rectangle.

次に，この矩形（`包装~区画$）は、 `text-anchor$p ~propに則って~anchorされる — `包装~区画$の各~辺を利用して［ 始端, 真中, 終端 ］位置を決定するため。 ◎ The rectangle (wrapping area) is then anchored according to the text-anchor property using the edges of the wrapping area to determine the start, middle, and end positions.

注記： `inline-size$p ~propにより~textを折返す手法は、 整形済み~SVG~textに対する拡張であり、 作者は，単純に~text塊の`行内~size$の上限を与えられるようになる。 したがって［ `x$a, `y$a ］属性の利用は、［ `direction$p, `text-anchor$p ］~propとともに，~textの最初の行lを位置する。 全部的な両端揃えが必要な場合、 `shape-inside$p ~propを利用して，`包装~区画$を作成するベキである。 ◎ The inline-size property method to wrap text is an extension to pre-formatted SVG text where the author simply gives a limit to the width or height of the block of text; thus the use of the ‘x’ and ‘y’ attributes along with the direction and text-anchor properties to position the first line of text. If full justification is needed, the shape-inside property should be used to create the wrapping area.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="100"
  viewBox="0 0 300 100"
>

  <text x="50" y="30" style="font: 20px sans-serif; inline-size: 200px">
    This text wraps at 200 pixels.
  </text>

</svg>

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="100"
  viewBox="0 0 300 100"
>

  <text x="250" y="30"
	style="font: 20px PakType Naqsh; inline-size: 200px; direction: rtl;">
    هذا النص يلتف في 200 بكسل.</text>

</svg>

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="100" height="300"
  viewBox="0 0 100 300"
>

  <text
    x="62.5" y="25"
    inline-size="200"
    style="font: 25px IPAMincho; inline-size: 200px; writing-mode: vertical-rl;"
  >
    テキストは１０~~文字の後に折り~~返されます。</text>

</svg>

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="100"
  viewBox="0 0 300 100"
>

  <text x="50" y="30" style="font: 20px sans-serif; inline-size: 200px; text-anchor: middle">
    This text wraps at 200 pixels.
  </text>

</svg>

11.4.2. `shape-inside^p ~prop

`shape-inside$p ~propは、 `内容~区画$を［ `~CSS基本~図形$／`図形~要素$ ］に設定できるようにする。 ◎ The shape-inside property allows one to set the content area to a CSS basic shape or to an SVG shape.

注記： ~CSS／~HTMLにおいては、 `shape-inside$p は`塊~要素$に適用され，［ 絶対的／百分率 ］値は塊~要素に相対的に定義される。 ~SVGにおいては、［ 絶対的／百分率 ］値は［ 現在の`利用元~座標系$／ `viewBox$a ］に相対的に定義される。 ◎ In CSS/HTML shape-inside applies to block-level elements and absolute and percentage values are defined relative to the block-level element. In SVG absolute and percentage values are defined relative to the current user coordinate system and the ‘viewBox’.

`shape-inside^p を指定し直すのでなく， `CSS Shapes^cite を参照するようにする。 ◎ Do nor re-specify shape-inside but reference CSS Shapes.

`auto^v

~SVGの目的においては，この値は、 内容~区画は［ `inline-size$p ~prop利用して定義されるか，整形済み~text用に定義されるそれになる ］ベキであることを指示する。 ◎ For the purposes of SVG, the 'auto' value indicates that the content area should be defined using the inline-size property or as for pre-formatted text.

`basic-shape$t

図形は［ `circle()^v ／ `ellipse()^v ／ `polygon()^v ］値に基づいて算出される。 ~CSS値 `inset()^v は，~SVG用には妥当でないとする。 ◎ The shape is computed based on the values of one of 'circle()', 'ellipse()' or 'polygon()'. The CSS value of 'inset()' is invalid for SVG.

~CSS基本~図形を利用して横書き~textを折返す例： ◎ An example of using a CSS basic-shape for wrapping horizontal text.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="300"
  viewBox="0 0 300 300"
>

  <text style="font: 20px/25px sans-serif;
               text-align: center;
               shape-inside: circle(120px at 150px 150px);">
    Lorem ipsum dolor sit amet, consec-tetuer adipiscing elit...</text>

</svg>

`url$t†

`図形~要素$を参照する場合、 その要素が図形を定義する。 画像を参照する場合、 図形は［ `shape-image-threshold$p を利用して，指定された画像から抽出された~alpha~channel ］に基づいて算出される。 他を参照する場合、 値 `auto^v が指定されていたかのような効果になる。 【†原文 `uri^t は過去の残滓であろう】 ◎ If the <uri> references an SVG shape element, that element defines the shape. Otherwise, if the <uri> references an image, the shape is extracted and computed based on the alpha channel of the specified image using the shape-image-threshold. If the <uri> does not reference an SVG shape element or an image, the effect is as if the value ‘auto’ had been specified.

`図形~要素$への参照を利用して横書き~textを折返す例： ◎ An example of using a reference to an SVG shape for wrapping horizontal text.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="100"
  viewBox="0 0 300 100"
>

  <defs>
    <rect id="wrap" x="50" y="10" width="200" height="80"/>
  </defs>

  <text style="font: 20px sans-serif; shape-inside: url(#wrap);">
    This text wraps in a rectangle.</text>

</svg>

~CSS値［ `outside-shape^v, `shape-box^v, `display^v ］は、~SVG用には無効になる。 ◎ The CSS values of 'outside-shape', 'shape-box', and 'display' are invalid for SVG.

~SVGにおいては、 `shape-inside$p ~propには，図形の~listも許容される。 各~図形は、互いに独立な`内容~区画$を定義する。 ~textはまず、 1 個目の図形の内容~区画に~lay-outされる。 1 個目の図形を~overflowする場合、 ~overflowした~textは，次に来る図形に~lay-outされる — すべての~textが~lay-outされるか，可用な図形が尽きるまで。 ◎ SVG allows the shape-inside property to have a list of shapes. Each shape defines an independent content area. Text is first laid out in the content area of the first shape. If the text overflows the first shape, the overflow text is laid out in the next shape until all text is laid out or no more shapes are available.

注記： その効果は、~CSS`複-柱~layout$に類似する — 各 `柱~box$が任意な図形になれることを除いて。 ◎ The effect is similar to CSS columns, except that the columns can have arbitrary shapes.

すべての~textへの~accessibilityを確保するため — 例えば，利用者が~font~sizeを増やした事例など — “~overflow” 用の図形を供することが推奨される。 ◎ It is recommended that an overflow shape be provided to ensure the accessibility of all text in cases; for example, if a user increases the font size.

注記： 注記されるものを除き、 この~propの定義は `css-shapes-2$r の `shape-inside$pp を見よ ◎ Except as noted, see the CSS Shapes Module Level 2 for the definition of 'shape-inside'. [css-shapes-2]

`shape-inside^p は、 `CSS Exclusions and Shapes Module^cite が［ `Exclusions Module^cite, `Shapes Module^cite ］に分離されたとき除去された。 Tokyo joint SVG/CSS F2F 会合にて `css-shapes-2$r に~~再現することものと合意された。 ◎ 'shape-inside' was removed when the CSS Exclusions and Shapes Module was split into separate Exclusions and Shapes modules. At the Tokyo joint SVG/CSS F2F meeting, it was agreed that it would reappear in CSS Shapes Module Level 2.

11.4.3. `shape-subtract^p ~prop

`shape-subtract$p ~propは、 `包装~区画$から`内容~区画$の一部を排他できるようにする。 排他される区画は、［ `~CSS基本~図形$／`図形~要素$ ］の~list内に定義されたすべての区画の~~和領域になる。 ◎ The shape-subtract property allows one to exclude part of the content area from the wrapping area. The excluded area is the addition of all the areas defined in a list of CSS basic shapes and/or SVG shapes.

Sydney 2016 会合にて， `shape-outside^p の代わりに `shape-subtract^p を利用するベキであるものと解決された — 異なる挙動が要求されることに因り（ `shape-outside^p は排他体が成す区画を抑制する）。 ◎ It was resolved at the 2016 Sydney F2F that 'shape-subtract' should be uses instead of 'shape-outside' due to the different behavior required. ('shape-outside' reduces the area of an exclusion.)

注記： ［ 絶対的／百分率 ］値は、［ 現在の`利用元~座標系$／ `viewBox$a ］に相対的に定義される。 ◎ Absolute and percentage values are defined relative to the current user coordinate system and the ‘viewBox’.

`basic-shape$t

図形は［ `circle()^v ／ `ellipse()^v ／ `polygon()^v ］値に基づいて算出される。 【 `basic-shape^t は他の値もとり得るが、それらについては言及されてない。】 ◎ The shape is computed based on the values of one of 'circle()', 'ellipse()' or 'polygon()'.

`url$t †

`図形~要素$を参照する場合、 当の要素が供与する図形を定義する — この図形は `shape-margin$p の値に与えられる距離だけ拡げられる。 画像を参照する場合、［ `shape-image-threshold$p を利用して，指定された画像から抽出された~alpha~channel ］に基づいて算出される図形を供与することになる。 他を参照する場合、 無視される。 【†原文 `uri^t は過去の残滓であろう】 ◎ For any <uri> that references an SVG shape element, that element defines the contributing shape, expanded by the value of its shape-margin distance. For any <uri> that references an image, the contributing shape is extracted and computed based on the alpha channel of the specified image using the shape-image-threshold. If an <uri> does not reference an SVG shape element or an image, that <uri> is ignored.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="450" height="300"
  viewBox="0 0 450 300"
>

  <rect
    id="rect1"
    x="25" y="25" width="225" height="175"
    fill="white" stroke="black"
  />
  <rect
    id="rect2"
    x="200" y="125" width="225" height="150"
    fill="white" stroke="black"
    style="shape-margin:25px;"
  />

  <text
    style="shape-inside:url(#rect1);
           shape-subtract:url(#rect2);
           shape-padding:25px;
           font-family:DejaVu Sans;
           font-size:12px;
           text-align:justified;
           line-height:110%"
  >Lorem ipsum ...</text>
  <text
    style="shape-inside:url(#rect2);
           shape-padding:25px;
           font-family:DejaVu Sans;
           font-size:12px;
           text-align:justified;
           line-height:110%"
  >Lorem ipsum ...</text>
</svg>

11.4.4. `shape-image-threshold^p ~prop

`shape-image-threshold$p は、［ 画像を利用して図形を抽出するために利用される~alpha~channel ］の閾値を定義する。 値 0.5 は、［ 当の図形は、不透明度が 50% を超える画素~すべてを封入することになる ］ことを意味する。 ◎ The shape-image-threshold defines the alpha channel threshold used to extract the shape using an image. A value of 0.5 means that the shape will enclose all the pixels that are more than 50% opaque.

~SVGの目的においては、 この~propは `text$e 要素に適用される。 ◎ For the purposes of SVG, this property applies to ‘text’ elements.

注記： 注記されるものを除き、 この~propの定義は `css-shapes-1$r `shape-image-threshold$pp を見よ。 ◎ Except as noted, see the CSS Shapes Module Level 1 for the definition of 'shape-image-threshold'. [css-shapes-1]

11.4.5. `shape-margin^p ~prop

`shape-margin$p ~propは、 `shape-subtract$p で参照された図形に~marginを追加する。 それは、元の図形から指定された距離~以内にある すべての点からなる新たな図形を定義する。 この~propは、負な値はとれない。 【原文の “正な値のみをとる” は誤りであろう。】 ◎ The shape-margin property adds a margin to a shape referenced with shape-subtract. It defines a new shape where every point is the specified distance from the original shape. This property takes on positive values only.

`shape-margin^p を指定し直すのでなく、 `CSS Shapes^cite を参照するようにする。 ◎ Do nor re-specify shape-margin but reference CSS Shapes.

注記： 注記されるものを除き、 この~propの定義は `css-shapes-1$r の `shape-margin$pp を見よ。 ◎ Except as noted, see the CSS Shapes Module Level 1 for the definition of See 'shape-margin'. [css-shapes-1]

11.4.6. `shape-padding^p ~prop

`shape-padding$p ~propを利用すれば、 要素の内側で折返される行内~flow内容を~offsetできる。 ~offsetは、 `wrap-padding^p ~propにより作成され， 要素の内容~区画からの~offsetを与える。 この~propは正な値のみをとる。 ◎ The shape-padding property can be used to offset the inline flow content wrapping on the inside of elements. Offsets created by the ‘wrap-padding’ property are offset from the content area of the element. This property takes on positive values only.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="300"
  viewBox="0 0 300 300"
>

  <circle id="circle" cx="150" cy="150" r="125" fill="none" stroke="black"/>
  <text style="shape-inside: url(#circle);
	       shape-padding: 25px;
	       font: 18px DejaVu Sans;
	       text-align: justified;
	       line-height: 110%;">This is an
  example of wrapped text in SVG 2! There should
  be 25 pixel padding around the text. The text is
  justified on both sides. It looks good!</text>

</svg>

注記： 注記されるものを除き、 この~propの定義は `css-shapes-1$r の `shape-padding$pp を見よ。 ◎ Except as noted, see the CSS Shapes Module Level 2 for the definition of 'shape-padding'.

11.6.1. `white-space^p を介する複数行の~text

複数行の整形済み~textは、 `white-space$p 値に［ `pre^v ／ `pre-line^v ］を利用して作成できる。 これらの事例では、 ~LFや~CRは，強制d行l分断として保全され，新たな`行l~box$を作成する。 `行l~box$は~CSSの規則に従って堆積される。 ◎ Multi-line pre-formatted text may be created by using the white-space values pre or pre-line. In these cases, a line-feed or carriage return is preserved as a forced line break which creates a new line box. The line boxes are stacked following the rules of CSS.

11.6.2. ~glyphたちの再位置決め

基本的な~CSS~text~layout規則に則って ~textが~lay-outされた後、 ~SVGに特有な規則を利用して`~typographic文字$を位置し直せる。 絶対的な再位置決めは、［ `x$a, `y$a ］属性に絶対~座標を与えるか, 強制d行l分断により，予め述べれる。 `text-anchor$p ~propは、 絶対的な再位置決めに波及し得る。 相対的な再位置決めは、［ `dx$a, `dy$a ］属性に相対的な座標を与えることにより，予め述べれる。 `rotate$a 属性を利用すれば、 `~typographic文字$を任意に回転できる。 絶対的な再位置決め（ `text-anchor$p ~propに因る調整も含む）は、 相対的な再位置決め, 回転の前に行われる。 ◎ After text is laid out according to the basic CSS text layout rules, typographic characters can be repositioned using SVG specific rules. Absolute repositioning can be prescribed by giving absolute coordinates in the ‘x’ and ‘y’ attributes or by forced line breaks. Absolute repositioning may be influenced by the text-anchor property. Relative repositioning can be prescribed by giving relative coordinates in the ‘dx’ and ‘dy’ attributes. The typographic characters may be arbitrarily rotated by giving a list of values in the ‘rotate’ attribute. Absolute repositioning (including any adjustment due to the text-anchor property) is done before relative repositioning and rotation.

11.7.1. ~text折返ngに対する注記

図形~内に~textを~lay-outすることに関する少数の課題を，以下に挙げる例に示す。 ◎ The following examples illustrate a few issues with laying out text in a shape.

11.8.1. `textPath^e 要素

`path$a, `href$a 両~属性とも，~pathを指定する — `~typographic文字$たちが，それに沿って描画されることになるような。 ◎ Both the ‘path’ attribute and the ‘href’ attribute specify a path along which the typographic characters will be rendered.

`textPath$e 要素~上に両~属性とも指定された場合、 利用される~pathは［ `path$a 属性, `href$a 属性, `~xlink_href$a 属性 ］の順に優先されるモノトスル。 ◎ If both attributes are specified on a ‘textPath’ element, the path that is used must follow the following order of precedence: • path attribute href attribute xlink:href attribute

`path$a 属性が~errorを包含する場合、 `href$a 属性を利用するモノトスル。 ◎ If the ‘path’ attribute contains an error, the ‘href’ attribute must be used.

11.8.2. 属性

◎属名 `startOffset@a ◎属値 `length-percentage$t | `number$t ◎属初 `0^v ◎属ア 可 ◎表終

初期-現在の~text位置~用の，~pathの始端からの~offset — ~pathを `textPath$e 要素の座標系に変換した後，`~pathに沿う距離$~algoを利用して計算された。 ◎ An offset from the start of the path for the initial current text position, calculated using the user agent's distance along the path algorithm, after converting the path to the ‘textPath’ element's coordinate system.

`length$t 値は、 `textPath$e 要素~用の現在の利用元~座標系~内で測定される，~pathに沿う距離を表現する。 ◎ If a <length> other than a percentage is given, then the ‘startOffset’ represents a distance along the path measured in the current user coordinate system for the ‘textPath’ element.

百分率~値は、 ~path全体に沿う百分率~距離を表現する。 したがって，［ `0%^v ／ `100%^v ］は、 ~pathの［ 始端~点 ／ 終端~点 ］を指示する。 ◎ If a percentage is given, then the ‘startOffset’ represents a percentage distance along the entire path. Thus, startOffset="0%" indicates the start point of the path and startOffset="100%" indicates the end point of the path.

注記： 負な値や~path長さより大きい値（例： `150%^v ）も許容される。 ◎ Negative values and values larger than the path length (e.g. 150%) are allowed.

値を範囲［ `0%^v 〜 `100%^v ］に制限すると，~pathに沿って~textを移動する様な効果を作成し難くなる。 ◎ Limiting values to the range 0%-100% prevents easily creating effects like text moving along the path.

`~typographic文字$のうち，その中点が~path上にないものは描画されない。 ◎ Any typographic characters with mid-points that are not on the path are not rendered.

単独の`閉な下位path$（`基本~図形$に`等価な~path$も含む）からなる~path用には、`~typographic文字$は，~pathに沿って一周回に限り描画される 【が、開な下位pathのときのように始点＝終点で途切れることはない】 。 ~textは、［ `startOffset$a 属性により設定される，~path上の初期~位置 ］に， `text-anchor$p ~propに則って整列される — その値［ `start^v ／ `end^v ／ `middle^v ］に対し、~textは行lの［ 始端 ／ 終端 ／ 真中 ］が初期~位置に整列される。 ~textは、値［ `start^v ／ `end^v ］に対しては，~pathに沿って再度~初期~位置に達するまで描画され、 値 `middle^v に対しては，初期~位置から両~方向へ等~距離にある~path上の点に達するまで描画される。 ◎ For paths consisting of a single closed subpath (including an equivalent path for a basic shape), typographic characters are rendered along one complete circuit of the path. The text is aligned as determined by the text-anchor property to a position along the path set by the ‘startOffset’ attribute. For the start (end) value, the text is rendered from the start (end) of the line until the initial position along the path is reached again. For the middle, the text is rendered from the middle point in both directions until a point on the path equal distance in both directions from the initial position on the path is reached.

~path上の~text用の~pathとしての基本~図形の利用は、 Sydney 2015 会合 （`~~参照先＠http://www.w3.org/2015/02/12-svg-minutes.html#item05$） にて同意された（議事録は無いが）。 `startOffset^a 属性による，~pathを~~周回する効果を［ 1 個の閉な下位pathを伴う~path, その一周回 ］に制限することは、 London (2016) Editor's 会合 （`~~参照先＠https://www.w3.org/2016/04/22-svg-minutes.html#item02$） にて同意された。 ◎ Rendering all glyphs was agreed to for basic shapes at the Sydney (2015) meeting (but missing in minutes). Limiting the wrapping to a path with a single closed sub-path and to one loop, effected by the 'startOffset' attribute agreed to at the London (2016) Editor's Meeting.

◎ Value <length-percentage> | <number> initial value 0 Animatable yes

◎属名 `method@a ◎属値 `align^v | `stretch^v ◎属初 `align^v ◎属ア 可 ◎表終

~textを~path %~path に沿って描画するときに利用するベキ手法を指示する。 各種 値は、次を指示する： ◎ Indicates the method by which text should be rendered along the path.

`align^v ◎ A value of align indicates that＼

`~typographic文字$は — ［ 伸張する／歪曲する ］ことなく — 単純な変形n行列を利用して描画するベキである。 概して，各`~typographic文字$には、 補足的な［ 回転／拡縮／並進 ］変形nが行われる。 その結果，`~typographic文字$が続字にされるよう設計された~font （例： `cursive^en（筆記的）~font） では、 ~textを %~path に沿って描画したとき，続字が適正につながらなくなり得る。 ◎ A value of align indicates that＼ the typographic character should be rendered using simple 2×3 matrix transformations such that there is no stretching/warping of the typographic characters. Typically, supplemental rotation, scaling and translation transformations are done for each typographic characters to be rendered. As a result, with align, in fonts where the typographic characters are designed to be connected (e.g., cursive fonts), the connections may not align properly when text is rendered along a path.

`stretch^v ◎ A value of stretch indicates that＼

`~typographic文字$を成す~glyph外形線を、 まず~pathに変換してから，結果を成すすべての両端~点, 制御~点を調整する — それらの点が，変換-後も［［ 変換-前における，点から基底線への垂線 ］に対応する，変換-後の %~path に垂直な~vector ］沿いにあるように。 その結果、 ~glyphは伸張され，場合によっては歪曲される。 この~approachでは、 `cursive^en 用字系などの続字にされる`~typographic文字$は，それらの続字を保守することになる。 （この外形線は、 その各~点から %~path までの距離が（近似的に）変わらないような仕方で~Bezier曲線に変換されるベキである。） ◎ the typographic character outlines will be converted into paths, and then all end points and control points will be adjusted to be along the perpendicular vectors from the path, thereby stretching and possibly warping the glyphs. With this approach, connected typographic characters, such as in cursive scripts, will maintain their connections. (Non-vertical straight path segments should be converted to Bézier curves in such a way that horizontal straight paths have an (approximately) constant offset from the path along which the typographic characters are rendered.)

◎ Value align | stretch initial value align Animatable yes

◎属名 `spacing@a ◎属値 `auto^v | `exact^v ◎属初 `exact^v ◎属ア 可 ◎表終

~pathに沿って描画される`~typographic文字$どうしのアキを，~UAがどう決定するベキかを指示する。 ◎ Indicates how the user agent should determine the spacing between typographic characters that are to be rendered along a path.

各種 値は、次のようにするベキであることを~UAに指示する：

`exact^v

`~path上の~text~layout規則$にて指定されるアキ規則に正確に則って，`~typographic文字$を描画する ◎ A value of exact indicates that the typographic characters should be rendered exactly according to the spacing rules as specified in Text on a path layout rules.

`auto^v

視覚的に~~映える結果を達成するよう、 ~path上の~text~layout~algoにおいて，`~typographic文字$どうしのアキを調整する。 ◎ A value of auto indicates that the user agent should use text-on-a-path layout algorithms to adjust the spacing between typographic characters in order to achieve visually appealing results.

◎ Value auto | exact initial value exact Animatable yes

◎属名 `side@a ◎属値 `left^v | `right^v ◎属初 `left^v ◎属ア 可 ◎表終

~textを，~pathが進む方向の左右どちら側に配置するかを決定する。 値 `right^v を指定することは、 実質的に~pathを逆方向にする。 ◎ Determines the side of the path the text is placed on (relative to the path direction). Specifying a value of right effectively reverses the path.

注記： `閉な下位path$／ `基本~図形$（例：矩形, 真円, 楕円） の内側にも外側にも，~textを許容するために、 ~SVG-2にて追加された。 ◎ Added in SVG 2 to allow text either inside or outside closed subpaths and basic shapes (e.g. rectangles, circles, and ellipses).

Sydney 2015 会合にて， `side^a を追加するものと解決された （`~~参照先＠http://www.w3.org/2015/02/12-svg-minutes.html#item05$）。 ◎ Adding 'side' was resolved at the Sydney (2015) meeting.

◎ Value left | right initial value left Animatable yes

◎属名 `path@a ◎属値 `~path~data$ ◎属初 ナシ ◎属ア 可 ◎表終

指定された`~path~data$ 文字列は、 `~typographic文字$の描画-先になる~pathを述べる。 空~文字列は、 この要素~用の~path~dataは無いことを指示し、［ `textPath$e の中の~textは描画しない ／ `text$e 要素の`限界~box$に寄与しない ］ことを意味する。 属性が指定されていない場合、 `href$a に~pathが指定されていれば 代わりにそれが利用される。 ◎ A path data string describing the path onto which the typographic characters will be rendered. An empty string indicates that there is no path data for the element. This means that the text within the ‘textPath’ does not render or contribute to the bounding box of the ‘text’ element. If the attribute is not specified, the path specified with ‘href’ is used instead.

◎ Value path data initial value (none) Animatable yes

◎属名 `href@a ◎属値 `~URLt$ ◎属初 See above. ◎属ア 可 ◎表終

`~URL参照$は、 `path$a 属性が供されていない場合に，~glyphたちの描画-先になる`図形~要素$を与える。 この属性が利用されていて，その値は`無効な参照$である場合（例：参照先の要素は存在しないか`図形~要素$でない）、 `textPath$e 要素は~errorになり，その内容~全体を描画しないモノトスル。 ◎ An URL reference to the ‘path’ element or basic shape element onto which the glyphs will be rendered, if no ‘path’ attribute is provided. If the attribute is used, and the <url> is an invalid reference (e.g., no such element exists, or the referenced element is not a ‘path’ element) or basic shape, then the ‘textPath’ element is in error and its entire contents shall not be rendered by the user agent.

［ `~URL参照~属性$, `非推奨にされた~XLink属性$ ］用に定義された共通的な取扱いを見よ。 ◎ Refer to the common handling defined for URL reference attributes and deprecated XLink attributes.

◎ Value URL [URL] initial value See above. Animatable yes

参照先の［ `path$e ／`基本~図形$ ］要素の中の~path~data座標は、 参照先の要素が定義された所の座標系ではなく， 現在の `text$e 要素と同じ座標系と見做される。 参照先の要素~上の`transform$p 属性は、［ 現在の `text$e 要素~用の — その `transform$p ~propに因る座標系変換も含めた — 現在の利用元~座標系 ］に相対的な，補足的な座標系変換を表現する。 例えば、次の~SVG内容~素片： ◎ The path data coordinates within the referenced ‘path’ element or basic shape element are assumed to be in the same coordinate system as the current ‘text’ element, not in the coordinate system where the ‘path’ element is defined. The transform attribute on the referenced ‘path’ element or basic shape element represents a supplemental transformation relative to the current user coordinate system for the current ‘text’ element, including any adjustments to the current user coordinate system due to a possible transform property on the current ‘text’ element. For example, the following fragment of SVG content:

<svg
  xmlns="http://www.w3.org/2000/svg">
  <g `transform="translate(25,25)"^mark>
    <defs>
      <path id="path1"
        `transform="scale(2)"^mark
        path="M0,10 L40,20 80,10"
        fill="none" stroke="red"
      />
    </defs>
  </g>
  <text `transform="rotate(45)"^mark>
    <textPath href="#path1">~path上の~text</textPath>
  </text>
</svg>

による効果は、次と同じになるベキであり： ◎ should have the same effect as the following:

<svg
  xmlns="http://www.w3.org/2000/svg">
  <g `transform="rotate(45)"^mark>
    <defs>
      <path id="path1"
        `transform="scale(2)"^mark
        path="M0,10 L40,20 80,10"
        fill="none" stroke="red"/
      >
    </defs>
    <text>
      <textPath href="#path1">~path上の~text</textPath>
    </text>
  </g>
</svg>

次と等価になるベキである： ◎ and be equivalent to:

<svg
  xmlns="http://www.w3.org/2000/svg">
  <text `transform="rotate(45)"^mark>
    <textPath
      `path="M0,20 L80,40 160,20"^mark
    >~path上の~text</textPath>
  </text>
</svg>

まず， `transform="translate(25,25)"^c による `textPath$e 要素に対する効果は無い。 一方で， `transform="rotate(45)"^c は、［ `text$e 要素, ~path上の~text用の参照先の図形~用の `path$e の利用 ］どちらにも適用されることに注意。 更に， `transform="scale(2)"^c は、 ~path自体は拡縮するが，~pathに沿って配置される~textは拡縮しないことに注意。 【！(equivalent to multiplying every coordinate by 2 for simple linear paths)】 ◎ Note that the transform="translate(25,25)" has no effect on the ‘textPath’ element, whereas the transform="rotate(45)" applies to both the ‘text’ and the use of the ‘path’ element as the referenced shape for text on a path. Further note that the transform="scale(2)" scales the path (equivalent to multiplying every coordinate by 2 for simple linear paths), but does not scale the text placed along the path.

<?xml version="1.0" standalone="no"?>
<svg
  width="12cm" height="3.6cm"
  viewBox="0 0 1000 300"
  version="1.1"
  xmlns="http://www.w3.org/2000/svg"
>
  <defs>
    <path id="MyPath"
          d="M 100 200 
             C 200 100 300   0 400 100
             C 500 200 600 300 700 200
             C 800 100 900 100 900 100" />
  </defs>
  <desc>
例 `toap01^xl
— 単純な~path上の~text
◎
Example toap01 - simple text on a path
</desc>

  <use href="#MyPath" fill="none" stroke="red"  />
  <text font-family="Verdana" font-size="42.5" fill="blue" >
    <textPath href="#MyPath">
      We go up, then we go down, then up again
    </textPath>
  </text>

  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

<?xml version="1.0" standalone="no"?>
<svg
  width="12cm" height="3.6cm"
  viewBox="0 0 1000 300"
  version="1.1"
  xmlns="http://www.w3.org/2000/svg"
>
  <defs>
    <path id="MyPath"
          d="M 100 200 
             C 200 100 300   0 400 100
             C 500 200 600 300 700 200
             C 800 100 900 100 900 100" />
  </defs>
  <desc>
例 `toap02^xl
— `textPath^e の中の `tspan^e
◎
Example toap02 - tspan within textPath
</desc>

  <use href="#MyPath" fill="none" stroke="red"  />
  <text font-family="Verdana" font-size="42.5" fill="blue" >
    <textPath href="#MyPath">
      We go 
      <tspan dy="-30" fill="red" >
        up
      </tspan>
      <tspan dy="30">
        ,
      </tspan>
      then we go down, then up again
    </textPath>
  </text>

  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

<?xml version="1.0" standalone="no"?>
<svg
  width="12cm" height="3.6cm"
  viewBox="0 0 1000 300"
  version="1.1"
  xmlns="http://www.w3.org/2000/svg"
>
  <defs>
    <path id="MyPath"
          d="M 100 200 
             C 200 100 300   0 400 100
             C 500 200 600 300 700 200
             C 800 100 900 100 900 100" />
  </defs>
  <desc>
例 `toap03^xl
— `startOffset^a 属性を伴う~path上の~text
◎
Example toap03 - text on a path with startOffset attribute
</desc>

  <use href="#MyPath" fill="none" stroke="red"  />
  <text font-family="Verdana" font-size="42.5" fill="blue" >
    <textPath href="#MyPath" startOffset="80%">
      We go up, then we go down, then up again
    </textPath>
  </text>

  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

11.8.3. ~path上の~text~layout規則

~path上の~text用の~layout~flowは、 概念的には、元の~pathが直線~区分に引伸ばされ， 標準な`~text~layout~algo$sec規則が この仮想の直線~区分に適用され， その結果が元の~pathへ戻すように対応付けられる。 元の~pathは、横書き~text用には — ~pathの始端が線~区分の左端に対応付けられるように— 横に引伸ばされ，縦書き~text用には — ~pathの始端が線~区分の上端に対応付けられるように — 縦に引伸ばされる。 ~path上の~textには、［ 縦書き／双方向- ］`~text~layout~algo$sec規則も適用される。 ◎ Conceptually, for text on a path the target path is stretched out into either a horizontal or vertical straight line segment. For horizontal text layout flows, the path is stretched out into a hypothetical horizontal line segment such that the start of the path is mapped to the left of the line segment. For vertical text layout flows, the path is stretched out into a hypothetical vertical line segment such that the start of the path is mapped to the top of the line segment. The standard text layout rules are applied to the hypothetical straight line segment and the result is mapped back onto the target path. Vertical and bidirectional text layout rules also apply to text on a path.

~pathに沿う各~glyphの方位は、 個別に決定される。 ［ 横書き／縦書き ］~text用の~layout~flowにおける所与の~glyph用の既定の方位（ “上” 方向）は、 ~path上の~glyphが据えられた点から，~pathの進行方向に向かって反時計回りに［ 90 ／ 180 ］~degの方向を指す。 ◎ The orientation of each glyph along a path is determined individually. For horizontal text layout flows, the default orientation (the up direction) for a given glyph is along the vector that starts at the intersection point on the path to which the glyph is attached and which points in the direction 90 degrees counter-clockwise from the angle of the curve at the intersection point. For vertical text layout flows, the default orientation for a given glyph is along the vector that starts at the intersection point on the path to which the glyph is attached and which points in the direction 180 degrees from the angle of the curve at the intersection point.

<?xml version="1.0" standalone="no"?>
<svg
  width="12cm" height="3.6cm"
  viewBox="0 0 1000 300"
  version="1.1"
  xmlns="http://www.w3.org/2000/svg"
>
  <defs>
    <path id="MyPath"
          d="M 100 125 
             C 150 125 250 175 300 175
             C 350 175 450 125 500 125
             C 550 125 650 175 700 175
             C 750 175 850 125 900 125" />
  </defs>
  <desc>
例 `toap04^xl
— ~path上の~textの~layout規則
◎
Example toap04 - text on a path layout rules
</desc>

  <use href="#MyPath" fill="none" stroke="red"  />
  <text font-family="Verdana" font-size="60" fill="blue" letter-spacing="2" >
    <textPath href="#MyPath">
      Choose shame or get war 
    </textPath>
  </text>

  <!-- 
`rect^e 要素を利用して表示域の外形線を示す
◎
Show outline of viewport using 'rect' element
 -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

~path上の右向き横書き~text（すなわち，~glyph方位は`行内-基底~方向$に垂直）用の~layout規則は、次に従う： ◎ For left-to-right horizontal text layout along a path (i.e., when the glyph orientation is perpendicular to the inline-base direction the layout rules are as follows:

【以下、この節の内容は未訳。】

11.10.1. ~SVG~prop

この節は、この仕様の他所が受持っていない~SVGに特有な~propを受持つ。 ◎ This section covers properties that are not covered elsewhere in this specification and that are specific to SVG.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="100"
  viewBox="0 0 300 100"
>

  <text x="150" y="30" style="font: 20px sans-serif; white-space: pre-line;
                              text-anchor: middle;">
    This multi-line text is
    anchored to the middle.</text>

</svg>

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="200" height="150"
  viewBox="0 0 200 150"
>
  <path d="m 100,0 0,150" style="fill:none;stroke:#add8e6"/>
  <text x="100 100 100" y="50 95 140"
	style="font-size: 42px; text-anchor: middle">I❤SVG</text>
</svg>

11.10.2. ~SVGへの順応

この節は、 この仕様において他所が受持っていない~CSS~propのうち，［ ~SVGに特有な順応があるもの／~SVG-11から有意に改められたもの ］を受持つ。 ◎ This section covers CSS properties that are not covered elsewhere in this specification and have either SVG specific adaptions or are significantly altered from SVG 1.1.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="100%" height="100%"
  viewBox="0 0 600 72"
  direction="rtl"
  xml:lang="fa"
>

  <title direction="ltr" xml:lang="en">Right-to-left Text</title>
  <desc direction="ltr" xml:lang="en">
左向きの言語が支配的な文書における， `direction^p ~propの単純な用例
◎
A simple example for using the 'direction' property in documents that predominantly use right-to-left languages.
</desc>

  <text x="300" y="50" text-anchor="middle" font-size="36">داستان SVG 1.1 SE طولا ني است.</text>

</svg>

<?xml version="1.0" encoding="utf-8"?>
<svg
  xmlns="http://www.w3.org/2000/svg"
  width="100%" height="100%"
  viewBox="0 0 600 72"
  direction="rtl"
  xml:lang="he"
>

  <title direction="ltr" xml:lang="en">Right-to-left Text</title>
  <desc direction="ltr" xml:lang="en">
左向きの言語が支配的な文書における
`direction^p, `unicode-bidi^p ~propの用例
◎
An example for using the 'direction' and 'unicode-bidi' properties in documents that predominantly use right-to-left languages.
</desc>

  <text x="300" y="50" text-anchor="middle" font-size="36"> כתובת MAC:&#x200F;
    <tspan direction="ltr" unicode-bidi="embed">00-24-AF-2A-55-FC</tspan> 
  </text>

</svg>

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300" height="150"
  viewBox="0 0 300 150"
>
  <style>
    text { font: 25px sans-serif; white-space: pre; }
    path { fill: none; stroke: #add8e6; }
  </style>

  <path d="m  50,0 0,150"/>
  <path d="m 200,0 0,150"/>

  <text x="50" y="35"  inline-size="100" style="overflow:visible">SVG is awesome</text>
  <text x="50" y="85"  inline-size="100" style="text-overflow:clip">SVG is awesome</text>
  <text x="50" y="135" inline-size="100" style="text-overflow:ellipsis">SVG is awesome</text>

</svg>

11.10.3. 空白

注記： ~SVG-2にて新たに~~導入された。 空白の取扱いを制御する もっと有用な仕方を許容するため， `white-space$p が追加された。 ~SVGを~HTML／~CSSによる~text処理に揃える。 新たな内容において非推奨にされる `~xml_space$a は、 後方-互換性を得るために維持される。 ◎ New in SVG 2. Added white-space to allow a more useful way to control white-space handling. Aligns SVG and HTML/CSS text processing. ‘xml:space’ deprecated in new content, retained for backwards compatibility.

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="270" height="200"
  viewBox="0 0 270 200"
>
  <text
    x="240" y="30"
    style="font: 20px/30px IPAMincho; writing-mode: vertical-rl; white-space: pre-line;"
  >いろはにほへと
    ちりぬるを
    わかよたれそ
    つねならむ
    ういのおくやま
    けふこえて
    あさきゆめみし
    ゑひもせす</text>
</svg>

[01]␣␣<text xml:space='default'>
[02]␣␣␣␣WS␣example
[03]␣␣␣␣indented␣lines
[04]␣␣</text>
[05]
[06]
[07]␣␣<text xml:space='default'>
[08]WS␣example
[09]non-indented␣lines
[10]␣␣</text>

11.12.1. ~text選択の実装~注記

以下の実装~注記では、 `~text選択~操作o＠#TextSelection$の間， どの文字たちが選択されるか裁定する~algoを述べる。 ◎ The following implementation notes describe the algorithm for deciding which characters are selected during a text selection operation.

~text選択~操作oが生じるに伴い（例：利用者が~mouseを~clickして~dragして選択を同定する間）、 ~UAは［ `始端~選択~位置^i, `終端~選択~位置^i ］を決定する — 両者とも~text文字列~内の ある 2 個の文字の合間の位置を表現する。 これらを決定した後、 ~UAは，適切な文字たちを選択する — 結果の~text選択は、 選択なしか, 同じ `text$e 要素の中で ~DOM内の位置が論理的に連続する文字たちからなる。 ◎ As the text selection operation occurs (e.g., while the user clicks and drags the mouse to identify the selection), the user agent determines a start selection position and an end selection position, each of which represents a position in the text string between two characters. After determining start selection position and end selection position, the user agent selects the appropriate characters, where the resulting text selection consists of either: • no selection or • a start character, an end character (possibly the same character), and all of the characters within the same ‘text’ element whose position in the DOM is logically between the start character and end character.

~pointer装置を備える~system上で， `始端~選択~位置^i を決定するときは、 ~UAは，選択~操作oを起動した時点（例： ~mouseを押した）における現在の~pointerの所在に基づいて，［ 描画された各~glyphに対応している文字 ］たちのうち，どの文字~間の境界が最良かを決定する（例：最も近い）。 ~UAは，選択~操作oを完了するまで追跡して（例：~mouse~drag）、 選択~操作oが終止したとき（例： ~mouseを放した）， `終端~選択~位置^i 用にどの文字~間の境界が最良か決定する（例：最も近い）。 ◎ On systems with pointer devices, to determine the start selection position, the SVG user agent determines which boundary between characters corresponding to rendered glyphs is the best target (e.g., closest) based on the current pointer location at the time of the event that initiates the selection operation (e.g., the mouse down event). The user agent then tracks the completion of the selection operation (e.g., the mouse drag, followed ultimately by the mouse up). At the end of the selection operation, the user agent determines which boundary between characters is the best target (e.g., closest) for the end selection position.

双方向性に因る文字~並替ngは生じていない場合、 選択は［ `始端~選択~位置^i, `終端~選択~位置^i ］の合間にあるすべての文字たちからなる。 例えば、 `text$e 要素が 文字列 `abcdef^l を包含していて，［ 始端~選択~位置は 0, 終端~選択~位置は 3 ］の場合（ "a" の左端~側を位置 0 と見做す）、 選択は `abc^l になる。 ◎ If no character reordering has occurred due to bidirectionality, then the selection consists of all characters between the start selection position and end selection position. For example, if a ‘text’ element contains the string "abcdef" and the start selection position and end selection positions are 0 and 3 respectively (assuming the left side of the "a" is position zero), then the selection will consist of "abc".

~UAが双方向-~textの選択を実装している下で、 論理-順序で不連続な文字~並びの合間で選択を開始した（または終止した）場合、 選択の一部を成すと見なせる文字の組合nは，複数あり得るが、 その中から選ぶときは，視覚的な描画~順序に最も近く合致するものを選ぶモノトスル。 ◎ When the user agent is implementing selection of bidirectional text, and when the selection starts (or ends) between characters which are not contiguous in logical order, then there might be multiple potential combinations of characters that can be considered part of the selection. The algorithms to choose among the combinations of potential selection options shall choose the selection option which most closely matches the text string's visual rendering order.

複数の文字が 1 個以上の~glyphが成す集合に~~不可分的に対応付けられる場合、 ~UAは，集合の途中から開始する選択を許容しないか， `can attempt to allocate portions of the area taken up by the glyph set to the characters that correspond to the glyph.^en 【集合~全体から選択し始めたかのようにできる？】 ◎ When multiple characters map inseparably to a given set of one or more glyphs, the user agent can either disallow the selection to start in the middle of the glyph set or can attempt to allocate portions of the area taken up by the glyph set to the characters that correspond to the glyph.

~mouseなどの~pointer装置を~supportする~system上の~UAには、 ~textを選択するための仕組みを供することが要求される — 所与の~textが［ ~event処理~規則が優先されることに因り，~text選択を阻むこともある ］ような~event~handlerや~linkに結付けられていようが （`§ ~pointer~event＠~SVGinteract#PointerEvents$を見よ）。 例えば、文字~cellの周りに［ ~text選択~操作oは起動するが ~event~handlerや~linkは起動しない，小さな追加的な領域 ］を供するなどが挙げられる。 ◎ For systems which support pointer devices such as a mouse, the user agent is required to provide a mechanism for selecting text even when the given text has associated event handlers or links, which might block text selection due to event processing precedence rules (see Pointer events). One implementation option: For platforms which support a pointer device such as a mouse, the user agent may provide for a small additional region around character cells which initiates text selection operations but does not initiate event handlers or links.

11.13.1. ~interface `SVGTextContentElement^I0

`SVGTextContentElement$I ~interfaceは、 子~text内容の描画を~supportする要素により実装される。 ◎ The SVGTextContentElement interface is implemented by elements that support rendering child text content.

この~interface上の~methodにおいて［ 文字への~index／文字の個数 ］を参照する所は、［ ~UTF-16符号単位を指す~index／ ~UTF-16符号単位の個数 ］として解釈される。 これは、~UTF-16符号単位を それら［ ~index／文字の個数 ］として利用する ~DOM `CharacterData$I ~interface上の~methodとの一貫性を得るためである。 したがって，例えば、 `text$e 要素の~text内容が `10000^U など，~BMPに属さない単独の文字である場合、 その要素~上で `getNumberOfChars()$m を呼出したときは， 2 を返すことになる — 2 個の~UTF-16符号単位（~surrogate~pair）を利用して， 1 個の文字を表現しているので。 ◎ For the methods on this interface that refer to an index to a character or a number of characters, these references are to be interpreted as an index to a UTF-16 code unit or a number of UTF-16 code units, respectively. This is for consistency with DOM Level 2 Core, where methods on the CharacterData interface use UTF-16 code units as indexes and counts within the character data. Thus for example, if the text content of a ‘text’ element is a single non-BMP character, such as U+10000, then invoking getNumberOfChars on that element will return 2 since there are two UTF-16 code units (the surrogate pair) used to represent that one character.

[Exposed=Window]
interface `SVGTextContentElement^I0 : `SVGGraphicsElement$I {

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

  [SameObject] readonly attribute `SVGAnimatedLength$I `textLength$m;
  [SameObject] readonly attribute `SVGAnimatedEnumeration$I `lengthAdjust$m;

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

`SVGTextContentElement$I 上に定義される数量- LENGTHADJUST 定数は、 `lengthAdjust$a 属性がとれる各種~keyword値を表現するために利用される。 それらの意味は： ◎ The numeric length adjustment type constants defined on SVGTextContentElement are used to represent the keyword values that the ‘lengthAdjust’ attribute can take. Their meanings are as follows:

【 以下に現れる “`~typographic文字$” は、 各~描画~instanceごとに別個と見なされることに注意。 例えば文字列 "aa" を成す 1 個目, 2 個目の "a" に対応する`~typographic文字$は、 `同じでない^em。 】

`textLength@m

`textLength$a 内容~属性を`反映する$。 ◎ The textLength IDL attribute reflects the ‘textLength’ content attribute.

注記： `textLength$a 内容~属性の初期~値は、 ~UAが当の要素~用に計算した長さに等しいものと定義される。 言い換えれば、 その内容~属性が無いときは，この~IDL属性は［ 同じ要素~上の `getComputedTextLength()$m が返す値に等しい，利用元~単位による長さ ］で初期化される。 ◎ The initial value of the ‘textLength’ content attribute is defined to equal the user-agent's calculated length for the element. In other words, when the content attribute is not present, the IDL property is initialized with a base length equal to the return-value of getComputedTextLength on the same element, as a length in user units.

`lengthAdjust@m

`lengthAdjust$a 内容~属性を`反映する$。 `lengthAdjust$a 用の`数量-型~値$は、 上で述べた数量- LENGTHADJUST 定数~表tに与えられる。 ◎ The lengthAdjust IDL attribute reflects the ‘lengthAdjust’ content attribute. The numeric type values for ‘lengthAdjust’ are as described above in the numeric length adjust type constant table.

`getNumberOfChars()@m

この要素の中で描画に可用な`~address可能な文字$の総数を返す。 ◎ The getNumberOfChars method returns the total number of addressable characters available for rendering within the current element, regardless of whether they will be rendered.＼

【 原文には “`regardless of whether they will be rendered^en （描画されるかどうかに関わらず）” とも記されているが、 実際の~algoに合致していない。 】【 下の~algoは，原文では単に文字の個数を返しているが、 他からも利用できるよう，この訳では文字の~listを返すように改変している。 】

その~method~手続きは、 コレの`~address可能な文字~list$の`~size$を返す。 ◎ When getNumberOfChars() is called, the following steps are run:

所与の %~node の `~address可能な文字~list@ は、次を走らせた結果の`~list$を返す： ◎ • Let node be the element or node upon which this method was called

1. ~IF［ %~node は `Text$I である ］ ⇒ ~RET ［ %~node の~text内容を， %~node の親~要素の `white-space$p ~propの値に則って空白を正規化した結果 ］を成す各~符号単位からなる同順の`~list$ ◎ If node is a DOM text node, return the length of the text content of node, after normalizing whitespace according to the value of the white-space property on its parent element.

2. ~IF［ %~node は `Element$I である ］： ◎ If node is an Element:

   1. ~IF［ %~node は`描画されない＠~SVGrender#Rendered-vs-NonRendered$ （例： `display$p ~propの使用~値は `none^v ） ］ ⇒ ~RET 空~list ◎ If the element is not rendered (e.g., because the display property has the used value none), then return 0;
   2. %結果 ~LET 空~list ◎ Otherwise, set count to 0, and＼
   3. %~node を成す ~EACH( %子 ) に対し ⇒ %結果 の末尾に［ %子 の`~address可能な文字~list$ ］を連結する ◎ for each child of node: • Recursively call this algorithm and add the returned value to count.
   4. ~RET %結果 ◎ Return count.
3. ~RET 空~list （他のすべての~node型（例： `Comment$I ）用） ◎ For all other node types (e.g., DOM comments), return 0.

`getComputedTextLength()@m

要素の中の~textの “長さ” を算出する。 ◎ The getComputedTextLength method is used to compute a "length" for the text within the element.＼

その~method~手続きは： ◎ When getComputedTextLength() is called, the following steps are run:

1. %個数 ~LET コレの`~address可能な文字~list$の`~size$ ◎ Let count be the value that would be returned if the getNumberOfChars method were called on this element.
2. ~RET コレ上で， `getSubStringLength()$m ~methodの手続きを引数 ( 0, %個数 ) を渡して~callした結果 ◎ Let length be the value that would be returned if the getSubStringLength method were called on this element, passing 0 and count as arguments. ◎ Return length.

`getSubStringLength(charnum, nchars)@m

要素の中の~textを成す部分文字列に対し，整形された~textの総~送幅~距離を算出する。 ◎ The getSubStringLength method is used to compute the formatted text advance distance for a substring of text within the element.＼

その~method~手続きは： ◎ When getSubStringLength(charnum, nchars) is called, the following steps are run:

1. %文字~list ~LET コレの`~address可能な文字~list$ ◎ Assign an index to each addressable character in the DOM within this element, where the first character has index 0.
2. ~IF［ %charnum ~GTE %文字~list の`~size$ ］~OR［ %nchars ~LT 0 ］ ⇒ ~THROW `IndexSizeError$E ◎ If charnum is greater than the highest index assigned to a character or if nchars is negative, then throw an IndexSizeError.
3. %長さ ~LET 0 （利用元~単位による長さを表す） ◎ Let length be a length in user units, initialized to 0.

4. ~EACH( %~index ~IN { %charnum 〜 %charnum ~PLUS %nchars ~MINUS 1 } ) に対し： ◎ For each addressable character in the DOM within this element that has an index such that charnum ≤ index < (charnum + nchars):

   1. %文字 ~LET %文字~list[ %~index ]

   2. ~IF［ %文字 は、`~typographic文字$ %T に対応する ］~AND［ %文字 は、 %T に対応する文字のうち，文書~順序で最初の文字である ］： ◎ If the character corresponds to a typographic character and it is the first character in document order to correspond to that typographic character, then:

      1. %長さ ~INCBY ［ %T の送幅を，~font~kerning効果があれば それで調整した結果 ］ ◎ Add the advance of the typographic character to length, adjusted for any font kerning in effect.
      2. ~IF［［ `letter-spacing$p ／ `word-spacing$p ］~propは %T の直後に空間を供与している ］ ⇒ %長さ ~INCBY その空間 ◎ If the letter-spacing or word-spacing properties contributed space just after the typographic character, then add that space to length.

      注記： これは例えば，当の部分文字列~内に一部しか含まれていない合字がある場合、 %T の送幅, および［ `letter-spacing$p ／ `word-spacing$p ］による後続な空間は、 合字を成す最初の文字の~text長さにアテガわれることになることを意味する。 ◎ This means that, for example, if there is a ligature that is only partly included in the substring, then the advance of the typographic character and any subsequent letter-spacing or word-spacing space will be assigned to the first character's text length.

5. ~RET %長さ ◎ Return length.

注記： 以前の~versionの~SVGにおける［ この~method ／ `getComputedTextLength()$m ］は、 子~要素~上の［ `dx$a ／ `dy$a ］に因る，行内~方向への位置決め調整も含むことを要求していた — 返される値が，~UAによる`textLength$a 用の計算に等価になるよう。 しかしながら，それは、 拙く指定され, 拙く実装されていた上に，その便益は疑わしいので、 実装に合致するよう単純~化された。 ◎ Previous versions of SVG required that this method and getComputedTextLength also include positioning adjustments in the inline direction due to ‘dx’ or ‘dy’ on child elements, so that the returned value would be equivalent to the user agent's calculation for ‘textLength’. However, it was poorly specified, poorly implemented, and of dubious benefit, so has been simplified to match implementations.

~text長さ~methodに対する変更は、 August 2015 Paris F2F にて解決された （`~~参照先＠https://lists.w3.org/Archives/Public/www-svg/2015Aug/att-0009/SVGWG-F2F-minutes-20150824.html#item04$）。 ◎ Change to text length methods resolved at August 2015 Paris face-to-face.

`getStartPositionOfChar(charnum)@m

~text~layoutが遂行された後における`~typographic文字$の位置を取得する。 ◎ The getStartPositionOfChar method is used to get the position of a typographic character after text layout has been performed.＼

その~method~手続きは： ◎ When getStartPositionOfChar(charnum) is called, the following steps are run:

1. %~cluster ~LET `文字~用の~typographic文字を見出す$( コレ, %charnum ) ◎ Let cluster be the result of finding the typographic character for the character at index charnum within the current element.
2. ~IF［ %~cluster ~EQ ~NULL ］ ⇒ ~THROW `IndexSizeError$E ◎ If cluster is null, then throw an IndexSizeError.
3. %p ~LET ~index %charnum に対応する`~typographic文字$の`整列~点$ — コレの座標系における ◎ Let p be the alignment point of the typographic character that correspond to the character at index charnum, in the coordinate system of the current element.
4. ~RET 点 %p を表現する新たな `DOMPoint$I ~obj 【！detached:~SVGshapes#PointMode】 ◎ Return a newly created, detached DOMPoint object representing the point p.

`getEndPositionOfChar(charnum)@m

~text~layoutを遂行した後における`~typographic文字$の末尾~位置を取得する。 ◎ The getEndPositionOfChar method is used to get the trailing position of a typographic character after text layout has been performed.＼

その~method~手続きは： ◎ When getEndPositionOfChar(charnum) is called, the following steps are run:

1. %~cluster ~LET `文字~用の~typographic文字を見出す$( コレ, %charnum ) ◎ Let cluster be the result of finding the typographic character for the character at index charnum within the current element.
2. ~IF［ %~cluster ~EQ ~NULL ］ ⇒ ~THROW `IndexSizeError$E ◎ If cluster is null, then throw an IndexSizeError.
3. %p ~LET コレの座標系における， %~cluster の`整列~点$ ◎ Let p be the alignment point of cluster that correspond to the character at index charnum, in the coordinate system of the current element.
4. %方向~vector ~LET %~cluster の送り方向を指す単位~vector — この方向には、 次に挙げるものを織り込む ⇒＃ 利用されている書字~mode, 文字の方向, `text-orientation$p ~prop, `glyph-orientation-horizontal$p ~prop, `glyph-orientation-vertical$p ~prop, %~cluster に適用された `rotate$a 値, `textPath$e に因り適用された回転 ◎ Let direction be a unit vector in the direction of the cluster's advance. This direction takes into account the writing mode being used, the direction of the character, the text-orientation, glyph-orientation-horizontal and glyph-orientation-vertical properties, any ‘rotate’ value that applies to cluster, and any rotation applied to due a ‘textPath’.
5. %p ~INCBY ( %~cluster の送幅 ~MUL %方向~vector ) ◎ Let advance be cluster's advance. ◎ Set p to p + advance · direction.
6. ~RET 点 %p を表現する新たな `DOMPoint$I ~obj 【！detached:~SVGshapes#PointMode】 ◎ Return a newly created, detached DOMPoint object representing the point p.

`getExtentOfChar(charnum)@m

所与の`~typographic文字$に対応する~glyph~cellを最も緊密に囲う限界~boxを算出する。 ◎ The getExtentOfChar method is used to compute a tight bounding box of the glyph cell that corresponds to a given typographic character.＼

その~method~手続きは： ◎ When getExtentOfChar(charnum) is called, the following steps are run:

1. %~cluster ~LET `文字~用の~typographic文字を見出す$( コレ, %charnum ) ◎ Let cluster be the result of finding the typographic character for the character at index charnum within the current element.
2. ~IF［ %~cluster ~EQ ~NULL ］ ⇒ ~THROW `IndexSizeError$E ◎ If cluster is null, then throw an IndexSizeError.
3. ~RET 次を表現する新たな `DOMRect$I ~obj ⇒ コレの座標系における［ %~cluster 用の~glyph~cellを最も緊密に囲う限界~box ］を形成する矩形 （~glyphは回転され得るので、~cellと結果の矩形は異なり得る） ◎ Let quad be the potentially rotated rectangle in the current element's coordinate system that is the glyph cell for cluster. ◎ Let rect be the rectangle that forms the tightest bounding box around quad in the current element's coordinate system. ◎ Return a newly created DOMRect object representing the rectangle rect.

`getRotationOfChar(charnum)@m

`~typographic文字$の回転を取得する。 ◎ The getRotationOfChar method is used to get the rotation of typographic character.＼

その~method~手続きは： ◎ When getRotationOfChar(charnum) is called, the following steps are run:

1. %~cluster ~LET `文字~用の~typographic文字を見出す$( コレ, %charnum ) ◎ Let cluster be the result of finding the typograhic character for the character at index charnum within the current element.
2. ~IF［ %~cluster ~EQ ~NULL ］ ⇒ ~THROW `IndexSizeError$E ◎ If cluster is null, then throw an IndexSizeError.
3. ~RET %~cluster の送り方向を表現する `deg^u 単位による角度 — この方向には、次に挙げるものを織り込む ⇒＃ 利用されている書字~mode, 文字の方向, `text-orientation$p ~prop, `glyph-orientation-horizontal$p ~prop, `glyph-orientation-vertical$p ~prop, %~cluster に適用された `rotate$a 値, `textPath$e に因り適用された回転 ◎ Let direction be the angle in degrees that represents the direction of the cluster's advance. This direction takes into account the writing mode being used, the direction of the character, the text-orientation, glyph-orientation-horizontal and glyph-orientation-vertical properties, any ‘rotate’ value that applies to cluster, and any rotation applied to due a ‘textPath’. ◎ Return direction.

`getCharNumAtPosition(point)@m

座標系~内の所与の位置に~glyphを描画させた文字の~indexを見出す。 文字と~glyphの関係性は一対一でないので、 関連な`~typographic文字$を成す最初の文字のみ返される ◎ The getCharNumAtPosition method is used to find which character caused a text glyph to be rendered at a given position in the coordinate system. Because the relationship between characters and glyphs is not one-to-one, only the first character of the relevant typographic character is returned＼

その~method~手続きは： ◎ When getCharNumAtPosition(point) is called, the following steps are run:

1. %文字~list ~LET %要素 の中の~DOM内の各~文字からなる文書~順序による`~list$ 【`~address可能な文字~list$ではないことに注意。】 ◎ Assign an index to each character in the DOM within this element, where the first character has index 0. ◎ Let last be the highest index assigned to a character. ◎ Let charnum be 0.
2. %結果 ~LET ~MINUS 1 ◎ Let result be -1.

3. ~EACH( %~index ~IN { 0 〜 %文字~list の`~size$ ~MINUS 1 } ) に対し： ◎ While charnum < last:

   1. %文字 ~LET %文字~list[ %~index ] ◎ ↓
   2. ~IF［ %文字 はある`~typographic文字$ %T に対応する ］~AND［ %文字 は %文字~list 内で %T に対応する最初の文字である ］~AND［ %point はコレの座標系~内で %T 用の~glyph~cellの中にある ］ ⇒ %結果 ~SET %~index ◎ If the character at index charnum corresponds to a typographic character and it is the first character in document order to correspond to that typographic character, and point in this element's coordinate system is within the glyph cell for the typographic character, then set result to charnum.
4. ~RET %結果 ◎ Return result.

`selectSubString(charnum, nchars)@m

要素の中の~textを成す［ ~index %charnum にある文字から %nchars 個の文字 ］を選択する。 ◎ The selectSubString method is used to select text within the element.＼

その~method~手続きは： ◎ When selectSubString(charnum, nchars) is called, the following steps are run: ◎ ↑Selects a substring of the text in this element, beginning at character index charnum and extending forwards nchars characters. The following steps must be followed when this method is called: • Let node be this text content element.

1. %個数 ~LET コレ内にある文字の個数 ◎ Let count be the number of characters in this text content element.
2. %終端 ~LET %charnum ~PLUS %nchars ◎ Let end = charnum + nchars.
3. ~IF［ %charnum ~GTE %個数 ］~OR［ %終端 ~GTE %個数 ］ ⇒ ~THROW `IndexSizeError$E ◎ If charnum ≥ count or end ≥ count, then throw an IndexSizeError.
4. %選択 ~LET 文書の`選択$ ◎ ↓
5. %選択 からすべての`範囲~obj$を除去する `DOM$r `EDITING$r ◎ Remove all ranges from the document's selection. [DOM][EDITING]
6. %選択 の`方向$ ~SET `前方^i ◎ Set the selection's direction to forwards.
7. %選択 に次のようにされた新たな`範囲~obj$を追加する ⇒＃ `始端$rG ~SET `境界~点$( コレ, %charnum ), `終端$rG ~SET `境界~点$( コレ, %終端 ) ◎ Add to the selection a new range whose start is the boundary point tuple (node, charnum) and end is the boundary point tuple (node, end).

注記： 引数の検査-法や例外の投出-法を無視すれば、 次を遂行することに等価になる： ◎ Ignoring the argument checking and exception throwing, this is equivalent to performing the following:

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

この~methodは非推奨にされた — `Selection API^cite の機能性と重複するので。 ◎ This method is deprecated, as it duplicates functionality from the Selection API.

11.13.2. ~interface `SVGTextPositioningElement^I0

`SVGTextPositioningElement$I ~interfaceは、 個々の~text~glyphを位置する属性を~supportする要素により実装され，［ `SVGTextElement$I, `SVGTSpanElement$I ］に継承される。 ◎ The SVGTextPositioningElement interface is implemented by elements that support attributes that position individual text glyphs. It is inherited by SVGTextElement and SVGTSpanElement.

[Exposed=Window]
interface `SVGTextPositioningElement^I0 : `SVGTextContentElement$I {
  [SameObject] readonly attribute `SVGAnimatedLengthList$I `x$m;
  [SameObject] readonly attribute `SVGAnimatedLengthList$I `y$m;
  [SameObject] readonly attribute `SVGAnimatedLengthList$I `dx$m;
  [SameObject] readonly attribute `SVGAnimatedLengthList$I `dy$m;
  [SameObject] readonly attribute `SVGAnimatedNumberList$I `rotate$m;
};

`x@m

`y@m

`dx@m

`dy@m

`rotate@m

順に，［ `x$a, `y$a, `dx$a, `dy$a, `rotate$a ］内容~属性を`反映する$。 ◎ The x, y, dx, dy and rotate IDL attributes reflect the ‘x’, ‘y’, ‘dx’, ‘dy’ and ‘rotate’ content attributes, respectively.

11.13.3. ~interface `SVGTextElement^I0

`SVGTextElement$I ~objは、 ~DOM内で `text$e 要素を表現する。 ◎ An SVGTextElement object represents a ‘text’ element in the DOM.

[Exposed=Window]
interface `SVGTextElement^I0 : `SVGTextPositioningElement$I {
};

11.13.4. ~interface `SVGTSpanElement^I0

`SVGTSpanElement$I ~objは、 ~DOM内で `tspan$e 要素を表現する。 ◎ An SVGTSpanElement object represents a ‘tspan’ element in the DOM.

[Exposed=Window]
interface `SVGTSpanElement^I0 : `SVGTextPositioningElement$I {
};

11.13.5. ~interface `SVGTextPathElement^I0

`SVGTextPathElement$I ~objは、 ~DOM内で `textPath$e 要素を表現する。 ◎ An SVGTextPathElement object represents a ‘textPath’ element in the DOM.

[Exposed=Window]
interface `SVGTextPathElement^I0 : `SVGTextContentElement$I {

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

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

  [SameObject] readonly attribute `SVGAnimatedLength$I `startOffset$m;
  [SameObject] readonly attribute `SVGAnimatedEnumeration$I `method$m;
  [SameObject] readonly attribute `SVGAnimatedEnumeration$I `spacing$m;
};

`SVGTextPathElement$I includes `SVGURIReference$I;

`SVGTextPathElement$I 上に定義される数量- METHODTYPE 定数は、 `method$a 属性がとり得る~keyword値を表現するために利用される。 それらの意味は次に従う： ◎ The numeric method type constants defined on SVGTextPathElement are used to represent the keyword values that the ‘method’ attribute can take. Their meanings are as follows:

`SVGTextPathElement$I 上に定義される数量- SPACINGTYPE 定数は、 `spacing$a 属性がとり得る~keyword値を表現するために利用される。 それらの意味は次に従う： ◎ The numeric spacing type constants defined on SVGTextPathElement are used to represent the keyword values that the ‘spacing’ attribute can take. Their meanings are as follows:

`startOffset@m

`startOffset$a 内容~属性を`反映する$。 ◎ The startOffset IDL attribute reflects the ‘startOffset’ content attribute.

`method@m

`method$a 内容~属性を`反映する$。 `method$a 用の`数量-型~値$は、 上で述べた数量- METHODTYPE 定数~表tに与えられる。 ◎ The method IDL attribute reflects the ‘method’ content attribute. The numeric type values for ‘method’ are as described above in the numeric method type constant table.

`spacing@m

`spacing$a 内容~属性を`反映する$。 `spacing$a 用の`数量-型~値$は、 上で述べた数量- SPACINGTYPE 定数~表tに与えられる。 ◎ The spacing IDL attribute reflects the ‘spacing’ content attribute. The numeric type values for ‘spacing’ are as described above in the numeric spacing type constant table.