11. テキスト — Text

11.1. 序論

~SVG文書片の一部として描画される~textは、 `text$e 要素を利用して指定される。 `text$e 要素の中の~textは、次のいずれかにより描画できる: ◎ Text that is to be rendered as part of an SVG document fragment is specified using the ‘text’ element. The text within a ‘text’ element can be rendered:

まず、 §~text~layout にて、~text~layoutの序論を与える。 後続する[ §内容~区画, `~text~layout~algo$sec ]各節は、`内容~区画$の中における~text~layoutを受持つ。 [ `整形済み~text$ / `自動折返d~text$ / `~path上の~text$ ]各節は、それぞれに対応する特化された~layout規則について取組む。 ◎ The section Text layout gives an introduction to text layout. It is followed by sections covering content areas and the algorithm for laying out text within a content area. The specialized layout rules corresponding to text that is pre-formatted, auto-wrapped, and on a path are then addressed in individual sections.

注記: ~SVG-11における~text~layout用の規則は、大部分が~SVG-11仕様の中で定義される。 これらの規則は、~CSS内に見出される広範囲のものを映し出す。 ~SVG-2においては、~CSSへの依存性は,より明示的になる。 実施においては、結果の~layoutは同じになる。 ~CSS仕様へ直に依拠するこの変更は、~SVG仕様を単純~化しつつ,~UAの描画器が~HTML, ~SVG 両者にて同じ~codeを利用して ~textを もっと明白に描画できるようにする。 特に,~SVG-2による自動折返d~textは、~CSS~text~layoutに基づく。 ◎ Rules for text layout in SVG 1.1 are mostly defined within the SVG 1.1 specification. The rules mirror to a large extent those found in CSS. In SVG 2, the dependence on CSS is more explicit. In practice the resulting layout is the same. The change to directly relying on CSS specifications simplifies the SVG specification while making it more obvious that rendering agents can use the same code to render both text in HTML and in SVG. In particular, SVG 2 auto-wrapped text is based on CSS text layout.

~SVGの `text$e 要素は、他の~graphics要素の様に描画される。 したがって,[ 座標系変換, 塗ng, 切抜き, ~mask法 ]特能は、[ ~path矩形 ]などの`図形~要素$に適用されるのと同じ仕方で `text$e 要素にも適用される。 ◎ SVG's ‘text’ elements are rendered like other graphics elements. Thus, coordinate system transformations, painting, clipping and masking features apply to ‘text’ elements in the same way as they apply to shapes such as paths and rectangles.

~SVG~textは、次を含む,高度な~typographic特能を~supportする: ◎ SVG text supports advanced typographic features including:

~SVG~textは、国際的な~text処理の必要を~supportする — 次に挙げるものなど: ◎ SVG text supports international text processing needs such as:

多言語~SVG内容は、 利用者が選好する言語に基づいて,異なる~text文字列で代用する ことにより,アリになる。 ◎ Multi-language SVG content is possible by substituting different text strings based on the user's preferred language.

描かれる文字は、 `text$e 要素の内側にある文字~data `xml$r として表出される — その結果: ◎ The characters to be drawn are expressed as character data ([xml], section 2.4) inside the ‘text’ element. As a result:

~accessibilityの理由から、文書に含まれた~textは,その機能を指示するような適切な意味論上の~markupを備えることが推奨される。 例えば,図式の一部~用に可視な~labelを供する~text要素は、関連な ~groupや~path要素~上の `aria-labelledby$a 属性から参照される `id$a を有するベキである。 さらなる情報は、 ~SVG~accessibility指針 を見よ。 ◎ For accessibility reasons, it is recommended that text that is included in a document have appropriate semantic markup to indicate its function. For example, a text element that provides a visible label for part of a diagram should have an ‘id’ that is referenced by an ‘aria-labelledby’ attribute on the relevant group or path element. See SVG accessibility guidelines for more information.

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 の定義から要求される。 ◎ 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などの 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や排他体に因り,狭められ得る。 【§ 内容~区画を見よ。】 ◎ 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$refer )。 ◎ 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を利用して,文字を何らかの視覚的な媒体に呈示するために必要とされる他の情報 ](~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.

~SVG-2要件: ~WOFF( `Web Open Font Format^cite )用の明示的な~supportを含む。 ◎ SVG 2 Requirement: Include explicit support for Web Open Font Format (WOFF).

  • 解決: ~SVG-2においては、~WOFFの~supportを義務付ける( `http://www.w3.org/2011/03/01-svg-minutes.html#item03$refer )。 ◎ Resolution: We will mandate WOFF support in SVG 2.
  • 目的: 国際-化, および高度な~typography用に,~OpenType特能への全部的な~accessを許容する。 ◎ Purpose: To allow access to full OpenType features for internationalization and advanced typography.
  • Owner: Chris (no action)
  • Status: Done

適正な~text描画は、著作~時に利用したものと同じ~fontを利用することに依存することもある。 この理由から、~SVGには §~font資源 `css-fonts-3$r にて定義される,~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.

`font_embox^dgm
~EM~box(水色~正方形)の内側にある 'M' 。 'M' は基底線(水色~線)上に座する。 座標系の原点は、小さい黒-真円で示される。 ◎ An 'M' inside an Em box (blue square). The 'M' sits on the baseline (blue line). The origin of the coordinate system is shown by the small black circle.

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

`font_baseline^dgm
3 種の用字系による基底線の例(赤-線) — 左から右の順に,`~alphabetic^i, `~hanging^i, `~ideographic^i 。 ~ideographic用字系~用の~EM~boxは、水色で示されている。 ◎ Example baselines (red lines) in three different scripts. From left to right: alphabetic, hanging, ideographic. The EM box is shown in blue for the ideographic script.

一連の~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.

`font_metrics^dgm
~font計量の例。 水色~boxは 3 個の~glyph用の幾何的な~boxを示す。 ~label付きの丸い点dは、~glyphを配置する前の`現在の~text位置$を示す。 四角い点d(青)は、最後の~glyphを配置した後の最終-`現在の~text位置$を示す。 ~kerningに因り、~glyph 'a' の~boxの左端と,~glyph 'V' の~boxの右端は整列されていないことに注意。 ◎ Example of font metrics. The blue boxes show the geometric boxes for the three glyphs. The labeled small circles show the current text position before glyph placement. The small square shows the final current text position after placing the last glyph. Note that the left side of the 'a' glyph's box is not aligned with the right side of the 'V' glyph's box due to kerning.

~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を給さないときには、 基底線の合成-法 `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.

`vertical_align^dgm
`vertical-align^p ~propの用例。 図左の '[z]' は、 `vertical-align^p: `mathematical^v が適用された `tspan$e に包含されている(この場合, `alignment-baseline^p が `mathematical^v になる) — 水色~線は、 `~mathematical^i 基底線の位置を示す。 図右の '2' は、 `vertical-align^p: `super^v が適用された `tspan$e に包含されている(この場合, `baseline-shift^p が `super^v になる) — 水色~線は、基底線のズラシを指示する。 ◎ Examples of using the 'vertical-align' property. Left: 'vertical-align:mathematical' ('alignment-baseline:mathematical') is applied to the ‘tspan’ containing '[z]'. The light-blue line shows the position of the mathematical baseline. Right: 'vertical-align:super' ('baseline-shift:super') applied to the ‘tspan’ containing '2'. The light-blue lines indicate the shift in baseline.

~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高さと基底線~整列 `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])

~SVG-2要件: 各種 基底線の下で整列される~textを~supportする。 ◎ SVG 2 Requirement: Support text aligned to different baselines.

  • 解決: ~SVG-2は、各種 基底線の下での~glyphの整列-法を~supportすることとする — たぶん、既存のまたは改善された~CSS~propを利用することにより( `http://www.w3.org/2012/03/15-svg-irc#T21-07-21$refer )。 【すなわち、 `dominant-baseline$pp 】 ◎ Resolution: SVG 2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties.
  • 目的: ~style上の効果~用に、横書き~textにおいて,一連の~glyphに対し各種 縦方向~整列を許容する。 ◎ Purpose: To allow glyphs in horizontal text to have different vertical alignments for stylistic effects.
  • Owner: Chris (no action)
  • Status: Done

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

`line_box^dgm
`行l~box$の縦幅を決定する例。 まず,各~glyph~box(小さい水色~box)が、 `line-height$p ~propに則って縦方向に上, 下へ拡幅される。 この事例では、大きい方の~glyphは, `line-height$p ~propは `125%^v, `font-size$p は `96px^v なので,計 `24px^v ( `96px^v の `25%^v )だけ拡幅されている。 この拡幅量は、上, 下に均等に分割され,その結果が図の赤-~boxになる — 各 赤-~boxは、`行l~box$を成す各 `行内~要素$ごとに~group化された~glyphたちを示している。 最終的な`行l~box$(全体を囲う水色~box)は、[ 基底線より上における各 赤-~boxの拡幅量の最大, 基底線より下における各 赤-~boxの拡幅量の最大 ]を利用して見出される。 ◎ Example of determining the height of a line box. First each glyph box (small light-blue boxes) is extended vertically above and below according to the line-height property. In this case the line-height property is 125%. The larger glyphs have a font-size of 96px so their extra height is 24px (25% of 96px). The extra height is evenly divided above and below resulting in the red boxes. (For clarity, all glyphs in the same inline element have been grouped together). The final line box (large light-blue box) is then found using the maximum extents of the red boxes above and below the baseline.

様々な国際的な書記体系を~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\
  • 空白を縮約する。 ◎ 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. `text^e, `tspan^e 要素

`text$e 要素は、~textからなる~graphics要素を定義する。 [ `text$e /別の `tspan$e 要素 ]の中の `tspan$e 要素は、次を許容する: ~styleを切替える / `tspan$e 要素の内側にある描画される~textの位置を 親~要素に相対的に調整する。 ◎ The ‘text’ element defines a graphics element consisting of text. The ‘tspan’ element within a ‘text’ or another ‘tspan’ element, allows one to switch the style and/or adjust the position of the rendered text inside the ‘tspan’ element relative to the parent element.

[ `text$e / `tspan$e ]要素の中の文字~dataは、[ 関連な各種 属性や~prop, ~fontの`文字~map$(~fontの中の,文字を~glyphへ対応付ける~table) ]とともに,描画される~glyphたちを定義する。 [ `text$e / `tspan$e ]要素の属性や~propは、[ 書字~方向, ~font指定, 塗ng属性 ]など,文字たちをどう正確に描画するか述べるものを指示する。 後続の各~節では、関連な,~textに特有な属性や~propを述べる。 ◎ The character data within the ‘text’ and ‘tspan’ elements, along with relevant attributes and properties, and character-to-glyph mapping tables within the font itself, define the glyphs to be rendered. The attributes and properties on the ‘text’ and ‘tspan’ elements indicate such things as the writing direction, font specification, and painting attributes which describe how exactly to render the characters. Subsequent sections of this chapter describe the relevant text-specific attributes and properties.

[ `text$e / `tspan$e ]要素は,他の~graphics要素と同じ描画~手法を利用して描画されるので、`図形~要素$に適用される 塗ng 特能のうち ~markerを除くすべては,[ `text$e / `tspan$e ]要素にも適用される。 加えて,[ 座標系変換, 切抜き, ~mask法 ]も、一体としての `text$e 要素に適用できる。 ◎ Since ‘text’ and ‘tspan’ elements are rendered using the same rendering methods as other graphics elements, all of the same painting features that apply to shapes such as paths and rectangles also apply to ‘text’ and ‘tspan’ elements, except for markers. In addition, coordinate system transformations, clipping, and masking can be applied to the ‘text’ element as a whole.

注記: `text$e 要素は、~CSS用語における`塊~要素$として動作する。 `~text内容~要素$の子孫である[ `tspan$e, `textPath$e, `a$e ]要素は,`行内~要素$として動作する。 ◎ In CSS terms, the ‘text’ element acts as a block element. The ‘tspan’, ‘textPath’, and ‘a’ elements that are descended from text content elements act as inline elements.

~textには[ ~gradient / ~pattern / 切抜き~path / ~mask / ~filter ]を適用することもアリである。 これらいずれかの特能が~textに適用されていて, かつ — ~graphicな効果を “~obj限界~box” に相対的に指定するために — ~keyword `objectBoundingBox^v が利用された場合、どの事例であれ,`~obj限界~box単位$secは, `text$e 要素~全体に相対的に算出される — 同じ `text$e 要素の中で異なる[ `tspan$e / `textPath$e ]要素に異なる効果が適用されていようが。 ◎ It is possible to apply a gradient, pattern, clipping path, mask or filter to text. When one of these facilities is applied to text and keyword 'objectBoundingBox' is used (see Object bounding box units) to specify a graphical effect relative to the "object bounding box", then the object bounding box units are computed relative to the entire ‘text’ element in all cases, even when different effects are applied to different ‘tspan’ or ‘textPath’ elements within the same ‘text’ element.

`text$e 要素は、(双方向性~並替ngの後に)最初の~glyphを初期-`現在の~text位置$に描画する( `text-anchor$p / `text-align$p ~prop値に因るアリな調整も伴う)。 [ 整形済み~text/ `内容~区画$が `inline-size$p ~propにより決定された自動折返d~text ]用の初期-`現在の~text位置$は、最初に描画される文字を包含する[ `text$e / `tspan$e ]要素の[ `x$a, `y$a ]値により決定される。 [ 図形~内の自動折返d~text/ ~path上の~text ]用の初期-`現在の~text位置$の決定-法は、[ `自動折返d~text$ / `~path上の~text$ ]を各~節見よ。 所与の文字(たち)に対応している ~glyph(たち)が描画された後、現在の~text位置は,次に来る文字~用に更新される。 最も単純な事例では,新たな現在の~text位置は、それまでの現在の~text位置に,~glyph(たち)の送幅(横方向/縦方向)を~~加算した結果になる。 [ ~glyph配置, ~glyph送幅 ]についての記述は、`~text~layout~algo$secを見よ。 ◎ The ‘text’ element renders its first glyph (after bidirectionality reordering) at the initial current text position (with possible adjustments due to the value of the text-anchor property or the text-align property). For pre-formatted text and for auto-wrapped text where the content area is determined by the inline-size property, the initial current text position is determined by the ‘x’ and ‘y’ values of the ‘text’ or ‘tspan’ element which contains the first rendered character. For auto-wrapped text in a shape or text on a path see the Auto-wrapped text or Text on a path sections, respectively, to determine the initial current text position. After the glyph(s) corresponding to the given character is (are) rendered, the current text position is updated for the next character. In the simplest case, the new current text position is the previous current text position plus the glyphs' advance value (horizontal or vertical). See text layout for a description of glyph placement and glyph advance.

~text文字列 `Hello, out there!^l は、 `Verdana^v ~font~family を利用して~canvas上に描画され, ~glyphたちは色 `blue^v で~fillされる。 ◎ The text string Hello, out there! is rendered onto the canvas using the Verdana font family with the glyphs filled with the color blue.

<?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"
>

  <text x="250" y="180"
        font-family="Verdana" font-size="64" fill="blue" >
    Hello, out there!
  </text>

</svg>
`text01^dgm

単語 `not^l の~style付けを変更するために `tspan$e が利用されている。 ◎ A ‘tspan’ is used to change the styling of the word not.

<?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"
>

  <g font-family="Verdana" font-size="64" >
    <text x="160" y="180" fill="blue" >
      You are
      <tspan font-weight="bold" fill="red" >not</tspan>
      a banana.
    </text>
  </g>

</svg>
`tspan01^dgm

2 つの `tspan$e 要素は、[ `x$a / `y$a ]属性を利用して,[ 横方向/縦方向 ]に位置し直す。 すべての~textは単独の `text$e 要素の中にあるので、`~text選択と~clipboard操作o$secを~supportする~UAにおいては,利用者は すべての~textを通して選択-可能かつ~system~clipboardへ複製-可能になる。 ◎ Two ‘tspan’ elements are repositioned horizontally and vertically using the ‘x’ and ‘y’ attributes. Because all the text is within a single ‘text’ element, a user will be able to select through all the text and copy it to the system clipboard in user agents that support text selection and clipboard operations.

<?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"
>

  <g font-family="Verdana" font-size="64" >
    <text x="100" y="180" fill="blue" >
      But you
      <tspan dx="2em" dy="-50" font-weight="bold" fill="red" >
        are
      </tspan>
      <tspan dy="100">
        a peach!
      </tspan>
    </text>
  </g>

</svg>
`tspan02^dgm
◎要素名 `text@e ◎分類 `~graphics要素$, `描画-可能な要素$, `~text内容~要素$ ◎内容 任意個数, 任意順序の,文字~dataまたは次に挙げる要素 ⇒# `~animation要素$, `記述的~要素$, `塗り~server要素$, `~text内容~子~要素$, `a$e, `clipPath$e, `marker$e, `mask$e, `script$e, `style$e ◎属性 `~ARIA属性$, `条件付き処理~属性$, `中核~属性$, `大域~event属性$, `文書~要素~event属性$, `呈示~属性$, `lengthAdjust$a, `x$a, `y$a, `dx$a, `dy$a, `rotate$a, `textLength$a ◎界面 `SVGTextElement$I ◎表終

~SVG-2要件: `tspan$e に対しても変形を許容する。 ◎ SVG 2 Requirement: Allow transforms on ‘tspan’.

  • 解決: ~SVG-2は、 `tspan^e に対しても変形を許容することとする( `http://www.w3.org/2011/12/01-svg-irc#T21-02-34$refer )。 ◎ Resolution: SVG 2 will allow transforms on ‘tspan’.
  • 目的: すでに変形を許容している `a$e などの他の要素に揃える。 ◎ Purpose: Align with other elements such as ‘a’ which already allow transforms.
  • Owner: Cameron (no action)
  • Status: Done

この裁定は覆された。 Issue #210 を見よ。 [ ~CSS/~HTML ]は、`行内~要素$に対し変形を許容しないことに加え,行内にされた `a$e 要素に対し変形を~supportする描画器は無い(~SVG, ~HTMLとも)。 ◎ This decision was reversed. See GitHub Issue 210. CSS/HTML does not allow transforms on inline elements and no renderer supports transforms on the ‘a’ element when inline (in both SVG and HTML).

◎要素名 `tspan@e ◎分類 `~graphics要素$, `描画-可能な要素$, `~text内容~要素$, `~text内容~子~要素$ ◎内容 任意個数, 任意順序の,文字~dataまたは次に挙げる要素 ⇒# `記述的~要素$, `塗り~server要素$, `a$e, `animate$e, `script$e, `set$e, `style$e, `tspan$e ◎属性 `~ARIA属性$, `条件付き処理~属性$, `中核~属性$, `大域~event属性$, `文書~要素~event属性$, `呈示~属性$, `x$a, `y$a, `dx$a, `dy$a, `rotate$a, `textLength$a, `lengthAdjust$a ◎界面 `SVGTSpanElement$I ◎表終

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制御~用に~~微細な位置決め調整が必要とされる状況では、~SVG内容~設計者は,文書に必要とされる~fontが どこの~viewerからも可用になり(例: 必要とされる~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.

例 `tspan04^xl は、 `tspan$e 要素に `rotate$a 属性を利用して,描画される~glyphを回転する。 この例は、 `tspan$e 要素~内の~text文字列を成す文字~数が `rotate$a 属性に指定された値の個数を超える場合を示す。 この事例では、 `tspan$e の `rotate$a 属性に指定された最後の値は,文字列~内の残りの文字にも適用されなければならない。 ◎ Example tspan04 uses the ‘rotate’ attribute on the ‘tspan’ element to rotate the glyphs to be rendered. This example shows a single text string in a ‘tspan’ element that contains more characters than the number of values specified in the ‘rotate’ attribute. In this case the last value specified in the ‘rotate’ attribute of the ‘tspan’ must be applied to the remaining characters in the string.


<?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>
`tspan04^dgm
例 `tspan04^xl ◎ Example tspan04
`text/tspan04.svg$viewAs

例 `tspan05^xl は、 `rotate$a 属性の伝播をデモる。 [ `text$e 要素, 1 個を除くすべての子 `tspan$e 要素 ]には `rotate$a 属性が指定され、描画されることになる各~glyphを回転する。 ◎ Example tspan05 specifies the ‘rotate’ attribute on the ‘text’ element and on all but one of the child ‘tspan’ elements to rotate the glyphs to be rendered. The example demonstrates the propagation of the ‘rotate’ attribute.

<?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>
`tspan05^dgm
例 `tspan05^xl ◎ Example tspan05
`text/tspan05.svg$viewAs

"parent" `text$e 要素の内側にある `red^v ~text `Not ^l の回転 — 以下,角度( “〜~deg” )は `deg^u 単位を表す: ◎ Rotation of red text inside the ‘text’ element:

  • `rotate$a 値 `5,15,25,35,45,55^v を成す最初の 4 個により、~text `Not ^l を成す各~文字は,順に[ 5, 15, 25, 35 ]~degだけ回転されることになる。 ◎ The ‘rotate’ value will rotate the characters in the text "Not " by 5, 15, 25 and 35 degrees respectively.
  • `rotate$a 値は、[ `Not ^l を成す最後の~space ], [ "child1", "child5" `tspan$e 要素の合間にある~space ], [ ~text `rotation^l の前にある~space ]にも適用される。 ◎ A ‘rotate’ value is applied to the space that follows the text "Not", to the space in between the text in the "child1" and "child5" ‘tspan’ elements, and to the space before the text "rotation".
  • 残りの `rotate$a 値[ `45^v, `55^v ]は、後続の各~文字が処理されるに伴い,最後の値 55 ~degに達するまで,現在の `rotate$a 値を変化させる。 しかしながら、 `Not ^l の次に来る子 `tspan$e 要素に指定された `rotate^a 値が,これらを上書きする。 ◎ The next current ‘rotate’ value specified is 45 followed by 55. The current ‘rotate’ value in the ‘text’ element is incremented as subsequent characters in the text of the child ‘tspan’ elements are processed. ◎ The next immediate ‘tspan’ element specifies rotate values for the text, hence the current ‘rotate’ value will change to the next value in the list (but is not used) as each character is processed until the last value of 55 degrees is reached.
  • 最後の `rotate$a 値 `55^v は、 "parent" `text$e の直下にある~text `rotation^l を成すすべての文字にも適用されることになる。 ◎ The last ‘rotate’ value of 55 degrees will be applied to all the characters in the text "rotation".

"child1" `tspan$e 要素の内側にある `orange^v ~textの回転: ◎ Rotation of the orange text inside the "child1" ‘tspan’element:

  • `rotate$a 値により、~text `all characters ^l を成す最初の 4 個の文字は,順に[ −10, −20, −30, −40 ]~degだけ回転されることになる。 ◎ The ‘rotate’ value will rotate the first 4 characters in the text "all characters " by -10, -20, -30 and -40 respectively.
  • 最後の `rotate$a 値 `-40^v は、現在の `rotate$a 値になり,[ `tspan$e 要素~内の後続の文字~すべて, および 子 `tspan$e 要素のうち`rotate$a 値を指定しないもの ]に適用される。 ◎ The last ‘rotate’ value of -40 becomes the current ‘rotate’ value and will be applied to all subsequent characters in the ‘tspan’ element and to any child ‘tspan’ elements that do not specify ‘rotate’ values.
  • "child4" `tspan$e 要素は、 `rotate$a 値を指定しないので,先祖( "child1" `tspan$e 要素)の現在の `rotate$a を利用する。 "child4" `tspan$e 要素の中に指定された~text `text^l を成す各~文字は、すべて −40 ~degだけ回転される。 ◎ The "child4" ‘tspan’ element does not specify any ‘rotate’ values and thus uses the current ‘rotate’ of its ancestor ("child1" ‘tspan’ element). All the characters in the text "text" specified within the "child4" ‘tspan’ element will be rotated by -40 degrees.
  • 最後の `rotate$a 値 `-40^v は、~text `have a^l を成すすべての文字に適用される。 ◎ The last ‘rotate’ value of -40 degrees will be applied to all the characters in the text "have a".
  • `rotate$a 値は、[ "child2", "child4" `tspan$e 要素の合間にある~space ], [ ~text `have a^l の前にある~space ]にも適用される。 ◎ A ‘rotate’ value is applied to the space in between the text in the "child2" and "child4" ‘tspan’ elements, and to the space before the text "have a".

"child2" `tspan$e 要素の内側にある `yellow^v ~textの回転: ◎ Rotation of the yellow text inside the "child2" ‘tspan’element:

  • `rotate$a 値により、~text `in ^l を成す各~文字は,順に[ 70, 60, 50 ]~degだけ回転されることになる。 ◎ The ‘rotate’ value will rotate the characters in the (yellow) text "in " by 70, 60, and 50 degrees respectively.
  • `rotate$a 値は、~text `in ^l を成す最後の~spaceにも適用される。 ◎ A ‘rotate’ value is applied to the space that follows the text "in".
  • 文字~数を超える `rotate$a 値が指定されているので、残りの `rotate$a 値は, `rotate$a 値が指定されていない "child3" `tspan$e 要素に適用されることになる。 ◎ There are more ‘rotate’ values specified than characters, thus the additional ‘rotate’ values will be applied to the "child3" ‘tspan’ element which does not specified any ‘rotate’ values.
  • "child3" `tspan$e 要素~内の~text `the^l を成す各~文字は、順に[ 40, 30, 20 ]~degだけ回転されることになる。 ◎ The characters in the text "the" specified within the "child3" ‘tspan’ element will be rotated 40, 30 and 20 degrees respectively.

"child5" `tspan$e 要素の内側にある `blue^v ~textの回転: ◎ Rotation of the blue text inside the "child5" ‘tspan’ element:

  • `rotate$a 値により、~text `specified^l を成す各~文字は,すべて −10 ~degだけ回転されることになる。 ◎ The ‘rotate’ value will rotate all the characters in text "specified" by -10 degrees.
  • `rotate$a 値は 1 個しか指定されてないので、この要素~内のすべての文字に適用される。 ◎ Only one ‘rotate’ value is specified and is thus applied to all characters in the ‘tspan’ element.

`text$e 要素の中に入子にされた `tspan$e 要素へ回転~値がどう伝播するかを,次の図式に示す: ◎ The following diagram illustrates how the rotation values propagate to ‘tspan’ elements nested withing a ‘text’ element:

`tspan05-diagram^dgm

11.3. ~text~layout — 序論

~SVG-2要件: SVG Tiny 1.2 からの~text~layout改善を含める。 ◎ SVG 2 Requirement: Include text layout improvements from SVG Tiny 1.2.

  • 解決: ~SVG-2は、 SVG Tiny 1.2 にて改善された[ 文字と~glyph, ~text~layout, ~text選択, ~text探索 ]についての記述を含めることとする( `http://www.w3.org/2012/02/02-svg-minutes.html#item10$refer )。 ◎ Resolution: SVG 2 will include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search.
  • 目的: より明瞭な~text~layoutの記述を含める — 機能上の変更は無い。 ◎ Purpose: To include clearer descriptions of text layout; no functional change.
  • Owner: Chris (`3236$ACTION)

~SVG-2要件: 図形~内の~textを~supportする。 ◎ SVG 2 Requirement: Support text in shapes.

  • 解決: ~SVG-2は、~CSSに互換な,~textの自動的な折返ngを要求することとする( `http://www.w3.org/2011/11/17-svg-irc#T22-04-11$refer )。 ◎ Resolution: SVG 2 will require automatic text wrapping compatible with CSS.
  • 目的: フローチャート内の~text, 等々。 ◎ Purpose: Text in flow charts, etc.
  • Owner: Tav (no action)

この節は、~SVG~text~layoutについての短い概観を与える。 後続する各~節は、~text~layoutにおける異なる側面を,より詳細に受持つ。 ◎ This section gives a short overview of SVG text layout. It is followed by sections that cover different aspects of text layout in more detail.

~SVGにおける~text~layoutは,複段階の処理-を経る — それは、 `text$e 要素~下位treeと その~prop値を入力にとり,描画する~glyph並び, および `~text内容~要素$の座標系におけるそれらの位置を生産する: ◎ Text layout in SVG is a multi-stage process that takes as input a ‘text’ element subtree and its property values and produces a sequence of glyphs to render and their positions in each text content element's coordinate system.

  1. `text$e 要素と その子孫を、まず,~CSSに則って[ `内容~区画$/`包装~区画$ ]の内側に~lay-outする — `text$e は`塊~要素$で その子孫である[ `tspan$e / `textPath$e / `a$e ]は`行内~要素$であるかのように。 この~layoutには、[ この章にて述べる[ 段落~levelの, および~fontに関係する ]~CSS~prop ]すべてを織り込む。 ◎ First, a ‘text’ element and its descendants are laid out inside a content area or wrapping area according to CSS, as if the ‘text’ were a block element and any ‘tspan’, ‘textPath’, and ‘a’ descendants were inline elements. This layout takes into account all paragraph level and font related CSS properties described in this chapter.
  2. `内容~区画$は、[ `inline-size$p ~propを設定するか,`図形~要素$を[ 定義する/参照する ] `shape-inside$p を設定する ]ことにより,明示的に宣言できる。 `内容~区画$が宣言されていない場合、既定の[ 横幅, 縦幅とも無限な矩形 ]になる。 ◎ The content area may be explicitly declared by setting the inline-size property, or by setting the shape-inside property that defines or references an SVG shape. If a content area is not declared, it defaults to a rectangle of infinite width and height.
  3. [ `x$a, `y$a, `dx$a, `dy$a ]属性に与えられた位置決めを,~CSS~layout処理-による結果の~glyph位置に適用する。 変形~用の規則が許容されるかは、`内容~区画$が明示的に宣言されたかどうかに依存する。 明示的に宣言されていない場合、その規則は`整形済み~text$の~layoutを定義する。 宣言されている場合、規則は`自動折返d~text$の~layoutを定義する。 ◎ Second, any positioning given by ‘x’, ‘y’, ‘dx’ and ‘dy’ attributes are applied to the resulting glyph positions from the CSS layout process. The rules for which transforms are allowed depend on if the content area was explicitly declared or not. If not explicitly declared, the rules define the layout of pre-formatted text. If declared, the rules define the layout of auto-wrapped text.
  4. 必要とされるなら、 `text-anchor$p ~propによる効果を適用する。 ◎ Third, the effect of the text-anchor property is applied if necessary.
  5. `textPath$e 要素があれば、~glyphに対しそれ用の~layoutを遂行して,`整形済み~text$を`~path上の~text$に変換する。 ◎ Finally, layout of glyphs for any ‘textPath’ elements is performed, converting pre-formatted text to text-on-a-path.

各種~text~layoutの例: ◎ Examples of the different types of text layout:

整形済み~text:
~textを成す文字列が短い場合(例:~label)や,各~glyphに正確な配置が要求される場合(例:~titleなどの~~手作業による~~字組み)。 ◎ For short strings of text (e.g. labels) or where exact placement of glyphs is required (e.g. hand-kerned titles).

複数行の整形済み~textの例: ◎ An example of multi-line pre-formatted text.

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

     <text x="20" y="45" style="font: 24px sans-serif;">
       Example of multi-line,
       <tspan x="20" y="75">pre-formatted text.</tspan>
     </text>

</svg>
`text-preformatted^dgm
整形済み~text。 `tspan$e 要素を利用して複数行の~textを作成している。 ◎ Pre-formatted text where a ‘tspan’ element has been used to create multi-line text.
自動折返d~text:
~textを成す文字列が長いため、~textの自動的な折返ngが要求される場合。 ◎ For long strings of text where automatic text wrapping is required.

自動折返d~textの例: ◎ An example of auto-wrapped text.

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

  <text x="20" y="45" style="font: 24px sans-serif; inline-size: 250px;">
    Example of text auto-wrapped.</text>

</svg>
`text-wrapped^dgm
自動折返d~text。 `inline-size$p ~propは、縦幅~無限な,矩形な内容~区画(図の水色~線)を定義する。 ◎ Auto-wrapped text. The inline-size property defines a rectangular content area of infinite height (shown in light blue).
~path上の~text:
指定された~pathを辿る~text用。 ◎ For text that follows a specified path.

~path上の~textの例: ◎ An example of text on a path.

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

  <path id="MyPath" stroke="lightblue" fill="none"
	d="M 50,50 C 100,0 200,100 250,50"/>

  <text style="font: 24px sans-serif;">
    <textPath href="#MyPath">Text on a path.</textPath>
  </text>

</svg>
`text-path^dgm
~path(図の水色~線)上の~text。 `textPath$e 要素は、 `path$e 要素を参照している。 ◎ Text on a path. The ‘textPath’ element references a ‘path’ element (shown in light blue).

注記: ~SVG-2は、`内容~区画$を指定することにより,[ 矩形~その他の図形の内側で,~textを自動的に折返す ]能を導入する。 ~SVG自動折返d~textの設計は、~SVG~text折返ngが,~CSSにおける~text折返ngにアリな限り互換になることが欲されることが動機にある — ~CSSにおける~text折返ngを~supportする描画器が,~SVGにおける~text折返ngを容易に実装できるために(~HTMLに互換でない~SVG描画器に~HTMLを実装することを要求することなく)。 ~SVGと~CSSにおける~text折返ngの間には、いくつか相違がある。 最も重要なのは、~SVGにおいては,`内容~区画$は明示的に供されなければならないことである — ~SVGには(~CSSの~box~modelが供するような)自動的かつ有限(または 片方の次元のみ有限)な`内容~区画$は無いので。 もう一つの相違は、~SVGには,行l~分断を作成するような要素 — `p^e や `br^e など — が無いことである。 代わりに,~SVGにおいては、行l~分断を供するために `white-space$p の `pre^v や `pre-line^v 値に依拠する。 ~SVG自動折返d~textは、自動折返d~textを~supportしない~SVG-11描画器~用に自然な~fallbackを供することも内容~作成~toolに許容する([ `text$e / `tspan$e ]要素における[ `x$a, `y$a ]属性の利用により — それらは、自動折返d~textに対しては ~SVG-2描画器からは無視される)。 ◎ SVG 2 introduces the ability to automatically wrap text inside a rectangle or other shape by specifying a content area. The design of SVG wrapped text is motivated by the desire that SVG text wrapping be as compatible as possible with text wrapping in CSS in order that renderers that support CSS text wrapping can implement SVG text wrapping easily (but without requiring non-HTML compatible SVG renderers to implement HTML). There are several differences between SVG and CSS text wrapping. The most important is that in SVG, a content area must be explicitly provided as SVG does not have an automatic finite (or semi-finite) content area (provided in CSS by the box model). Another difference is that SVG does not have the <p></p> and <br/> elements which create line breaks. Instead, SVG relies on the pre and pre-line values of white-space to provide line breaks. SVG wrapped text also allows a content-creation tool to provide a natural fallback for SVG 1.1 renderers that do not support wrapped text (by use of ‘x’ and ‘y’ attributes in the ‘text’ and ‘tspan’ elements, which are ignored by SVG 2 renderers for auto-wrapped text).

注記: ~SVGの各種~text~layout~optionは、ほとんどの一般的な利用事例を受持つよう設計されている。 より複階的な~layout(~bullet付き~list, ~table, 等々)が要求される場合、 `foreignObject$e 要素の中に~inlineに埋込まれた[ ~XHTML `HTML$r などの別の~XML名前空間 ]内に~textを描画できる。 ◎ SVG's text layout options are designed to cover most general use cases. If more complex layout is required (bulleted lists, tables, etc.), text can be rendered in another XML namespace such as XHTML [HTML] embedded inline within a ‘foreignObject’ element.

11.4. ~text~layout — 内容~区画

`内容~区画^dfn は、 `text$e 要素に[ `inline-size$p ~propを指定するか, `図形~要素$を[ 定義する/参照する ] `shape-inside$p ~propを指定する ]ことにより,定義される。 `内容~区画$が供されない場合の既定の`内容~区画$は、横幅, 縦幅とも無限な矩形になる(§`整形済み~text$を見よ)。 [ `inline-size$p, `shape-inside$p ]両~propとも `none^v 以外の値が与えられた場合、 `shape-inside$p ~propが利用される。 ◎ A content area is defined by specifying in a ‘text’ element an inline-size property, or a shape-inside property that defines or references an SVG shape. If no content area is provided, the content area defaults to a rectangle of infinite width and height (see the pre-formatted text section). If both an inline-size property and a shape-inside property with value other than 'none' are given, the shape-inside property is used.

自動折返d~textは、 `包装~区画^dfn 内に~lay-outされる。 `包装~区画$は、通常は`内容~区画$と同じになるが,[ `内容~区画$が `shape-inside$p ~propを利用して定義されている場合 ]には[ `shape-subtract$p / `shape-padding$p ]に因り 狭められ得る: `shape-subtract$p ~propは( `shape-margin$p ~propとともに)、 `包装~文脈^dfn を定義し、`包装~区画$は,[ `内容~区画$を `shape-padding$p による距離だけ内方へ~offsetしてから,`包装~文脈$を減算する ]ことにより見出される。 ◎ Wrapped text is laid out in a wrapping area. The wrapping area is normally the same as the content area. When the content area is defined using the shape-inside property, the wrapping area may be smaller due to the presence of a shape-subtract property and/or a shape-padding property. The shape-subtract property (along with the shape-margin property) defines a wrapping context. The wrapping area is found by insetting the content area by the shape-padding distance, and then subtracting the wrapping context.

`包装~区画$が定義されたなら、~textは,~CSSの規則に則って`包装~区画$の内側に~lay-outされる(この節に与える特別な規則も尊重しつつ)。 ◎ Once a wrapping area is defined, the text is laid out inside the wrapping area according to the rules of CSS (respecting any special rules given in this section).

注記: ~SVG/~HTML における等価な包装~区画の構築-法。 包装~区画の内側にある~textは、両~事例とも同じに描画される。 ◎ Constructing equivalent wrapping areas in SVG and HTML. The text inside the wrapping areas is rendered the same in both cases.

`text-layout-svg^dgm
~SVGにおける`包装~区画$の定義-法。 `text$e 要素には[ `shape-inside$p, `shape-subtract$p ]両~propが指定されている。 `shape-inside$p ~propは、`内容~区画$を定義する真円を参照する(薄紫の点線)。 2 個の半円を参照している `shape-subtract$p ~propは、`包装~文脈$を定義する(薄緑の点線) — それを`内容~区画$から減算した結果が`包装~区画$になる(水色~線)。 ◎ Defining a wrapping area in SVG. The ‘text’ element has both a shape-inside property and a shape-subtract property. The shape-inside property references a circle that defines a content area (dotted purple line). The shape-subtract property referencing two semicircles defines a wrapping context (dotted green line) which when subtracted from the content area results in the wrapping area (light blue line).
`text-layout-html^dgm
~HTMLにおける`包装~区画$の定義-法。 2 個の “浮動体” `div^e を包含している“wrapper” `div^e は、矩形な領域(薄紫のベタ線)を定義する。 その `shape-inside$p ~propは、 `div^e の中の`内容~区画$(薄紫の点線)を定義する。 他の 2 個の `div^e は 2 個の浮動体を左, 右に定義する(薄緑のベタ線, ピンクのベタ線)。 2 つの浮動体は、矩形な図形~内にある。 各~浮動体には、 `shape-outside$p ~propがあり, 各~浮動体(薄緑の点線とピンクの点線)用に`包装~文脈$を定義する。 組合された`包装~文脈$は、`内容~区画$から減算され,`包装~区画$が定義される(水色~線)。 ◎ Defining a wrapping area in HTML. A wrapper <div> contains two float <div>s. The wrapper <div> defines a rectangular region (solid purple line). Its shape-inside property defines a content area within the <div> (dotted purple line). The two other <div>s define two floats, one on the left (solid green line) and the right (solid pink line). The floats are rectangular in shape. Each float has a shape-outside property which defines the wrapping context for each float (dotted green and pink lines). The combined wrapping context is subtracted from the content area to defined the wrapping area (light blue line).

11.4.1. `inline-size^p ~prop

Sydney 2015 会合の解決により, `extent^v を追加した( `http://www.w3.org/2015/02/12-svg-minutes.html#action17$refer )。 `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$refer )。 ◎ '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.

◎名 `inline-size@p ◎値 `auto^v | `length-percentage$t ◎初 `auto^v ◎適 `text$e 要素 ◎継 されない ◎百 現在の`~SVG表示域$の[ 横幅(横書き~text用)/縦幅(縦書き~text用) ]を基準にする(`単位$secを見よ) ◎ Refer to the width (for horizontal text) or height (for vertical text) of the current SVG viewport (see Units) ◎算 絶対~長さ/百分率 ◎ an absolute length or percentage ◎ア 算出d値の型による ◎表終

`inline-size$p を利用して横書き~textを折返す例: ◎ An example of using inline-size for wrapping horizontal text.

<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>
`text-wrap-horizontal^dgm
折返される横書き~text。 水色~線は、`内容~区画$の上限を指示する。 内容~区画の縦幅は無限になることに注意。 赤-点dは初期-`現在の~text位置$を示す。 ◎ Horizontal text wrapping. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite height. The red dot shows the initial current text position.

`inline-size$p を利用して,左向き横書き~textを折返す例: ◎ An example of using inline-size for wrapping right to left horizontal text.

<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>
`text-wrap-horizontal-rl^dgm
折返される左向き横書き~text。 水色~線は、`内容~区画$の上限を指示する。 内容~区画の縦幅は無限になることに注意。 赤-点dは初期-`現在の~text位置$を示す。 ◎ Horizontal text wrapping for right to left text. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite height. The red dot shows the initial current text position.

この~SVG-11による図を正しく描画しない~browserもある。 ~Batik, ~Firefox は、~~正しいように見受けられる。 ~Chromeに対しては~bugが申請されている。 ◎ Some browser may not render this SVG 1.1 figure correctly. Batik and Firefox seems to get it right. Bug filed against Chrome.

`inline-size$p を利用して縦書き~textを折返す例: ◎ An example of using inline-size for wrapping vertical text.

<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;"
  >
    テキストは10~~文字の後に折り~~返されます。</text>

</svg>
`text-wrap-vertical^dgm
折返される縦書き~text。 水色~線は、`内容~区画$の上限を指示する。 内容~区画の`塊~size$(横幅)は無限になることに注意。 赤-点dは、初期-`現在の~text位置$を示す。 ◎ Vertical text wrapping. The light-blue lines indicate the limits of the content area. Note that the content area is of infinite width. The red dot shows the initial current text position.

この~SVG-11画像は、~Firefoxにおいては働かない【現在はそうでない】 。 ~Firefoxは `writing-mode^p を呈示~属性としては~supportしない。 ~Firefoxに対しては~bugが申請されている。 ◎ This SVG 1.1 image doesn't work in Firefox, even nightly. Firefox does not support the presentation attribute 'writing-mode'. Bug filed against Firefox.

`inline-size$p を利用して,横書き~textを折返して真中を~anchorする例: ◎ An example of using inline-size for wrapping horizontal text, anchored in the middle.

<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>
`text-wrap-anchored^dgm
折返される横書き~text。 水色~線は、`内容~区画$の上限を指示する。 ~textは真中が~anchorされる。 赤-点dは初期-`現在の~text位置$を示す。 ◎ Horizontal text wrapping. The light-blue lines indicate the limits of the content area. The text is anchored in the middle. The red dot shows the initial current text position.

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.

◎名 `shape-inside@p ◎値 `auto^v | [ `basic-shape$t | `url$t ]+ ◎初 `auto^v ◎適 `text$e 要素 ◎継 されない ◎百 `viewBox$a に相対的 ◎ Relative to the ‘viewBox’ ◎算 `basic-shape^t 用には算出された長さたち/ `url^t 用には絶対~URI / 他の場合は指定された~keyword ◎ computed lengths for <shape>, the absolute URI for <uri>, otherwise as specified ◎ア 基本~図形の補間 を見よ ◎ See Interpolation of Basic 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>
`text-wrap-circle^dgm
~CSS真円~図形の内側で折返される横書き~text。 水色~真円は、`内容~区画$の上限を指示する。 ◎ Horizontal text wrapping inside a CSS circle shape. The light-blue circle indicates the limit of the content area.
`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>
`text-wrap-rectangle^dgm
~SVG矩形~図形の内側で折返される横書き~text。 水色~線は、`内容~区画$の上限を指示する。 ◎ Horizontal text wrapping inside an SVG rectangle shape. The light-blue lines indicate the limits of the content area.

~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, Shapes ~moduleに分かれたとき除去された。 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’.

◎名 `shape-subtract@p ◎値 `none^v | [ `basic-shape$t | `url$t ]+ ◎初 `none^v ◎適 `text$e 要素 ◎継 されない ◎百 `viewBox$a に相対的 ◎ Relative to the ‘viewBox’ ◎算 `basic-shape^t 用には算出された長さたち/ `url^t 用には絶対~URI/ 他の場合は指定された~keyword ◎ computed lengths for any <basic-shape>, the absolute URI for <uri>, otherwise as specified ◎ア 基本~図形の補間 を見よ ◎ See Interpolation of Basic Shapes ◎表終
`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.

`shape-subtract$p の用例: ◎ An example of using shape-subtract.

<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>
`text-wrap-complex^dgm
重合している 2 個の矩形の内側で折返される横書き~text。 `shape-subtract$p を[ `shape-inside$p, `shape-padding$p, `shape-margin$p ]とともに利用している。 黒-矩形は、`内容~区画$を示す。 内縁の水色~線は、`包装~区画$を示す。 ◎ Horizontal text wrapping inside two overlapping rectangles using shape-subtract as well as shape-inside, shape-padding and shape-margin. The black rectangles show the content areas. The inner blue lines show the wrapping areas.

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.

◎名 `shape-margin@p ◎値 `length-percentage$t ◎初 `0^v ◎適 `text$e 要素 ◎継 されない ◎百 受容しない ◎算 絶対~長さ ◎ア 算出d値の型による ◎表終

注記: 注記されるものを除き、この~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.

`shape-padding$p の用例: ◎ An example of using shape-padding.

<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>
`text-shape-padding^dgm
`shape-padding$p を伴う真円の内側で折返される横書き~text。 外縁の黒-真円は`内容~区画$を示す。 内縁の水色~真円は`包装~区画$を示す。 ◎ Horizontal text wrapping inside a circle with a shape-padding. The outer black circle shows the content area. The inner blue circle shows the wrapping area.

この画像は~PNGである。 良い~SVGでこれを成す方法を見つける。 ◎ This image is a PNG. Figure out how to make a good SVG.\

~Chromeは `tspan$e 上の `textLength^a を~supportするが,~Firefoxは~supportしない。 ◎ Note: Chrome supports 'textLength' on 'tspan' but Firefox does not.

注記: 注記されるものを除き、この~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.5. ~textの~layout~algo

~text~layoutは、~CSSに基づく~text描画器に `text$e 要素の内容 — ~text~data, および[ ~style付け情報, ~fillされる 1 個以上の図形についての記述 ]も含む — を渡して始まる。 `text$e 要素は、`塊~要素$として扱われ,その子孫[ `tspan$e, `textPath$e, `a$e ]要素は`行内~要素$として扱われる。 ~CSS描画器は、`~typographic文字$の集合に[ 当の~textを絶対的に位置されていたかのように~lay-outした結果の位置 ]も伴わせて返す。 ◎ Text layout begins by passing to a CSS-based text renderer the content of the ‘text’ element which includes text data along with styling information and a description of one or more shapes to be filled. The ‘text’ element is treated as a block element and its descendant ‘tspan’, ‘textPath’ and ‘a’ elements are treated as inline elements. The CSS renderer returns a set of typographic characters with their positions resulting from laying out the text as if the text were absolutely positioned.

注記: `~typographic文字$は、複数個の `~glyph$を包含することもある。 ここでの`~typographic文字$の内側にある`~glyph$の相対的な位置決めは、`~typographic文字$により~encapsulateされ,利用者からは制御-不能と見做される。 ◎ A typographic character may contain more than one glyph. It is assumed here the relative positioning of the glyphs inside a typographic character is encapsulated by the typographic character and it is not user controllable.

`内容~区画$が定義されたなら、次の~algoを利用して,所与の `text$e 要素~用の`~typographic文字$とそれらの位置を決定する: ◎ Once a content area has been defined, the following algorithm is used to determine the typographic characters and their positions for a given ‘text’ element:

いくつかの~CSS~propは、効果が制限されるものもあるが,~SVG~text~layoutに効果がある: ◎ A number of CSS properties have no or limited effect on SVG text layout:

様々な~SVG属性, ~propは、`内容~区画$がどう定義されたかに依存して,`~typographic文字$を位置し直すこともある: ◎ Various SVG attributes and properties may reposition the typographic characters depending on how the content area is defined:

以下に与える~SVG~text~layout~algoは… 【以下、この節の内容は未訳。】

11.6. 整形済み~text

注記: この~optionは、~SVG-11による基本~text~layoutに対応する。 ◎ This option corresponds to basic SVG 1.1 text layout.

これは、`内容~区画$が明示的に定義されていないときの 既定の~text~layout手法であり, `~path上の~text$を~lay-outするときにも最初の段として(少しばかり規則を改変した上で)利用される。 この~layout手法においては、自動的な[ 行l分断-法/折返ng ]は行われない。 名目上、~textは[ 横幅, 縦幅とも無限な,矩形な`内容~区画$ ]の内側にある単独の行lとして描画される。 複数の行lからなる~textは、行l~分断を予め算出した上で,次に挙げるいずれかの手法を利用して得せる: ◎ This is the default text layout method and is used in the absence of an explicitly defined content area. It is also used as a first step in laying out text on a path (with slightly modified rules). In this layout method, no automatic line breaking or word wrapping is done. Nominally, the text is rendered as a single line inside a rectangular content area of infinite width and height. Multiple lines of text can be obtained by precomputing line breaks and using one of the following methods:

注記: 次に挙げる~propは、`整形済み~text$には適用されない ⇒# `text-align$p, `text-align-last$p, `line-break$p, `word-break$p, `hyphens$p, `word-wrap$p, `overflow-wrap$p ◎ The following properties do not apply to pre-formatted text: text-align, text-align-last, line-break, word-break, hyphens, word-wrap, and overflow-wrap.

11.6.1. `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. 自動折返d~text

`text$e 要素にて`内容~区画$が指定されている場合、~textは自動的に折返される。 `内容~区画$は、~textを折返ng用の最外縁の容器を定義する。 `包装~文脈$(排他~区画の集合)も与えられ得る。 実際の`包装~区画$は、`内容~区画$から`包装~文脈$を減算することにより定義される。 `包装~文脈$はまた、 `shape-padding$p ~propの値により抑制され得る。 排他体を成す実質的な区画は、 `shape-margin$p ~propの値により~~拡げられ得る。 ◎ Text is automatically wrapped when a content area is specified in the ‘text’ element. The content area defines the outermost container for wrapping text. A wrapping context (set of exclusion areas) may also be given. The actual wrapping area is defined by subtracting the wrapping context from the content area. The wrapping context may also be reduced by the value of the shape-padding property. The effective area of an exclusion may be enlarged by the value of the shape-margin property.

`内容~区画$が `inline-size$p ~propにより定義される事例では、最初に描画される`~typographic文字$に対応している[ `x$a, `y$a ]属性が,初期-`現在の~text位置$を定義する。 `内容~区画$が`図形~要素$の内側にある場合、初期-`現在の~text位置$は,図形の内側にある最初の行l~boxを~lay-outした後に最初に描画される`~typographic文字$の位置から決定される。 ◎ In the case where the content area is defined by the inline-size property, the ‘x’ and ‘y’ attributes corresponding to the first rendered typographic character define the initial current text position. When the content area is inside a shape, the initial current text position is determined from the position of the first rendered typographic character after laying out the first line box inside the shape.

自動折返d~textにおいては、[ `text$e / `tspan$e ]要素~上のすべての[ `x$a, `y$a ]値は — 初期-`現在の~text位置$を決定するために利用されるときを除き — 無視される。 ◎ Except when used to determine the initial current text position, all values ‘x’ and ‘y’ are ignored on ‘text’, and ‘tspan’ elements in auto-wrapped text.

注記: 折返される~text用には、~SVG-11描画器~用の自然な~fallbackを与える仕組みとして,[ `x$a, `y$a ]属性を供せる。 内容~生産器は、各 行lを[ `x$a, `y$a ]属性を伴う一連の `tspan$e 要素に分断することにより,~textを予め~lay-outするよう望むこともあろう。 そうすれば、例えば,~textの描画に~fallback~fontが利用される場合、~SVG-2描画器は[ `x^a, `y^a ]属性を無視して~fallback~fontの~font計量を利用して~textを~flowし直すことになる一方,~SVG-11描画器は[ `x^a, `y^a ]属性を利用して~textを描画することになり、描画が図形に合致しない場合でも,通例的に~textは読み易くなる。 この節に与える~text折返ng例の多くは、~text折返ngを実装していない~browserにおいて~textを描画するため,この仕組みに依拠している。 ◎ The attributes ‘x’ and ‘y’ can provide a natural fallback mechanism for SVG1.1 renderers for wrapped text. Content producers may wish to pre-layout text by breaking up lines into ‘tspan’ elements with ‘x’ and ‘y’ attributes. Then, for example, if a fallback font is used to render the text, an SVG2 renderer will ignore the ‘x’ and ‘y’ attributes and reflow the text using the font metrics of the fallback font. An SVG1.1 renderer will use the ‘x’ and ‘y’ attributes in rendering the text which will usually result in readable text even if the rendering doesn't match the shape. Many of the text wrapping examples in this section rely on this mechanism to render text in browsers that have not implemented text wrapping.

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

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

11.7.1.1. 最初の行lの位置決め

`包装~区画$が任意に形状付けられる下では、最初の`行l~box$は,塊~始端に接合するように収まらないこともある。 この事例では、最初の`行l~box$は,収まる所までズラされる。 ◎ Given an arbitrary shaped wrapping area, the first line box may not fit flush against the top (or side for vertical text). In this case, the first line box is shifted until it fits.

~CSSにおいては、図形を成す辺は、[ 一連の, 1 画素~平方を占める浮動体 ]として扱われる。 ◎ In CSS, the edge of a shape is treated as a series of 1 pixel × 1 pixel floats.

注記: 将来の~CSS仕様は、行l~格子を定義し得る — 異なる`包装~区画$にある~textどうしの整列を許容するように,~textの最初の行lの位置を制御するためにも利用できるような。 ◎ A future CSS specification may define a line grid that could be used to control the position of the first line of text to allow alignment of text between different wrapping areas.

`text-layout-firstline^dgm
アリな限り小さい~text塊からなる上端 `行l~box$(小さい方の水色~矩形)は、`行l~box$(水色~path)が`包装~区画$の内側に収まるまで下へ移動される。 `行l~box$は `line-height$p ~propの効果を含むことに注意 — ここでは 1.25 に設定されている。 赤-矩形は、各`行l~box$内で~glyphを緊密に包装する。 ◎ The top line box (small light-blue rectangle), consisting of the smallest possible block of text, is moved down until the line box fits inside the wrapping area (light-blue path). Note, the line box includes the effect of the line-height property, here set to 1.25. The red rectangles tightly wrap the glyphs in each line box.

これは、~SVG 1.2 草案と異なるように現れる — そこでは、包装~区画の上端は,行l~格子の原点として~serveし、最初の行lは,図形の内側に収まるまで行l縦幅だけ下へ移動されていた【?】。 ◎ This appears to be different from the SVG 1.2 draft in which the top of the wrapping area served as the origin of a line grid. The first line was moved down by the line height until it fit inside the shape.

11.7.1.2. 分断される行l

任意に形状付けられた`包装~区画$が与えられた下では、~textの単独の行lは複数個の部分に分断されるかもしれない。 この事例では、各~部分~用に 1 個の`行l~box$が作成される。 単独の行lの~text内の すべての`行l~box$の縦幅は、同じになるモノトスル(すべての部分の基底線が同じになることを確保するため)。 この縦幅は、~textの行l内のすべての~glyphを調べることにより計算される。 ◎ Given an arbitrary shaped wrapping area, a single line of text might be broken into more than one part. In this case, a line box for each part is created. The height of all line boxes in a single line of text must be the same (ensuring all parts have the same baseline). This height is calculated by looking at all glyphs in the line of text.

この既定の挙動は、 Sydney 2016 会合にて同意された。 ◎ This default behavior was agreed to at the CSS/SVG joint working group meeting in Sydney 2016.

注記: 将来~CSS仕様は、異なる部分に分断された図形の どの部分が~fillされるか制御することを,許容し得る(例:最も右にある部分のみ~fillする, 最も左にある部分のみ~fillする, 等々)。 ◎ A future CSS specification may allow one to control which parts of a shape broken into different parts is filled (e.g, fill only the right most parts, fill only the left most parts, etc.).

`text-layout-brokenline^dgm
上端~行lが 2 個の `行l~box$(水色~矩形)に分けられ、各`行l~box$内の~textは,~boxの内側で中央寄せされている( `text-align^p に対する `center^v に因り)。 ◎ The top line is split into two line boxes (light-blue rectangles), text in each line box is centered inside the box (due to 'text-align:center').

11.8. ~path上の~text

~SVGは、`図形~要素$に`等価な~path$に沿って~textを配置できる。 これは、 `textPath$e 要素の中に~textを含ませた上で,[ `href$a 属性にて`図形~要素$を指す`~URL参照$を与える / `path$a 属性にて~path~dataを直に指定する値を指定する ]ことにより指定される。 ◎ SVG can place text along a path defined either by a ‘path’ element or the path equivalent of a basic shape. This is specified by including text within a ‘textPath’ element that has either an ‘href’ attribute with an URL reference pointing to a ‘path’ element or basic shape, or by specifying a value for the ‘path’ attribute that specifies the path data directly.

注記: 基本~図形に沿って~textを配置する能は、~SVG-2にて新たに~~導入された。 ◎ The ability to place text along a basic shape is new in SVG 2.

基本~図形に沿って~textを配置することは Sydney 2015 会合にて解決された( `http://www.w3.org/2015/02/12-svg-minutes.html#item05$refer )。 ◎ Placing text along a basic shape was resolved at the Sydney (2015) meeting.

`path^a 属性を利用して直に~pathを指定するのは、~SVG-2にて追加された。 元々は `d^a 属性としていたが、 London (2016) Editor's 会合の裁定により `d^a を呈示~属性に昇進させたことに伴い, `path^a に改称された( `https://www.w3.org/2016/04/21-svg-minutes.html$refer )。 ◎ Directly using a 'd' attribute to specify the path was added to SVG 2. The 'd' attribute was renamed to 'path' by decision at the London (2016) editor's meeting at the same time 'd' was promoted to being a presentation attribute.

~path上の~textは、概念~上は,[ `整形済み~text$が成す単独の行lを,~pathを辿るように変形した ]様なものである。 指示されたものは除き、整形済み~textに適用されるすべての~propは、~path上の~textにも適用される。 ◎ Text on a path is conceptionally like a single line of pre-formatted text that is then transformed to follow the path. Except as indicated, all the properties that apply to pre-formatted text apply to text on a path.

11.8.1. `textPath^e 要素

◎要素名 `textPath@e ◎分類 `~graphics要素$, `描画-可能な要素$, `~text内容~要素$, `~text内容~子~要素$ ◎内容 任意個数, 任意順序の,文字~dataまたは次に挙げる要素 ⇒# `記述的~要素$ `塗り~server要素$ `a$e, `animate$e, `clipPath$e, `marker$e, `mask$e, `script$e, `set$e, `style$e, `tspan$e ◎属性 `~ARIA属性$, `条件付き処理~属性$, `中核~属性$, `大域~event属性$, `文書~要素~event属性$, `呈示~属性$, `非推奨にされた~XLink属性$, `lengthAdjust$a, `textLength$a, `path$a, `href$a, `startOffset$a, `method$a, `spacing$a, `side$a ◎界面 `SVGTextPathElement$I ◎表終

~SVG-2要件: ~text~pathの `method$a 用の値 `stretch^v に もっと精確な説明を与える。 ◎ SVG 2 Requirement: Have a more precise explanation of text path stretch methods.

  • 解決: `textPath^e 要素~上の `method$a に対する `stretch^v を明確化することとする( `http://www.w3.org/2011/11/17-svg-irc#T22-23-10$refer )。 ◎ Resolution: We will clarify method="stretch" on >'textPath' elements.
  • 目的: この特能の相互運用能を改善する。 ◎ Purpose: Improve interoperability of the feature.
  • Owner: Cameron (no action)

`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.
`text-path-startoffset^dgm

`startOffset$a 属性の各種 値の描画 — 上から順に,既定~値, `50%^v, `-50%^v 。 ◎ Rendering for different values of the ‘startOffset’ attribute. From top to bottom: default value, 50%, -50%.

下端の~pathは、~pathの左端~側に `path.^l のみを示すベキである。 ~Chrome, ~Safariとも、範囲 `0%^v 〜 `100%^v の外側にある~offsetを取扱わない。 ~Chrome~bug( `https://bugs.chromium.org/p/chromium/issues/detail?id=476554$refer ) ◎ The bottom path should show only "path." on the left side of the path. Chrome and Safari both do not handle offsets outside the range 0% to 100%. Chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=476554

単独の`閉な下位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.

`text-path-startoffset2^dgm
`startOffset$a 属性に各種 値を伴う下での, `circle$e を参照している~path上の~textの描画。 図左は `0^v/ 図右は `75%^v ( `-25%^v でも同じ)。 赤-点dは、(真円を`等価な~path$に変換した後の)~pathの始点を表す。 ◎ Rendering for text on a path referencing a ‘circle’ with different values of the ‘startOffset’ attribute. Left: 0. Right: 75% or -25%. The red circle marks the beginning of the path (after the canonical decomposition of the circle into a path).
`text-path-startoffset3^dgm
`text-anchor$p 属性に各種 値を伴う下での, `circle$e を参照している~path上の~textの描画。 図左は `start^v / 図中央は `middle^v / 図右は `end^v 。 赤-点dは、(真円を`等価な~path$に変換した後の)~pathの始点を表す。 青く四角い点dは 描画の始端~用の基準~点を表す(どれも, `startOffset$a 値 `75%^v によりズラされている)。 矢印(灰色)は、`~typographic文字$が配置されていく方向と それが停止する箇所を示す。 `direction$p ~propの値が `rtl^v の場合、矢印は逆方向になる。 ◎ Rendering for text on a path referencing a ‘circle’ with different values of the text-anchor attribute. Left: 'start'. Middle: 'middle'. Right: 'end'. The red circles marks the beginning of the path (after the canonical decomposition of the circle into a path). The blue square marks the reference point for the start of rendering (shifted from the path start by a ‘startOffset’ value of 75%). The gray arrow(s) shows the direction of typographic character placement and the point at which typographic character placement stops. The arrow(s) would be reversed if the direction property has a value of rtl.

~path上の~text用の~pathとしての基本~図形の利用は、 Sydney 2015 会合( — `http://www.w3.org/2015/02/12-svg-minutes.html#item05$refer )にて同意された(議事録は無いが)。 `startOffset^a 属性による,~pathを~~周回する効果を[ 1 個の閉な下位pathを伴う~path, その一周回 ]に制限することは、 London (2016) Editor's 会合( `https://www.w3.org/2016/04/22-svg-minutes.html#item02$refer )にて同意された。 ◎ 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.)
`text-path-method^dgm
各種 `method$a 値に対する~path上の~textの描画 — 図左は `align^v / 図右は `stretch^v 。 ◎ Rendering of text on a path for different ‘method’ values: Left: 'align'. Right: 'stretch'.
◎ 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.
`text-path-side^dgm
各種 `side$a 属性~値を伴う, `circle$e を参照している~path上の~textの描画: 図左は `left^v / 図右は `right^v 。 ◎ Rendering for text on a path referencing a ‘circle’ with different values of the ‘side’ attribute. Left: left. Right: right.
注記: `閉な下位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$refer )。 ◎ 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は拡縮しないことに注意。 ◎ 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.

例 `toap01@xl は、~path上の~textの単純な例を供する: ◎ Example toap01 provides a simple example of text on a 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>
`toap01^dgm
例 `toap01^xl ◎ Example toap01
`text/toap01.svg$viewAs

例 `toap02@xl は、 `textPath$e 要素の中に `tspan$e 要素を含ませて,特定0の~glyphの[ 各種 ~style付け属性 / 現在の~text位置 ]を描画-前に調整する方法を示す。 単語 `up^l ( 1 個目の方)は、色~redで~fillされる — 単語を基底線から持ち上げるため, `dy$a 属性を利用している。 ◎ Example toap02 shows how ‘tspan’ elements can be included within ‘textPath’ elements to adjust styling attributes and adjust the current text position before rendering a particular glyph. The first occurrence of the word "up" is filled with the color red. Attribute ‘dy’ is used to lift the word "up" from the baseline.

注記: [ `x$a, `y$a, `dx$a, `dy$a, `rotate$a ]属性は、[ `text$e / `tspan$e ]要素~上にのみ指定できる(が、~path上の~textにおける~glyphの描画にも効果を発揮し得る — `~path上の~text~layout規則$を見よ)。 ◎ The ‘x’, ‘y’, ‘dx’, ‘dy’, and ‘rotate’ attributes can only be specified on ‘text’ and ‘tspan’ elements (but may effect the rendering of glyphs in text on a path — see text on a path layout rules).

<?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>
`toap02^dgm
例 `toap02^xl ◎ Example toap02
`text/toap02.svg$viewAs

例 `toap03@xl は、~text文字列の始端~位置を~pathに沿う特定0の位置として指定するための, `textPath$e 要素~上の `startOffset$a 属性の利用をデモる。 ~pathの終端から はみ出る~glyphは、描画されないことに注意(`~path上の~text~layout規則$を見よ)。 ◎ Example toap03 demonstrates the use of the ‘startOffset’ attribute on the ‘textPath’ element to specify the start position of the text string as a particular position along the path. Notice that glyphs that fall off the end of the path are not rendered (see text on a path layout rules).

<?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>
`toap03^dgm
例 `toap03^xl ◎ Example toap03
`text/toap03.svg$viewAs

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.

`glyph-textpath^dgm
~pathに沿う既定の~glyph方位。 図左は 横書き~text / 図右は 縦書き~text。 ◎ Default glyph orientation along a path. Left, horizontal text. Right: vertical text.

基本的な直線~上の[ 横書き/縦書き ]~text用の`~text~layout~algo$sec規則を補足する,~path上の~text用の特定0の~layout規則を示すため、次の例 `toap04@xl を利用する。 ◎ Example toap04 will be used to illustrate the particular layout rules for text on a path that supplement the basic text layout rules for straight line horizontal or vertical text.

<?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>
`toap04^dgm
例 `toap04^xl ◎ Example toap04
`text/toap04.svg$viewAs

`text$e 要素~内の最初の~glyph上を~zoomした様子を,次の絵に示す: ◎ The following picture does an initial zoom in on the first glyph in the ‘text’ element.

`toap05^dgm

上の図の小さい点dは、~glyphが~pathに据えられる点を示す。 ~glyphを囲う~boxは、その横~軸が[ 曲線に~glyphが据えられた点における,曲線の接線 ]に平行になるように,~glyphが回転される様子を示す。 ~boxはまた、~glyphの `~charwidth@ (すなわち、横書き~text~layout利用して~glyphが描かれたときに,現在の~text位置が横方向に送する量)を示す。 【すなわち、横方向~送幅。】 ◎ The small dot above shows the point at which the glyph is attached to the path. The box around the glyph shows the glyph is rotated such that its horizontal axis is parallel to the tangent of the curve at the point at which the glyph is attached to the path. The box also shows the glyph's charwidth (i.e., the amount which the current text position advances horizontally when the glyph is drawn using horizontal text layout).

更に~zoomした次の絵に,詳細な~layout規則をデモる: ◎ The next picture zooms in further to demonstrate the detailed layout rules.

`toap06^dgm

~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.9. ~textの描画~順序

`text$e 要素は、 1 個以上の~chunk内に描画される。 各~chunkは、(`~text~layout~algo$secにより生産されるに伴い)文書~順序で 1 個ずつ描画され,[ 1 個以上の~glyphからなる単独の~path ]を成していたかのように~fillされ, ~strokeされる。 ◎ A ‘text’ element is rendered in one or more chunks. Each chunk (as produced by the text layout algorithm) is rendered, one after the other, in document order. Each rendered chunk, which consists of one or more glyphs, is filled and stroked as if it were a single path.

このことは、~chunk内のすべての~glyphは、[ ひとまとめに~fillされてから,ひとまとめに~strokeされる ]ベキであることを意味する — あるいは、 `paint-order$p ~propの値によっては,その逆順に。 ◎ This means that all glyphs in the chunk should be filled, then all glyphs stroked at once, or the reverse according to the value of the paint-order property.

塗ngの目的においては、 `text$e を成す各~chunkには`等価な~path$がある。 各~等価な~pathは、何個かの下位pathからなる — ~chunkの中の各~glyphごとに 1 個ずつ。 ◎ For the purposes of painting, a ‘text’ has zero, one, or more equivalent paths, one for each chunk. Each equivalent path consists of one subpath per glyph within that chunk.

注記: ~SVG~text要素には `fill-rule$p ~propは適用されないので、`等価な~path$における下位pathの順序は、~~問題にならない。 【この注記は不要に見える。どの~pathであろうが, `fill-rule^p が定義する “~pathの内側” が下位pathの順序に左右されることはないはずなので。】 ◎ Since the fill-rule property does not apply to SVG text elements, the specific order of the subpaths within the equivalent path does not matter.

各~glyphに対応する下位pathの[ 始端の位置, ~pathが進捗する方向 ]は、定義されない。 しかしながら,~UAは、同じ~fontの同じ~glyphに対しては,それらを一貫させるベキである。 ◎ The specific position of the start of each subpath, and the direction that the path progresses around glyph shape, is not defined. However, user agents should be consistent for a given font and glyph.

注記: したがって、~text上の~dash付き~stroke用の~dash~patternが配置される位置は、実装により異なり得る。 ◎ This means that dashed strokes on text may not place the dash pattern at the same positions across different implementations.

11.10. 各種~propと疑似要素

~CSSは、~textを~styleするための数多の~propを提供する。 一般に,~SVGにて適用-可能な~propは、次の 2 種に限られる: どの~glyphを描画するか決定するもの( `font-family$p, `font-style$p, 等々), `段落^em ~levelで適用するもの( `direction$p, `writing-mode$p, `line-height$p, `letter-spacing$p, 等々)。 ◎ CSS offers a multitude of properties for styling text. In general, only two sets of properties are applicable to SVG: those that determine which glyphs are to be rendered (font-family, font-style, etc.) and those that apply at the paragraph level (direction, writing-mode, line-height, letter-spacing, etc.).

~SVG~text要素~上で~supportするモノトスル ~CSS~propの~listは、 ~style付け 章にて見出せる。 ◎ The list of CSS properties that must be supported on SVG text elements can be found in the Styling chapter.

加えて、次に挙げるものも~supportするモノトスル:

  • ~font選択~用に `font-face^at 規則
  • `text$e 要素~上の[ `first-line$pe, `first-letter$pe ]疑似要素
  • 対話的~modeの下では、 `selection$pe 疑似要素
◎ Additionally, the @font-face rule must be supported for font selection as well as the ::first-line and ::first-letter pseudo-elements must be supported on ‘text’ elements. In interactive modes, the ::selection pseudo-element must also be supported.

~UAは、~textの[ ~layout/描画 ]に影響する他の~CSS~propも~supportしてヨイ。 それらの効果は、[ ~SVG~text~layout処理-全体の中の,~CSS~text~layout段 ]を成す一部として織り込むベキである。 ◎ Other CSS properties that affect text layout and rendering may also be supported by an SVG user agent; their effect should be taken into account as part of the CSS text layout step of the overall SVG text layout process.

注記: 例えば~SVG-2では, `text-combine-upright$p ~prop用の~supportは要求されないが、~SVG文脈におけるその挙動は明白になるベキである。 ◎ For example, while SVG 2 does not require support for the text-combine-upright property, its behavior in an SVG context should be obvious.

次に挙げる~CSS~propは、~SVG~text要素に対しては効果を発揮しないモノトスル: ◎ A number of CSS properties must not have any effect on SVG text elements:

加えて,生成d内容~疑似要素[ `before$pe, `after$pe ]は、~SVG~text要素には適用しないモノトスル。 ◎ Additionally, the ::before and ::after generated content pseudo-elements must not apply to SVG text elements.

注記: 将来の仕様は、これらの疑似要素~用の~supportを導入し得る — 作者は、それらが無視されることに依拠するベキでない。 ◎ A future specification may introduce support for the ::before and ::after generated content pseudo-elements; authors should not rely on them being ignored.

11.10.1. ~SVG~prop

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

11.10.1.1. ~text整列: `text-anchor^p ~prop

`text-anchor$p ~propは、[ `整形済み~text$ / `自動折返d~text$のうち, `inline-size$p ~propにより`包装~区画$が定義されるもの ]を成す文字列の[ 始端, 真中, 終端 ]のうち,どこを所与の点に整列するかを制御する — 後者の`包装~区画$は、所与の点に相対的に, `inline-size$p ~propにより決定される。 他の`自動折返d~text$には適用-可能でない(代わりは `text-align$p を見よ)。 複数行の~textに対しては、整列は行lごとに行われる。 ◎ The text-anchor property is used to align (start-, middle- or end-alignment) a string of pre-formatted text or auto-wrapped text where the wrapping area is determined from the inline-size property relative to a given point. It is not applicable to other types of auto-wrapped text, see instead text-align. For multi-line text, the alignment takes place for each line.

`text-anchor$p ~propは、所与の `text$e 要素の中の個々の`~text~chunk$に適用される。 各~text~chunkには、初期-`現在の~text位置$がある — それは、文脈に依存して次のいずれかで与えられる,利用元~座標系~内の点を表現する: ◎ The text-anchor property is applied to each individual text chunk within a given ‘text’ element. Each text chunk has an initial current text position, which represents the point in the user coordinate system resulting from (depending on context)\

  • `text$e 要素~上の[ `x$a, `y$a ]属性の適用。 ◎ application of the ‘x’ and ‘y’ attributes on the ‘text’ element,\
  • [ ~text~chunkを成す文字のうち,最初に描画される文字 ]に,ある `tspan$e 要素~上の[ `x$a / `y$a ]属性~値が明示的にアテガわれているならば、その適用。 ◎ any ‘x’ or ‘y’ attribute values on a ‘tspan’ element assigned explicitly to the first rendered character in a text chunk, or\
  • `textPath$e 要素~用には、初期-現在の~text位置の決定。 【`~path上の~text~layout規則$】 ◎ determination of the initial current text position for a ‘textPath’ element.\

各~text~chunkには、最終-`現在の~text位置$もある — それは、`~text~chunk$内の最後の~glyphを配置した直後の`現在の~text位置$になる。 これらの位置は、 `text-anchor$p ~propを適用する前に決定される。 ◎ Each text chunk also has a final current text position which is the current text position after placing the last glyph in the text chunk. The positions are determined before applying the text-anchor property.

◎名 `text-anchor@p ◎値 `start^v | `middle^v | `end^v ◎初 `start^v ◎適 `~text内容~要素$ ◎継 される ◎百 受容しない ◎算 指定された~keyword ◎ア 離散的 ◎表終

各種 値の意味は: ◎ Values have the following meanings:

`start^v
描画される文字は、描画した結果の~textの始端が 初期-`現在の~text位置$に来るように整列される。 要素の `direction$p ~prop値に応じて[ `ltr^v (代表的には、ほとんどの欧州-言語)ならば ~textの左端~側 / `rtl^v (代表的には、~Arabicや~Hebrew)ならば ~textの右端~側 / 縦書きにおける首な~text方向(代表的には、~Asian~text用のことが多い)ならば ~textの上端~側 ]が初期~text位置に描画される。 ◎ The rendered characters are aligned such that the start of the resulting rendered text is at the initial current text position. For an element with a direction property value of "ltr" (typical for most European languages), the left side of the text is rendered at the initial text position. For an element with a direction property value of "rtl" (typical for Arabic and Hebrew), the right side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the top side of the text is rendered at the initial text position.
`middle^v
描画される文字は、描画された結果の~textの幾何的な真中( `text-anchor$p ~propを適用する前の 初期-, 最終-`現在の~text位置$から 決定される )が初期-`現在の~text位置$に来るようにズラされる。 ◎ The rendered characters are shifted such that the geometric middle of the resulting rendered text (determined from the initial and final current text position before applying the text-anchor property) is at the initial current text position.
`end^v
描画される文字は、描画した結果の~textの終端( `text-anchor$p ~propを適用する前の, 最終-`現在の~text位置$から決定される)が 初期-`現在の~text位置$に来るようにズラされる。 要素の `direction$p ~prop値に応じて[ `ltr^v (代表的には、ほとんどの欧州-言語)ならば ~textの右端~側 / `rtl^v (代表的には、~Arabic, ~Hebrew)ならば ~textの左端~側 / 縦書きにおける首な~text方向(代表的には、~Asian~text用のことが多い)ならば ~textの下端~側 ]が初期~text位置に描画される。 ◎ The rendered characters are shifted such that the end of the resulting rendered text (final current text position before applying the text-anchor property) is at the initial current text position. For an element with a direction property value of "ltr" (typical for most European languages), the right side of the text is rendered at the initial text position. For an element with a direction property value of "rtl" (typical for Arabic and Hebrew), the left side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the bottom of the text is rendered at the initial text position.

複数行の~textにおける `text-anchor$p 利用しての例: ◎ An example of using text-anchor on multi-line text.

<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>
`text-anchor-middle^dgm
保全された~LF文字は、 2 個の `~text~chunk$を作成し,互いに独立に~anchorされる。 ◎ The preserved line-feed creates two text chunks, each anchored independently.

複数行の~textにおける `text-anchor$p を利用する別の例: ◎ Another example of using text-anchor on multi-line text.

<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>
`text-anchor-chunks^dgm
~textは 3 個の`~text~chunk$に分割され([ `x$a, `y$a ]属性~内の 3 個の座標に因り)。 各`~text~chunk$は、独立に~anchorされる。 ◎ The text is divided into three text chunks (due to the three coordinates in the ‘x’ and ‘y’ attributes). Each text chunk is independently anchored.

11.10.1.2. `glyph-orientation-horizontal^p ~prop

注記: この~propは、~SVG-2から除去された。 ◎ This property has been removed in SVG 2.

11.10.1.3. `glyph-orientation-vertical^p ~prop

この~SVG-11用の~propは、縦書き~textに限り適用される。 これは、~SVG-2においては廃用にされ, `text-orientation$p ~prop `css-writing-modes-3$r により部分的に置換された。 ~UAは、依然として, `glyph-orientation-vertical^p ~propを `text-orientation$p 用の`旧来の略式~prop$として~supportするモノトスル — 次の表に従って,値を対応付けることにより: ◎ This property applies only to vertical text. It has been obsoleted in SVG 2 and partially replaced by the text-orientation property of CSS Writing Modes Level 3. The following SVG 1.1 values must still be supported by aliasing the property as a shorthand to text-orientation as follows:

`glyph-orientation-vertical^p `text-orientation$p
`auto^v `mixed^v
`0deg^v / `0^v `upright^v
`90deg^v / `90^v `sideways^v
他の値 妥当でないと扱うモノトスル。
◎ 'auto' to 'mixed'; ◎ '0deg', and '0', to 'upright'. ◎ '90deg', and '90', to 'sideways'. ◎ Any other values must be treated as invalid.

11.10.1.4. `kerning^p ~prop

注記: `kerning^p ~propは、~SVG-2から除去された。 ◎ The ‘kerning’ property has been removed in SVG 2.

`kerning^p ~propは、~SVG-11においては,[ ~glyph間のアキを調整するために,~font~kerning~tableを利用するベキかどうか ]を決定するために利用されていた。 それはまた, `length^t 値も許容し、与えられた場合は,~glyph間のアキに追加される( `letter-spacing$p ~propによるアキに対し補足的に)。 ~SVG-2においては、この~propは `font-kerning$p ~propに置換された — それは、~font~kerning~tableを利用するかどうかのみを制御する。 ◎ SVG 1.1 uses the 'kerning' property to determine if the font kerning tables should be used to adjust inter-glyph spacing. It also allows a <length> value which if given is added to the spacing between glyphs (supplemental to any from the letter-spacing property). This property is replaced in SVG 2 by the CSS font-kerning property which solely controls turning on/off the use of the font kerning tables.

~Chromeの `UseCounter^en ~dataによる 2014 年における利用では、 0.01% が示された。 Issue #80 を見よ。 ◎ Chrome's UseCounter data showed a use of 0.01% in 2014. See GitHub issue 80.

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-2要件: `css-fonts-3$r を参照する。 ◎ SVG 2 Requirement: Reference CSS3 Fonts.

  • 解決: ~SVG-2は、 `css-fonts-3^r に依存することとする( `http://www.w3.org/2011/07/29-svg-minutes.html#item08$refer )。 ◎ Resolution: SVG 2 will depend on CSS3 Fonts.
  • 目的: ~Web~font機能性のために,`CSS2$r, `css-fonts-3^r に揃える/ ~fontの高度な~typographic特能への~accessを供する。 ◎ Purpose: Alignment with CSS 2.1 and CSS3 for Web font functionality, and to provide access to advanced typographic features of fonts.
  • Owner: Chris (`3123$ACTION)

11.10.2.1. `font-variant^p ~prop

~INFORMATIVE

`font-variant$p ~propは `css-font-3$r にて定義される。 ◎ The font-variant property gets defined by the CSS Font Module ([css-font-3]).

`css-font-3$r は、 `font-variant$p ~propの意味を~CSS 2.1により定義されたものから変更する。 それは、単独の~fontの中の~font異体を選択するための略式に転用された(および,その機能性は大きく拡げられた)。 ◎ CSS Font Module changes the meaning of the font-variant property from that defined by CSS 2.1. It has been repurposed (and its functionality greatly expanded) as a shorthand for selecting font variants from within a single font.

~SVG-2は、 `font-variant$p 用のすべての下位prop(例: `font-variant-ligatures$p )を~supportする。 ◎ SVG 2 supports all font-variant longhand properties (e.g. font-variant-ligatures).

11.10.2.2. `line-height^p ~prop

~SVGは、 `line-height$p ~propを利用して,複数行の~textにおける 行l間のアキ ( `leading space^en )を決定する(横書き, 縦書き両者とも)。 それは、~path上の~textには適用-可能でない。 ◎ SVG uses the line-height property to determine the amount of leading space which is added between lines in multi-line text (both for horizontal and vertical text). It is not applicable to text on a path.

注記: ここに供する追加的な情報を除き、 `CSS2$r が `line-height$pp ~propを規範的に定義する。 ◎ Except for the additional information provided here, the normative definition of the line-height property is in the CSS 2.1 specification ([CSS2]).

`css-inline-3$r は、 `line-height^p の定義を更新し得る。 ◎ The CSS Inline Module Level 3 may update the definition of 'line-height'.

11.10.2.3. `writing-mode^p ~prop

~INFORMATIVE

`writing-mode^p ~propは、 `css-writing-modes-3$r により定義される。 ◎ The writing-mode property gets defined by the CSS Writing Modes Module ([css-writing-modes-3]).

この~propは、`塊-~flow方向$ — 言い換えれば,~textの行lたちが堆積される方向 — を設定する。 その帰結として、~textの方位が横方向, 縦方向どっちになるかも決定する。 ◎ This property sets the block-flow direction; or in-other-words, the direction in which lines of text are stacked. As a consequence it also determines if the text has a horizontal or vertical orientation.

~SVG-2は、 `css-writing-modes-3$r による `writing-mode$pp ~propの定義を参照する。 その仕様は、この~prop用の新たな値を導入する。 ~SVG-11による値は廃用にされたが,依然として~supportするモノトスル — 指定d値を算出d値に次に従って変換することにより: 【…以下,その変換の記述が原文には無いが、その仕様にある。】 ◎ SVG 2 references CSS Writing Modes Level 3 for the definition of the 'writing-mode' property. That specification introduces new values for the property. The SVG 1.1 values are obsolete but must still be supported by converting the specified values to computed values as follows:

SVG 1.0 においては、この~propは `行内-基底~方向$も設定するものと解釈することもでき、 `direction$p ~propに相対的な その役割について混同に導いている。 ~SVG-11は `direction$p の役割について もう少し特定的であったが(例: `direction$p は `text-anchor$p ~prop用の基準~点を設定する)、依然として解釈の~~余地があった。 SVG 1.0 も~SVG-11も,複数行の~textを許容しない事実が混同に~~拍車をかけている。 ◎ In SVG 1.0, this property could be interpreted as to also setting the inline-base direction leading to confusion about its role relative to the direction property. SVG 1.1 was a bit more specific about the role of direction (e.g. that direction set the reference point for the text-anchor property) but still was open to interpretation. The fact that neither SVG 1.0 nor SVG 1.1 allowed multi-line text added to the confusion.

11.10.2.4. `direction^p ~prop

この~propは、[ `text$e / `tspan$e ]要素の`行内-基底~方向$を指定する。 それは,~textの各~行lの[ 始端, 終端 ]点になる~~側を定義し、[ `text-anchor$p, `inline-size$p ]~propにて利用される。 また、 `unicode-bidi$p ~propの値が[ `embed^v / `bidi-override^v ]の場合に文字が位置される方向にも影響する。 ◎ The property specifies the inline-base direction of a ‘text’ or ‘tspan’ element. It defines the start and end points of a line of text as used by the text-anchor and inline-size properties. It also may affect the direction in which characters are positioned if the unicode-bidi property's value is either embed or bidi-override.

`direction$p ~propは、`行内-基底~方向$に垂直に方位される~glyphに限り適用される — それは[ ~Latin/~Arabic ]~textが横書きに方位される通例の事例に加え、それらの~textが縦書きの中で`側転に$される(ひとまとめに 90 ~deg回転される)事例も含む。 ◎ The direction property applies only to glyphs oriented perpendicular to the inline-base direction, which includes the usual case of horizontally-oriented Latin or Arabic text and the case of narrow-cell Latin or Arabic characters rotated 90 degrees clockwise relative to a top-to-bottom inline-base direction.

これが `css-writing-modes-3$r に~~整合するのを確保することについて、査読者は,特別に~careされたし。 ◎ Reviewers, please take special care to ensure this agrees with CSS3 Writing modes.

注記: ここに供する追加的な情報を除き、 `css-writing-modes-3$r が `direction$pp ~propを規範的に定義する。 ◎ Except for the additional information provided here, the normative definition of the direction property is in CSS Writing Modes Level 3 ([css-writing-modes-3]).

多くの事例では,~Unicode `UNICODE$r による双方向-~algoが 欲される結果を自動的に生産するので、そのような事例では,作者はこれらの~propを利用する必要はない。 左向き言語を利用するときなど,他の事例では、`最外縁の~svg要素$に `direction$p ~propを追加して, 方向を すべての~text要素に継承させることで足るであろう — 次の例にあるように(~templateとしても利用できる): ◎ In many cases, the bidirectional algorithm from Unicode [UNICODE] produces the desired result automatically, and in such cases the author does not need to use these properties. For other cases, such as when using right-to-left languages, it may be sufficient to add the direction property to the outermost svg element, and allow that direction to inherit to all text elements, as in the following example (which may be used as a template):

<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>
`rtl-text^dgm
例 ◎ Example
`text/rtl-text.svg$viewAs

暗黙的な双向性~並替ngでは足らない別の例: ◎ Below is another example, where where implicit bidi reordering is not sufficient:

<?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>
`rtl-complex^dgm
例 ◎ Example
`text/rtl-complex.svg$viewAs

11.10.2.5. `dominant-baseline^p ~prop

注記: この~propは `css-inline-3$r にて定義される — `dominant-baseline$pp を見よ。 ◎ This property is defined in the CSS Line Layout Module 3 specification. See 'dominant-baseline'. [css-inline-3]

~SVG-2は、この~propの定義に いくつか変更点を導入する。 特に: ◎ SVG 2 introduces some changes to the definition of this property. In particular:

  • `reset-size^v 値は、もはや~supportしない。 `font-size$p に対するどの変化も、支配的な基底線~tableを設定し直す。 ◎ The 'reset-size' value is no longer supported. Any change in font-size resets the dominant baseline table.
  • [ `use-script^v / `no-change^v ]値は、もはや~supportしない。 ◎ The 'use-script' and 'no-change' values are no longer supported.
  • この~propは、今や継承される(実質的には、挙動は変化しない)。 ◎ The property is now inherited. (Behavior is effectively unchanged.)

注記: ~SVGは、 `dominant-baseline$p ~propの値を利用して、~glyphを[ `x$a, `y$a ]属性【による座標】に相対的に整列する。 `text-orientation$p が値 `sideways^v にされている下では、 `dominant-baseline$p に対する値 `auto^v は `alphabetic^v になる。 しかしながら,後方-互換性を得るため、~glyphは,値 `central^v を利用して[ `x^a, `y^a ]属性に整列されるベキである。 ◎ SVG uses the value of the dominant-baseline property to align glyphs relative to the ‘x’ and ‘y’ attributes. For the text-orientation value sideways, the auto value for dominant-baseline is alphabetic; however, for backwards compatibility, the glyphs should be aligned to the ‘x’ and ‘y’ attributes using the value central.

~WGは、古い挙動を選好するような実際の利用に関心がある。 ◎ We are interested in any actual use where one would prefer the old behavior.

11.10.2.6. `alignment-baseline^p ~prop

注記: この~propは、 `css-inline-3$rにて定義される。 `alignment-baseline$pp を見よ。 ◎ This property is defined in the CSS Line Layout Module 3 specification. See 'alignment-baseline'. [css-inline-3]

注記: 新たな内容には、 `vertical-align$p 略式~propが選好されるベキである。 ◎ The vertical-align property shorthand should be preferred in new content.

~SVG-2は、この~propの定義にいくつか変更点を導入する。 特に,値[ `auto^v / `before-edge^v / `after-edge^v ]は除去された。 また、作者は[ `text-before-edge^v / `text-after-edge^v ]を利用するベキでない — 後方-互換性を得るため、~UAは,それらを[ `text-top^v / `text-bottom^v ]に対応付けるベキである。 ◎ SVG 2 introduces some changes to the definition of this property. In particular: the values 'auto', 'before-edge', and 'after-edge' have been removed. For backwards compatibility, 'text-before-edge' should be mapped to 'text-top' and 'text-after-edge' should be mapped to 'text-bottom'. Neither 'text-before-edge' nor 'text-after-edge' should be used with the vertical-align property.

11.10.2.7. `baseline-shift^p ~prop

注記: この~propは、 `css-inline-3$r にて定義される — `baseline-shift$pp を見よ。 ◎ This property is defined in the CSS Line Layout Module 3 specification. See 'baseline-shift'. [css-inline-3]

注記: 新たな内容には、 `vertical-align$p 略式~propが選好されるベキである。 ◎ The vertical-align property shorthand should be preferred in new content.

`vertical-align^p が[ `alignment-baseline^p, `baseline-shift^p ]用の略式に変換されるに伴い, `baseline^v 値は除去された — それは `alignment-baseline^p 用の値であり、長さ値 `0^v ともかぶるので。 ◎ The 'baseline' value was removed with the conversion of 'vertical-align' to a shorthand for 'alignment-baseline' and 'baseline-shift' as it is also a value for 'alignment-baseline' and it is redundant with a length value of '0'.

~SVG-2要件: 基底線~整列の機能性に関して~CSSに揃える。 ◎ SVG 2 Requirement: Align with CSS for baseline alignment functionality.

  • 解決: ~SVG-2は、 `baseline-shift^p を非推奨にして,代わりに `vertical-align^p 利用することとする( `http://www.w3.org/2012/01/13-svg-irc#T03-24-06$refer )。 ◎ Resolution: SVG 2 will deprecate ‘baseline-shift’ and use ‘vertical-align’ instead.
  • 目的: ~CSSに揃える。 ◎ Purpose: To align with CSS.
  • Owner: Cameron (`3281$ACTION)

`baseline-shift$pp は、[ 下付文字/上付文字 ]を整列するために重要なので(~Inkscapeは、その目的で,この~propに依拠する)、 `css-inline-3$r に残り続ける。 `vertical-align$p は、 `baseline-shift^p も含め,複数の~propを一括して設定する略式~propである。 ◎ 'baseline-shift' is important for aligning subscripts and superscripts (Inkscape relies on it for this purpose). It remains in the CSS Inline Layout Module Level 3. 'vertical-align' is a shorthand for changing multiple properties at once, including 'baseline-shift'.

11.10.2.8. `letter-spacing^p ~prop

注記: 注記されるものを除き、この~propの定義は `css-text-3$r の `letter-spacing$p を見よ。 ◎ Except as noted, see CSS Text Level 3 for the definition of the letter-spacing.([css-text-3]).

~SVG-11は、 `letter-spacing$p ~propに百分率~値を許容していた。 `~SVG表示域$に基づく百分率~値は、有用には見えないので,~SVG-2から除去された。 これは、 `letter-spacing^p の定義を~CSSに揃える。 ◎ SVG 1.1 allowed percentage values in the letter-spacing property. Percentage values based on the SVG viewport are not seen as useful, so this was removed in SVG 2. This brings the definition of 'letter-spacing' in line with CSS.

11.10.2.9. `word-spacing^p ~prop

注記: 注記されるものを除き、この~propの定義は `css-text-3$r の `word-spacing$p を見よ。 ◎ Except as noted, see CSS Text Level 3 for the definition of the word-spacing.([css-text-3]).

~SVG-2は、 `word-spacing$p ~prop用の百分率~値の意味を変更する。 ~SVG-11においては、百分率による追加的なアキを`~SVG表示域$~sizeの百分率として定義していたが,有用には見えない。 ~SVG-2においては、百分率による追加的なアキを, `css-text-3$r に従って,影響される文字の横幅に対する百分率として定義する。 これは、 `word-spacing^p の定義を~CSSに揃える。 【しかしながら、現在の~CSSは,百分率~値を受容していない。】 ◎ SVG 2 changes the meaning of percentage values for the word-spacing property. In SVG 1.1, percentages define additional spacing as a percentage of the SVG viewport size. Percentage values based on the SVG viewport are not seen as useful. In SVG 2, following CSS Text Level 3, percentages define additional spacing as a percentage of the affected character's width. This brings the definition of 'word-spacing' in line with CSS.

11.10.2.10. `text-overflow^p ~prop

~SVG-2要件: `text-overflow$pp の機能性を追加する。 ◎ SVG 2 Requirement: Add text-overflow functionality.

  • 解決: ~SVG-2に `text-overflow^p を追加することとする( `http://www.w3.org/2011/03/03-svg-minutes.html#item04$refer )。 ◎ Resolution: We will add text-overflow in SVG 2.
  • 目的: ~CSSに揃うよう、~textの一部は示さなくするよう指示することを許容する。 ◎ Purpose: To align with CSS, allow indicating that not all text is shown.
  • Owner: Erik (`3003$ACTION)

注記: ~SVG-2にて新たに~~導入された。 ~UAが[ 定義済み包装~区画を~overflowする~text文字列 ]を,もっと有用な仕方で取扱えるようにするため、追加された。 ~SVGを[ ~HTML/~CSS ]による~text処理に揃える。 ◎ New in SVG 2. Added to allow user agents to handle text strings that overflow a predefined wrapping area in a more useful way. Aligns SVG and HTML/CSS text processing.

注記: この~propの定義は `css-overflow-3$r の `text-overflow$pp を見よ。 ◎ See the CSS3 Overflow specification for the definition of 'text-overflow'. [css-overflow-3]

~SVGでは、~textが`行l~box$を~overflowするとき — 例えば, `white-space$p ~propの値が `nowrap^v にされたため — `text-overflow$p ~propを利用して,`~text内容~塊~要素$をどう描画するかを制御する。 この~propは、[ `整形済み~text$/`~path上の~text$ ]には適用されない。 ◎ SVG uses the text-overflow property to control how text content block elements render when text overflows line boxes as, for example, can happen when the white-space property has the value nowrap. The property does not apply to pre-formatted text or text-on-a-path.

~SVGにおいては、妥当に指定された`包装~区画$がある場合 — `~text内容~塊~要素$上の `overflow$p ~propの算出d値に関わらず — `text-overflow$p の効果がある。 ◎ In SVG text-overflow has an effect if there is a validly specified wrapping area, regardless of the computed value of the overflow property on the text content block element.

`text-overflow$p ~propの値が `ellipsis^v にされた下で,描画される~textが`包装~区画$を~overflowする場合、省略符が所与の区画の中に収まるように描画される。 描画の目的においては、この省略符は,それが挿入される箇所にある文字を置換したかのように扱われる。 ◎ If the text-overflow property has the value ellipsis then if the text that is to be rendered overflows the wrapping area an ellipsis is rendered such that it fits within the given area. For the purposes of rendering, the ellipsis is treated as if it replaced the characters at the point where it is inserted.

`text-overflow$p ~propの値が `clip^v の場合、`包装~区画$を~overflowする~textは切取られる。 文字は部分的に描画され得る。 ◎ If the text-overflow property has the value clip then any text that overflows the wrapping area is clipped. Characters may be partially rendered.

`text-overflow$p 用の他の値は、指定されていなかったかのよう扱われる。 ◎ Any other value for text-overflow is treated as if it wasn't specified.

`text-overflow$p の効果は、純粋に視覚的であることに注意 — 省略符~自身が~DOMの一部を成すことは無い。 すべての~DOM~methodに対し,[ `text-overflow$p が適用されていない, かつ`包装~区画$は~textを拘束していない ]かのようになる。 ◎ Note that the effect of text-overflow is purely visual, the ellipsis itself does not become part of the DOM. For all the DOM methods it is as if text-overflow was not applied, and as if the wrapping area did not constrain the text.

次の例は、 `text-overflow$p の利用を示す。 1 行l目は、通常に描画されるときの~textを示す(~textは `white-space$p 値 `pre^v に因り~overflowし, `overflow$p 値 `visible^v に因り表示される)。 [ 2 行l目, 3 行l目 ]は、 `text-overflow$p 値が,順に[ `clip^v, `ellipsis^v ]にされたときの~textを示す。 ◎ The following example shows the use of text-overflow. The top line shows text as it would normally be rendered (text overflows due to white-space value pre and is displayed due to overflow value visible). The middle line shows text with text-overflow value clip, and the bottom line shows text with text-overflow value ellipsis.

<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>
`text-overflow-ref^dgm
~text要素で利用される `text-overflow$p ~prop。 3 行l目は、省略符が適用された~textを示している。 ◎ The text-overflow property used on text elements, the bottom line showing text with an ellipsis applied.

この~propは、有用でないとの~~論もある。 隠された~textを公開する仕組みと組にされた方が,もっと利用があろう(省略符~上を~hoverすると~~現れる~tool-tipなど?)。 `text-overflow^p ~propは、行lの終端を~overflowする~textしか~~対処せず,包装~区画の終端を~overflowする~textには~~対処しない。 ◎ It has been argued that this property is useless. It would be of more use if coupled with a mechanism that would expose the hidden text (tool-tip on hovering over ellipses?). The text-overflow property only deals with text that overflows off the end of a line. It does not deal with text that overflows the off the end of the wrapping area.

11.10.3. 空白

注記: ~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.

11.10.3.1. ~SVG-2にて選好される空白の取扱い: `white-space^p ~prop

~SVG-2においては、空白の描画は、 `white-space$p ~propにより制御される。 これは、次の 2 つを指定する: ◎ Rendering of white space in SVG 2 is controlled by the white-space property. This specifies two things:

  • 要素の内側にある空白を縮約するかどうか,どう縮約するか ◎ whether and how white space inside the element is collapsed
  • 自動折返機会の所で行lを折返してもよいかどうか ◎ whether lines may wrap at unforced soft wrap opportunities

注記: 各種 値, それらの意味は、 § 空白と折返ng `css-text-3$r にて定義される ◎ Values and their meanings are defined in CSS Text Module Level 3.[css-text-3]

`white-space$p 値に `pre-line^v を利用する例: ◎ An example of using the white-space value pre-line.

<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>
`text-whitespace-vertical^dgm
行l~分断を伴う複数行の縦書き~textの例。 ~textは日本の “いろは歌” から。 各 行lは、伝統的な箇所にて分断される。 ◎ Example of multi-line vertical text with line breaks. The text is from the Japanese poem Iroha. The lines are broken at traditional places.

11.10.3.2. 旧来の空白の取扱い: `~xml_space^a 属性

互換性を得るため、~SVG-2は,~XML属性 `~xml_space$a も~supportする — それは、所与の `text$e 要素の文字~dataの中の空白~文字の取扱いを指定する。 新たな内容は `~xml_space$a を利用するベキでない — 代わりに, `white-space$p ~propを利用すること。 ◎ For compatibility, SVG 2 also supports the XML attribute ‘xml:space’ to specify the handling of white space characters within a given ‘text’ element's character data. New content should not use ‘xml:space’ but instead, use the white-space property.

`~xml_space^a の論点を制限するため、この節は,代わりに それを~UA~stylesheet内で `white-space$p ~propを利用して定義するように単純~化するベキである。 CSS Text 4 仕様の `white-space-collapse$p ~prop用の `preserve-spaces^v 値が, `~xml_space^a 用の値 `preserve^v に合致するものと意図される( `https://log.csswg.org/irc.w3.org/css/2015-02-08/#e519951$refer )。 【!略:( `fantasai^en 氏は、 `white-space$p 用に,~SVG-11の~~不規則な `~xml_space="preserve"^c の挙動に合致する適切な値を追加することに同意した。)】 ◎ This section should be simplified to limit the discussion of xml:space and instead define it in the user agent style sheet using the white-space property. The CSS Text 4 specification's preserve-spaces value for the 'white-space-collapse' property is intended to match xml:space=preserve. ( fantasai agreed to add an appropriate value for white-space to match SVG 1.1's odd xml:space="preserve" behavior.)

【 明確化するため、この節の見本~codeでは,~textを成す各~space文字を `2423^U OPEN BOX (␣) で表すことにする。 】

`text$e 要素の子~要素も, `~xml_space$a 属性を有せることに注意 — それは、子の~text内容に適用されることになる。 ~UAに対しては、この属性に結付けられる特別な処理~規則がある(下に述べる)。 これらの挙動は、~XML構文解析 `XML$r, ~DOM構築の後に生じる。 ◎ Note that any child element of a ‘text’ element may also have an ‘xml:space’ attribute which will apply to that child element's text content. The SVG user agent has special processing rules associated with this attribute as described below. These are behaviors that occur subsequent to XML parsing [XML] and any construction of a DOM.

`~xml_space$a は、次の 2 つの値をとり得る継承-可能な属性である: ◎ ‘xml:space’ is an inheritable attribute which can have one of two values:

`default^v
(初期~値/既定の値)。 ~UAは、元の文字~data内容の複製に対し,次を順に施してから描くことになる ⇒# すべての改行文字を除去する; すべての~tab文字を~space文字に変換する; 頭部, 尾部の~space文字~並びをすべて剥取る; すべての連続的な~space文字~並びを 1 個に縮約する。 ◎ (The initial/default value for ‘xml:space’.) When xml:space="default", the SVG user agent will do the following using a copy of the original character data content. First, it will remove all newline characters. Then it will convert all tab characters into space characters. Then, it will strip off all leading and trailing space characters. Then, all contiguous space characters will be consolidated.
`preserve^v
~UAは、元の文字~data内容の複製に対し,すべての[ 改行文字, ~tab文字 ]を~space文字に変換してから、すべての~space文字を個別に描くことになる — 頭部, 尾部にあるものも, 連続的なものも。 ◎ When xml:space="preserve", the SVG user agent will do the following using a copy of the original character data content. It will convert all newline and tab characters into space characters. Then, it will draw all space characters, including leading, trailing and multiple contiguous space characters.\
したがって,この値の下では、文字列 `a␣␣␣b^l ( "a", "b" の合間に 3 個の~space)は, "a" と "b" の合間が `a␣b^l (合間に 1 個の~space)より広く~~空くよう描かれることになる。 ◎ Thus, when drawn with xml:space="preserve", the string "a b" (three spaces between "a" and "b") will produce a larger separation between "a" and "b" than "a b" (one space between "a" and "b").

`~xml_space^a に値 `default^v を利用した場合に,行lの字下げ~~量が重要になり得る例を示す。 この例の素片は、 2 個の類似な `text$e 要素からなる。 両~要素とも `~xml_space^a に `default^v を利用している。 これらには、どの行lの終端にも余分な空白は無い(すなわち,改行文字は最後の可視~文字の直後に生じる)。 【原文の見本には `xml:space^a が `preserve^v にされた `text^e も記されているが、以下の記述にまったく現れないので省略する。】 ◎ The following example illustrates that line indentation can be important when using xml:space="default". The fragment below show two pairs of similar ‘text’ elements, with both ‘text’ elements using xml:space="default". For these examples, there is no extra white space at the end of any of the lines (i.e., the line break occurs immediately after the last visible character).

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

行l [01] 〜 [04] を占める `text$e 要素は、文字~dataを字下げした効果を示す。 `text^e 要素の `~xml_space^a 属性~値 `default^v は、~UAに次を指図する: ◎ The first pair of ‘text’ elements above show the effect of indented character data. The attribute xml:space="default" in the first ‘text’ element instructs the user agent to:

  1. すべての~tabを~space文字に変換する ◎ convert all tabs (if any) to space characters,
  2. すべての改行文字を剥取る(すなわち,行l [01], [02], [03] の終端にある改行文字を剥取る) ◎ strip out all line breaks (i.e., strip out the line breaks at the end of lines [01], [02] and [03]),
  3. 頭部の~space文字をすべて剥取る(すなわち,行l [02] 上の `WS␣example^l の前にある~space文字を剥取る) ◎ strip out all leading space characters (i.e., strip out space characters before "WS example" on line [02]),
  4. 尾部の~space文字をすべて剥取る(すなわち,行l [04] 上の `</text>^l の前にある~space文字を剥取る) ◎ strip out all trailing space characters (i.e., strip out space characters before "</text>" on line [04]),
  5. 途中にある各~space文字~並びを 1 個の~space文字に縮約する(すなわち,行l [03] 上の `indented␣lines^l の前にある~space文字~並びを縮約する)。 ◎ consolidate all intermediate space characters (i.e., the space characters before "indented lines" on line [03]) into a single space character.

行l [07] 〜 [10] を占める `text$e 要素は、文字~dataを字下げしない場合の効果を示す。 `text^e 要素の `~xml_space^a 属性~値 `default^v は、~UAに次を指図する: ◎ The second pair of ‘text’ elements above show the effect of non-indented character data. The attribute xml:space="default" in the third ‘text’ element instructs the user agent to:

  1. ~tabはすべて~space文字に変換する ◎ convert all tabs (if any) to space characters,
  2. 改行文字をすべて剥取る(すなわち,行l [07], [08], [09] の終端にある改行文字を剥取る) ◎ strip out all line breaks (i.e., strip out the line breaks at the end of lines [07], [08] and [09]),
  3. 頭部の~space文字をすべて剥取る(この例には無い) ◎ strip out all leading space characters (there are no leading space characters in this example),
  4. 尾部の~space文字をすべて剥取る(すなわち,行l [10] 上の `</text>^l の前にある~space文字を剥取る) ◎ strip out all trailing space characters (i.e., strip out space characters before "</text>" on line [10]),
  5. 途中にある各~space文字~並びを 1 個に縮約する(この例には無い)。 ◎ consolidate all intermediate space characters into a single space character (in this example, there are no intermediate space characters).

~XML構文解析器では、文字~dataを~appに渡す前に,各 改行文字を指示する標準な表現(例:[ `000D^U ~CR, `000A^U ~LF ]並び / 1 個の `000D^U / 1 個の `000A^U )を 1 個の文字 `000A^U に変換することが要求されることに注意。 したがって,~SVG内の各~改行文字は、 1 個の文字 `000A^U で表現されることになる — 元の資源に利用された改行文字~用の表現が何であれ( ~XMLによる行末の取扱い を見よ。) ◎ Note that XML parsers are required to convert the standard representations for a newline indicator (e.g., the literal two-character sequence "U+000D U+000A", CARRIAGE-RETURN LINE-FEED or the stand-alone literals U+000D or U+000A) into the single character U+000A before passing character data to the application. Thus, each newline in SVG will be represented by the single character U+000A, no matter what representation for newlines might have been used in the original resource. (See XML end-of-line handling.)

[ ~SVG言語/~SVG~DOM ]の特能のうち,各~文字に付番される~indexに基づくもの — [ `text$e / `tspan$e ]要素~上の[ `x$a, `y$a, `dx$a, `dy$a, `rotate$a ]属性など — は、ここに述べた空白の取扱い規則を適用した後の文字~indexに基づく。 特に, `~xml_space^a が `default^v にされている場合、空白~文字は【構文解析-】処理の一部として除去されることが多い。 文字~indexは、この節の規則により空白~文字を除去した後の~text文字列の中で付番される。 ◎ Any features in the SVG language or the SVG DOM that are based on character position number, such as the ‘x’, ‘y’, ‘dx’, ‘dy’ and ‘rotate’ attributes on the ‘text’ and ‘tspan’ elements, are based on character position after applying the white space handling rules described here. In particular, if xml:space="default", it is often the case that white space characters are removed as part of processing. Character position numbers index into the text string after the white space characters have been removed per the rules in this section.

空白~文字に対応している~glyphは、 `blank space^en 【(単に)空間を占めるもの, または(より限定的に)~space文字】 として可視になるよう表示されるベキであることに注意。 — ~glyph自体は `non-blank^en 【 `missing glyph^en として描かれるもの?】であったとしても。 `UNICODE$r の ~supportされない文字の表示 を見よ。 ◎ Note that a glyph corresponding to a white-space character should only be displayed as a visible but blank space, even if the glyph itself happens to be non-blank. See display of unsupported characters [UNICODE].

`~xml_space$a 属性は~animate不可とする。 ◎ The ‘xml:space’ attribute is: • Animatable: no.

11.10.3.3. 重複する空白~指令

古い~SVG-11内容は `~xml_space$a を利用する。 新たな内容/作業し直されている古い内容は、 `white-space$p を利用して,既存の `~xml_space^a を除去することになる。 しかしながら,~UAは、同じ要素~上に両~手法とも利用する内容に出くわすこともあろう。 要素に `white-space^p ~propが設定された場合、 `~xml_space^a の値は無視される。 ◎ Older, SVG 1.1 content will use ‘xml:space’. New content, and older content that is being reworked, will use white-space and remove any existing ‘xml:space’. However, user agents may come across content which uses both methods on the same element. If the white-space property is set on any element, then the value of ‘xml:space’ is ignored.

11.11. ~text装飾

~SVGにおける~textは、[ 下線/上線/打消線 ]で`装飾できる^em。 装飾の[ 位置/~style ]は、 §行l装飾 `css-text-decor-3$r に定義される `text-decoration$pp 略式~prop, その下位prop( `text-decoration-line^p / `text-decoration-style^p )により決定される。 ◎ Text in SVG can be decorated with an underline, overline, and/or strike-through. The position and style of the decoration is determined respectively by the text-decoration-line and text-decoration-style properties, or by the text-decoration shorthand property as defined in the Line Decoration section of the CSS Text Decoration Module Level 3 [(css-text-decor-3)] specification.

装飾の[ ~fill/~stroke ]は、~text装飾が宣言された箇所にある~textの[ ~fill/~stroke ]により与えられる(下の例を見よ)。 ◎ The fill and stroke of the text decoration are given by the fill and stroke of the text at the point where the text decoration is declared (see example below).

注記: [ `text-decoration-line^p / `text-decoration-style^p ]~propは、~SVG-2にて新たに~~導入された。 [ ~SVG-11/~CSS 2.1 ]における `text-decoration$p ~propは、後方-互換な仕方で,これらの~prop用の略式に変形された。 ◎ The text-decoration-line and text-decoration-style properties are new in SVG 2. The SVG 1.1/CSS 2.1 text-decoration property is transformed in a backwards compatible way to a short hand for these properties.

~textと装飾が描かれる順序は、 §~text装飾の塗ng順序 `css-text-decor-3$r により定義される。 ~text装飾~自身の塗り順序(~fill/~stroke)は、当の~text装飾が宣言された要素の `paint-order$p ~propの値により決定される。 ◎ The order in which the text and decorations are drawn is defined by the Painting Order of Text Decorations section of CSS Text Decoration Module Level 3. The paint order of the text decoration itself (fill/stroke) is determined by the value of the paint-order property at the point where the text decoration is declared.

例 `textdecoration01@xl は、 `text-decoration$p 用の例を供する。 ~textの 1 行l目には `text-decoration$p 用の値は無いので、初期~値 `none^v が利用される。 [ 2/3 ]行l目は、 `text-decoration$p に対する値[ `line-through^v / `underline^v ]を示す。 4 行l目は、[ `text-decoration$p が指定されている要素の[ `fill$p, `stroke$p ]~propを利用して,装飾を描画する規則 ]を示す。 `text-decoration$p は `text$e 要素~上に指定されているので、その中のすべての~textは,この `text^e の[ `fill^p, `stroke^p ]~propで下線が描画される(すなわち,~fillは `blue^v, ~strokeは `red^v ) — 各 単語の[ `fill^p, `stroke^p ]~prop値は異なっていても。 しかしながら,単語 `different^l を囲っている `tspan$e 要素は `text-decoration$p 用の値を明示的に指定するので、その下線は,この `tspan^e 要素の[ `fill^p, `stroke^p ]~prop利用して描画される(すなわち,~fillは `yellow^v, ~strokeは `darkgreen^v ): ◎ Example textdecoration01 provides examples for text-decoration. The first line of text has no value for text-decoration, so the initial value of text-decoration:none is used. The second line shows text-decoration:line-through. The third line shows text-decoration:underline. The fourth line illustrates the rule whereby decorations are rendered using the same fill and stroke properties as are present on the element for which the text-decoration is specified. Since text-decoration is specified on the ‘text’ element, all text within the ‘text’ element has its underline rendered with the same fill and stroke properties as exist on the ‘text’ element (i.e., blue fill, red stroke), even though the various words have different fill and stroke property values. However, the word "different" explicitly specifies a value for text-decoration; thus, its underline is rendered using the fill and stroke properties as the ‘tspan’ element that surrounds the word "different" (i.e., yellow fill, darkgreen stroke):

<?xml version="1.0" standalone="no"?>
<svg
  width="12cm" height="4cm"
  viewBox="0 0 1200 400"
  xmlns="http://www.w3.org/2000/svg"
  version="1.1"
>
  <desc>
例 `textdecoration01^xl
— `text-decoration^ ~propの挙動
◎
Example textdecoration01 - behavior of 'text-decoration' property
</desc>
  <rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="2" />
  <g font-size="60" fill="blue" stroke="red" stroke-width="1" >
    <text x="100" y="75">Normal text</text>
    <text x="100" y="165" text-decoration="line-through" >Text with line-through</text>
    <text x="100" y="255" text-decoration="underline" >Underlined text</text>
    <text x="100" y="345" text-decoration="underline" >
      <tspan>One </tspan>
      <tspan fill="yellow" stroke="purple" >word </tspan>
      <tspan fill="yellow" stroke="black" >has </tspan>
      <tspan fill="yellow" stroke="darkgreen" text-decoration="underline" >different </tspan>
      <tspan fill="yellow" stroke="blue" >underlining</tspan>
    </text>
  </g>
</svg>
`textdecoration01^dgm
例 `textdecoration01^xl 【紫に見える~fill/~strokeは、実際には `blue^v, `red^v が混ざっている。】 ◎ Example textdecoration01
`text/textdecoration01.svg$viewAs

11.12. ~text選択と~clipboard操作o

`適合~SVG~viewer$は、~systemが[ ~text選択~用の能力を備える(例:~mouseなどの~pointer装置を備える~system), ~copy, ~paste操作o用の~system~clipboardも備える ]ならば,次を~supportすることが要求される: ◎ Conforming SVG viewers on systems which have the capacity for text selection (e.g., systems which are equipped with a pointer device such as a mouse) and which have system clipboards for copy/paste operations are required to support:

~text選択~操作oは、次に挙げるすべてが同時に満たされたとき,開始する: ◎ A text selection operation starts when all of the following occur:

~text選択~操作oを続行するに伴い(例:利用者は~mouse~buttonを押下げ続けている),~UAは、他の~graphics要素に結付けられている すべての~eventを無視して(すなわち,~text選択~操作oは~modal)、[ `selection$pe 疑似要素~用の~styleを適用して,どの文字たちが選択されたかを動的に指示する ]モノトスル。 ~text選択を処理する間,~pointerが移動するに伴い、~text選択~操作o用の終端~glyphは,同じ `text$e 要素の中の~glyph~cellが~pointerに最も近い~glyphになる。 ~UAは、 `text$e 要素の中の文字のうち[ その位置は `text$e 要素の中で選択の始端と終端の合間にある ]ものを強調するモノトスル — ~canvas上の位置や,選択~点の終端の上に~graphics要素があるかどうかに関わらず。 ◎ As the text selection operation proceeds (e.g., the user continues to press the given mouse button), all associated events with other graphics elements are ignored (i.e., the text selection operation is modal) and the SVG user agent shall dynamically indicate which characters are selected by applying styles for the ::selection pseudo-class. As the pointer is moved during the text selection process, the end glyph for the text selection operation is the glyph within the same ‘text’ element whose glyph cell is closest to the pointer. All characters within the ‘text’ element whose position within the ‘text’ element is between the start of selection and end of selection shall be highlighted, regardless of position on the canvas and regardless of any graphics elements that might be above the end of selection point.

~text選択~操作oが終止したなら(例:利用者は所与の~mouse~buttonを放した)、選択された~textは,[ ~pointer装置~作動化~eventなどの,~text選択を取消す~event ]が生じる(例:~mouse~buttonを押下げたなど)まで強調され続けることになる。 ◎ Once the text selection operation ends (e.g., the user releases the given mouse button), the selected text will stay highlighted until an event occurs which cancels text selection, such as a pointer device activation event (e.g., pressing a mouse button).

~text選択~操作oの間に どの文字たちを強調するか決定するための詳細な規則は、 §~text選択の実装~注記 に供される。 ◎ Detailed rules for determining which characters to highlight during a text selection operation are provided in Text selection implementation notes.

~system~clipboardを備える~system上の~UAは、[ 現在~選択された~textを~system~clipboardへ~copyすることを起動する~UI ]を供することが要求される。 ~UAは — 素な~text用には、選択された~text文字列を,~systemに適切な~clipboard形式で投函するだけでも足るが — 所与の~text文字列に結付けられている様々な~font~propを取り込むような~rich-textも,代替として投函する方が好ましい。 ◎ For systems which have system clipboards, the SVG user agent is required to provide a user interface for initiating a copy of the currently selected text to the system clipboard. It is sufficient for the SVG user agent to post the selected text string in the system's appropriate clipboard format for plain text, but it is preferable if the SVG user agent also posts a rich text alternative which captures the various font properties associated with the given text string.

双方向-~text用には、~UAは,論理-順序による~text選択を~supportするモノトスル — その結果、文字の双方向-並替ngに因り,~glyphたちは視覚的に不連続に選択される。 ~UAは、双方向-~textを視覚的な(すなわち,双方向-~text~layout~algoを適用した後の)描画~順序で選択する代替~能を供せる, — その結果、選択された文字~dataは論理的には不連続になるかもしれない。 この事例では、利用者が双方向-~textを~clipboardに複製するよう要請した場合、~UAには,適切な調整を施して視覚的に選択された文字のみを~clipboardに複製することが要求される。 ◎ For bidirectional text, the user agent must support text selection in logical order, which will result in discontinuous highlighting of glyphs due to the bidirectional reordering of characters. User agents can provide an alternative ability to select bidirectional text in visual rendering order (i.e., after bidirectional text layout algorithms have been applied), with the result that selected character data might be discontinuous logically. In this case, if the user requests that bidirectional text be copied to the clipboard, then the user agent is required to make appropriate adjustments to copy only the visually selected characters to the clipboard.

[ ~SVG作者/`~SVG生成器$ ]は、~Web~browserなどの~SVG~viewerの中で~text選択が適正に順序付けられるのを手助けするよう,~text文字列を順序付けるベキである。 言い換えれば、~textの~DOM順序は,~textを読むときの自然な順序に合致するベキである。 ◎ SVG authors and SVG generators should order their text strings to facilitate properly ordered text selection within SVG viewing applications such as Web browsers; in other words, the DOM order of the text should match the natural reading order of the text.

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

以下の実装~注記では、 ~text選択操作oの間, どの文字たちが選択されるか裁定する~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 を見よ)。 例えば、文字~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. ~DOM~interface

~SVG-2要件: `text$e 要素を 外形線~path~dataに変換する~DOM~methodを備える。 ◎ SVG 2 Requirement: Have a DOM method to convert a ‘text’ element to outline path data.

  • 解決: `text^e 要素を 外形線~path~dataに変換する~DOM~methodを追加することとする — 場合によっては、その機能性を関係する仕様へ移動して( `http://www.w3.org/2012/01/13-svg-irc#T05-07-07$refer )。 ◎ Resolution: We will add a DOM method to convert a ‘text’ element to outline path data, possibly moving the functionality to the FXTF.
  • 目的: ~textを~pathとして操作できるようにする。 ◎ Purpose: To allow manipulation of text as a path.
  • Owner: Cameron (`3076$ACTION)
  • Status: Future wish list( `~SVGissue/221$refer )。

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:

定数 意味
`LENGTHADJUST_SPACING@m `spacing^v ~keyword
`LENGTHADJUST_SPACINGANDGLYPHS@m `spacingAndGlyphs^v ~keyword
`LENGTHADJUST_UNKNOWN@m 他の何らかの値
◎ Constant Meaning LENGTHADJUST_SPACING The spacing keyword. LENGTHADJUST_SPACINGANDGLYPHS The spacingAndGlyphs keyword. LENGTHADJUST_UNKNOWN Some other value.

【 以下に現れる “`~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 定数~表に与えられる。 ◎ 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を返すように改変している。 】
被呼出時には、此れの`~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 は 描画されない (例: `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.\

被呼出時には、次を走らす: ◎ 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.\

被呼出時には、次を走らす: ◎ 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$refer )。 ◎ Change to text length methods resolved at August 2015 Paris face-to-face.

`文字~用の~typographic文字を見出す@ ときは、所与の ( 要素 %要素, 整数 %charnum ) に対し,次の手続きを走らす: ◎ To find the typographic character for a character at index index within an element element, 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. ~WHILE[ %charnum ~LT %文字~list の`~size$ ]:

    1. %文字 ~LET %文字~list[ %charnum ]
    2. ~IF[ %文字 は`~typographic文字$に対応する ] ⇒ ~RET その~typographic文字
    3. %charnum ~INCBY 1
    ◎ Let last be the highest index assigned to a character. ◎ While charnum < last and the character at index charnum does not correspond to a typographic character: • Set charnum to charnum + 1. ◎ If charnum is greater than the highest index assigned to a character or, then return null. ◎ Otherwise, return the typographic character that corresponds to charnum.
  3. ~RET ~NULL ◎ ↑
`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.\

被呼出時には、次を走らす: ◎ 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.\

被呼出時には、次を走らす: ◎ 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.\

被呼出時には、次を走らす: ◎ 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.\

被呼出時には、次を走らす: ◎ 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\

被呼出時には、次を走らす: ◎ 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.\

被呼出時には、次を走らす: ◎ 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:

定数 意味
`TEXTPATH_METHODTYPE_ALIGN@m `align^v ~keyword
`TEXTPATH_METHODTYPE_STRETCH@m `stretch^v ~keyword
`TEXTPATH_METHODTYPE_UNKNOWN@m 他の何らかの値
◎ Constant Meaning TEXTPATH_METHODTYPE_ALIGN The align keyword. TEXTPATH_METHODTYPE_STRETCH The stretch keyword. TEXTPATH_METHODTYPE_UNKNOWN Some other value.

`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:

定数 意味
`TEXTPATH_SPACINGTYPE_AUTO@m `auto^v ~keyword
`TEXTPATH_SPACINGTYPE_EXACT@m `exact^v ~keyword
`TEXTPATH_SPACINGTYPE_UNKNOWN@m 他の何らかの値
◎ TEXTPATH_SPACINGTYPE_AUTO The auto keyword. TEXTPATH_SPACINGTYPE_EXACT The exact keyword. TEXTPATH_SPACINGTYPE_UNKNOWN Some other value.
`startOffset@m
`startOffset$a 内容~属性を`反映する$。 ◎ The startOffset IDL attribute reflects the ‘startOffset’ content attribute.
`method@m
`method$a 内容~属性を`反映する$。 `method$a 用の`数量-型~値$は、上で述べた数量- METHODTYPE 定数~表に与えられる。 ◎ 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 定数~表に与えられる。 ◎ 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.