CSS ルビ注釈 — CSS Ruby Annotation Layout Module Level 1

1.1. ~rubyとは何か？

`~ruby@ とは，［ その “基底” と称される，ある~text連なり ］に並行して現れる別の~text連なりであり、［ 基底に対する注釈や発音の手引きになるものとして，結付けられたもの ］を指すときに，共通的に利用されている名前である。 ◎ Ruby is the commonly-used name for a run of text that appears alongside another run of text (referred to as the “base”) and serves as an annotation or a pronunciation guide associated with that run of text.

単純な~rubyの例と, より複雑な構造を有する~rubyの例を，以下の図に示す： ◎ The following figures show two examples of Ruby, a simple case and one with more complicated structure.

~HTMLにおいては、 ~ruby構造とそれを表現する~markupは， `Ruby Markup Extension^cite 仕様 【`参照＠~TR/html-ruby-extensions/$】 にて述べられる。 この~moduleは、 そのような~markupの~ruby~layoutに関連な，~CSSによる描画~modelと整形~制御について述べる。 ◎ In HTML, ruby structure and markup to represent it is described in the Ruby Markup Extension specification. This module describes the CSS rendering model and formatting controls relevant to ruby layout of such markup.

`~ruby$, その整形に関する もっと深い導入は、 `QA-RUBY$r による記事 “~rubyとは何か（ `What is Ruby^en ）” に見出せる。 日本語において`~ruby$が伝統的に整形されてきた主な仕方についての多方面な情報は、 `JIS4051$r （日本語のみ）, および `JLREQ$r `§ ~rubyと~~圏点＠~TR/jlreq/#ruby_and_emphasis_dots$ （日本語, 英語 併記）にて見出せる。 `SIMPLE-RUBY$r もまた，日本語~rubyの整形~用にアリな~approachを述べる。 `CLREQ$r `§ 行l間~注釈＠~TR/clreq/#interlinear_annotations$ は、 中国語~typography用の関係する実施を述べる（中国語, 英語 併記）。 ◎ A more in-depth introduction to Ruby and its formatting can be found in the “What is Ruby“ article [QA-RUBY]. Extensive information about the main ways ruby has traditionally been formatted in Japanese can be found in JIS X-4051 [JIS4051] (in Japanese) and in “Ruby and Emphasis Dots” in Requirements for Japanese Text Layout [JLREQ] (in English and Japanese); Rules for Simple Placement of Japanese Ruby [SIMPLE-RUBY] also describes (in English) one possible approach for Japanese ruby formatting. “Interlinear annotations” in Requirements for Chinese Text Layout [CLREQ] describes the related practices for Chinese typography (in Chinese and English).

1.2. ~module間の相互作用

この~moduleは、 `CSS2$r の行内~box~modelを，~rubyを~supportするように拡張する。 ◎ This module extends the inline box model of CSS Level 2 [CSS2] to support ruby.

この~moduleのどの~propも［ `first-line$pe ／ `first-letter$pe ］疑似要素には適用されない。 しかしながら， `ruby-position$p は、 `first-line$pe を通して，最初の行l【`整形される最初の行l$】にある~ruby注釈に影響するように継承され得る。 ◎ None of the properties in this module apply to the ::first-line or ::first-letter pseudo-elements; however ruby-position can inherit through ::first-line to affect ruby annotations on the first line.

1.3. 値~定義

【 この節の内容は `~CSS日本語訳 共通~page＠~CSScommon#values$に移譲。 】

1.4. 図式の表記規約

東Asian~typographyにおける多くの~typographic上の表記規約は、 描画される文字が［ `wide^en （“~~全角”, ~CJK）, `narrow^en （“~~半角”, 非~CJK） ］のどちらであるかに依存する。 この文書の いくつかの~~図式では、 その区別と~text連なり内の文字~付番を，次のような凡例で表す： ◎ Many typographical conventions in East Asian typography depend on whether the character rendered is wide (CJK) or narrow (non-CJK). There are a number of illustrations in this document for which the following legend is used:

`四^xF

これは、 `~text連列$内の 4 個目の文字を指す，全角~glyphを表す（例： `漢字$）。 全角~glyphとして描画される文字は、 このように漢数字で表される。 ◎ Wide-cell glyph (e.g. Han) that is the nth character in the text sequence. They are typically sized to 50% when used as annotations.

`4^xH

これは、 `~text連列$内の 4 個目の文字を指す，半角~glyphを表す（例： ~roman ）。 半角~glyphとして描画される文字は、 このように洋数字で表される。 ◎ Narrow-cell glyph (e.g. Roman) which is the nth glyph in the text sequence.

いずれも，注釈においては、 概して，基底の~~半分~sizeで示される。 ◎ ↑

【 この訳では、［ 漢数字, 洋数字 ］でこれらを区別することにする。 原文では、 文字, 文字大小, ~~数字による添字 （ F_%n ／ h_%n ） で区別されている。 】

図式においては、［ 上の記号を成す~~数字の方位 ］が，そのまま［ その~~数字が表現する~glyphを~UAが描画するときの方位 ］として意図されるものと見做される。 図式におけるこれらの文字~間の間隔は、 ~~要点を明らかにするために意図的に変更されない限り，副次的なものである。 ◎ The orientation which the above symbols assume in the diagrams corresponds to the orientation that the glyphs they represent are intended to assume when rendered by the user agent. Spacing between these characters in the diagrams is incidental, unless intentionally changed to make a point.

【 便宜上，この訳では、 原文の［ `wide-cell^en ／ `narrow-cell^en ］を［ ~~全角／~~半角 ］と対訳しているが，いわゆる［ ~~全角（ `fullwidth^en ）／~~半角（ `halfwidth^en ） ］とは技術的に異なるかもしれない （例えば “~~半角カナ” は、 本当はどちらに分類されるべきか？）。 ~Unicode仕様における， `East_Asian_Width^en ~propの［ `wide^en ／ `narrow^en ］を意味するようにも見受けられるが、 原文でも説明されていないので，深く立ち入らないことにする。 】

2.1. ~rubyに特有な `display^p 値

予め定義-済みな~ruby要素を備えていない文書~言語（~XMLの応用など）用には、 作者は，文書~言語の要素を~ruby要素に対応付けることが要求される — これは、 `display$p ~propで行われる。 ◎ For document languages (such as XML applications) that do not have pre-defined ruby elements, authors must map document language elements to ruby elements; this is done with the display property.

次に挙げる新たな `display$p 値は、 任意な要素に~ruby~layoutの役割をアテガう： ◎ The following new display values assign ruby layout roles to an arbitrary element:

`ruby@v

要素は `~ruby容器~box@ を生成するよう指定する （~HTML／~XHTMLの `ruby^e 要素に対応する）。 ◎ Specifies that an element generates a ruby container box. (Corresponds to HTML/XHTML <ruby> elements.)

`ruby-base@v

要素は `~ruby基底~box@ を生成するよう指定する （~HTML／~XHTMLの `rb^e 要素に対応する）。 ◎ Specifies that an element generates a ruby base box. (Corresponds to HTML/XHTML <rb> elements.)

`ruby-text@v

要素は `~ruby注釈~box@ を生成するよう指定する （~HTML／~XHTMLの `rt^e 要素に対応する）。 ◎ Specifies that an element generates a ruby annotation box. (Corresponds to HTML/XHTML <rt> elements.)

`ruby-base-container@v

要素は `~ruby基底~容器~box@ を生成するよう指定する （~XHTMLの `rbc^e 要素に対応する — ~HTMLにおいては，`匿名~box$として生成される）。 ◎ Specifies that an element generates a ruby base container box. (Corresponds to XHTML <rbc> elements; generated as an anonymous box in HTML.)

`ruby-text-container@v

要素は `~ruby注釈~容器~box@ を生成するよう指定する （~HTML／~XHTMLの `rtc^e 要素に対応する）。 ◎ Specifies that an element generates a ruby annotation container box. (Corresponds to HTML/XHTML <rtc> elements.)

【 `rb^e, `rtc^e は，現在の~HTMLでは`廃された＠~HTMLobs#rb$ので、 ~HTMLにおいては， `rbc^e と同じく`匿名~box$として生成されることになる （この仕様に現れる “XHTML” は、 `~XML構文を利用する~HTML＠~HTMLxml#writing-xhtml-documents$ではなく， 過去に策定された方の仕様を指す）。 （あるいは、 入子にされた `ruby^e 要素が それらの~boxを生成することになるかもしれないが、 まだ仕様~化されていない）。 この仕様が定義する~ruby用の~propは，どれも継承されるので、 ~HTMLにおいて，それらの~propを［ `~ruby基底$／`~ruby基底~容器$／`~ruby注釈~容器$ ］に適用したいときは、 親の`~ruby容器$（ `ruby^e ）に指定することになろう。 】

専用の~ruby~markupを~supportする言語（~HTMLなど）を利用している作者は、 その~markupを利用するべきである — （ `span^e の様な）任意な要素に ~ruby `display$p 値で~styleをアテガうのでなく。 正しい~markupを利用すれば、 ~screen読取器や非~CSS描画器が ~ruby構造を解釈できることを確保できる。 ◎ Authors using a language (such as HTML) that supports dedicated ruby markup should use that markup rather than styling arbitrary elements (like <span>) with ruby display values. Using the correct markup ensures that screen readers and non-CSS renderers can interpret the ruby structures.

2.2. 匿名な~ruby~boxの生成

~CSS~modelでは、 文書~言語が，各種~ruby~boxのそれぞれに対応する要素を含むことは、 要求されない。 文書~構造に欠けている部分に対しては、 以下に与えられる， `~tableを正規化するときに利用される規則＠~CSS2TABLE#anonymous-boxes$ `CSS2$r に似た規則を通して、 `匿名~box$が暗黙に生成される。 ◎ The CSS model does not require that the document language include elements that correspond to each of these components. Missing parts of the structure are implied through the anonymous box generation rules similar to those used to normalize tables. [CSS2]

1. `塊~levelの~box$を`行内~化$する： ◎ Inlinify block-level boxes:＼

   `~flow内$にある~boxに直に包含されている［ `~ruby容器$／ `内部~ruby~box$【！`~ruby基底~box$／`~ruby注釈~box$／`~ruby基底~容器$／`~ruby注釈~容器$】 ］は — `行内~level$の内容のみを包含するよう — “`行内~化$” され、 `display$p 値はそれに則って算出される。 例えば，`~flow内$にある要素が［ 自身の `display$p は `block$v，親の `display$p は `ruby-text$v にされている ］場合、 要素の `display$p ~propは， `inline-block$v に算出される。 `CSS-DISPLAY-3$r ◎ Any in-flow boxes directly contained by a ruby container, ruby base container, ruby annotation container, ruby base box, or ruby annotation box are “inlinified” per [CSS-DISPLAY-3]), and their display value computed accordingly, so that they contain only inline-level content. For example, the display property of an in-flow element with display: block parented by an element with display: ruby-text computes to inline-block.

2. 匿名な~ruby容器を生成する： ◎ Generate anonymous ruby containers:＼

   不適正に包含されている`内部~ruby~box$ 【！`~ruby基底~容器$／`~ruby注釈~容器$／`~ruby基底~box$／`~ruby注釈~box$】 （および介在な`空白$）からなる，連続する並びは、 `匿名$【！~CSS2TABLE#anonymous-boxes】な`~ruby容器$内に包装する。 この段の目的においては、 次のものが不適正に包含されているとされる： ◎ Any consecutive sequence of improperly-contained ruby base containers, ruby annotation containers, ruby bases, and/or ruby annotations (and any intervening white space) is wrapped in an anonymous ruby container. For the purpose of this step:

   • `~ruby基底$であって，その親は［ `~ruby基底~容器$／`~ruby容器$ ］でないもの。 ◎ an improperly-contained ruby base is one not parented by a ruby base container or ruby container
   • `~ruby注釈$であって，その親は［ `~ruby注釈~容器$／`~ruby容器$ ］でもないもの。 ◎ an improperly-contained ruby annotation is one not parented by a ruby annotation container or ruby container
   • ［ `~ruby基底~容器$／`~ruby注釈~容器$ ］であって，その親は`~ruby容器$でないもの。 ◎ an improperly-contained ruby base container or ruby annotation container is one not parented by a ruby container

3. 親が違えられた`行内~level$の内容を包装する： ◎ Wrap misparented inline-level content:＼

   連続する［ ~textや`行内~levelの~box$ ］からなる並びのうち，その親が： ◎ ↓

   • ［ `~ruby容器$／`~ruby基底~容器$ ］であるものは、 `匿名$な`~ruby基底$内に包装する。 ◎ Any consecutive sequence of text and inline-level boxes directly parented by a ruby container or ruby base container is wrapped in an anonymous ruby base.＼
   • `~ruby注釈~容器$であるものは、 `匿名$な`~ruby注釈$内に包装する。 ◎ Similarly, any consecutive sequence of text and inline-level boxes directly parented by a ruby annotation container is wrapped in an anonymous ruby annotation.＼

   （この目的においては、 親が違えられた`内部~table要素$は，`行内~level$の内容として扱われる — 親が~ruby~boxにされるものは、 最終的に`行内~level$の`~table包装~box$で包装されることになるので。） ◎ (For this purpose, misparented internal table elements are treated as inline-level content since, being parented by ruby boxes, they will be ultimately wrapped by an inline-level table wrapper box.)

   ただし，そのように構築された`匿名~box$が`空白$のみを包含する場合、 それは `~ruby内の空白@ と見なされ、 下に述べるように，破棄されるか保全される。 ◎ However, if an anonymous box so constructed contains only white space, it is considered intra-ruby white space and is either discarded or preserved as described below.

4. 頭部／尾部にある空白を削る：

   `~ruby内の空白$のうち， ~AND↓ を満たすものは、 `display:none$p にされていたかのように除去する：

   • 親は［ `~ruby容器$／`~ruby注釈~容器$／`~ruby基底~容器$ ］である
   • 親の`~flow内$にある子のうち，［ 最初か最後 ］のそれである
   • 親には、 他にも`~flow内$にある子がある
   ◎ Trim leading/trailing white space:＼ Any intra-ruby white space that is not the sole in-flow child of its parent and is the first or last in-flow child of a ruby container, ruby annotation container, or ruby base container is removed, as if it had display: none

5. 他の`~ruby内の空白$は、 その直前, 直後の`~flow内$にある同胞~box（`内部~ruby~box$【！`~ruby基底$／`~ruby注釈$／`~ruby基底~容器$／`~ruby注釈~容器$】）に応じて，次の表tに挙げる下位型に分類される：

   直前の~box	直後の~box	~box型	下位型
   任意	`~ruby注釈~容器$	なし	`~level間の空白@
   `~ruby注釈$でない	`~ruby注釈$	なし	同上
   `~ruby注釈$	`~ruby注釈$	`~ruby注釈$	`注釈~間の空白@
   `~ruby基底$	`~ruby基底$	`~ruby基底$	`基底~間の空白@
   上に挙げたもの以外の任意の組み合わせ		`~ruby基底$	`区分~間の空白@

   これらのうち，`~level間の空白$以外のものは、 `~level内の空白@ と総称される。

   ◎ ↓

6. `~level間の空白$を除去する： ◎ Remove inter-level white space:＼

   `~level間の空白$は、 `display:none$p にされていたかのように除去する。 ◎ Any intra-ruby white space whose immediately adjacent in-flow siblings match one of the patterns below is inter-level white space and is removed, as if it had display: none. • Previous box｜Next box • any｜ruby annotation container • not ruby annotation｜ruby annotation

7. `~level内の空白$を解釈する： ◎ Interpret intra-level white space:＼

   `~level内の空白$には、 上の表tに示した対応する~box型をアテガう — これらは、 `~pair法$と~layoutにおいては，後述するように特別に扱われる。 ◎ Any intra-ruby white space box whose immediately adjacent in-flow siblings match one of the patterns below is assigned the box type and subtype defined in the table below: • Previous box｜Next box｜Box type｜Subtype • ruby base｜ruby base｜ruby base｜inter-base white space • ruby annotation｜ruby annotation｜ruby annotation｜inter-annotation white space • ruby annotation or ruby annotation container｜ruby base or ruby base container｜ruby base｜inter-segment white space • ruby base or ruby base container｜ruby base container • ruby base container｜ruby base or ruby base container ◎ The intra-level white space boxes defined above are treated specially for pairing and layout. See below.

8. 行l分断を抑止する： ◎ Suppress line breaks:＼

   `~ruby注釈$の内側にあるすべての`強制d行l分断$は、 `縮約-可能$な`区分~分断$として， `CSS-TEXT-3$r `§ 区分~分断の変形n規則＠~CSSTEXT#line-break-transform$ による定義に従って変換する（ `white-space$p 値に関わらず）。 ◎ Convert all forced line breaks inside ruby annotations (regardless of white-space value) as defined for collapsible segment breaks in CSS Text Level 3 § 4.1.2.

   これの目標は、 ~ruby注釈の中では，行l分断を抑止して~layout~modelを単純~化することにある。 別法として、 受容-可能な何らかの種類の挙動を定義しようと試行することもできたが。 ◎ The goal of this is to simplify the layout model by suppressing any line breaks within ruby annotations. Alternatively we could try to define some kind of acceptable behavior for them.

9. 匿名~levelの容器を生成する： ◎ Generate anonymous level containers:＼

   • 連続する［ `~ruby基底$／`基底~間の空白$ ］からなる並びであって，親は`~ruby基底~容器$でないものは、 `匿名$な`~ruby基底~容器$内に包装する。 ◎ Any consecutive sequence of ruby bases and inter-base white space (and not inter-segment white space) not parented by a ruby base container is wrapped in an anonymous ruby base container.＼
   • 連続する［ `~ruby注釈$／`注釈~間の空白$ ］からなる並びであって，親は`~ruby注釈~容器$でないものは、 `匿名$な`~ruby注釈~容器$内に包装する。 ◎ Similarly, any consecutive sequence of ruby annotations and inter-annotation white space not parented by a ruby annotation container is wrapped in an anonymous ruby annotation container.

この節の規則により，~ruby~layout構造~内の親子関係がすべて適正にされたなら、 ~UAは，基底とそれらの注釈とを結付けることになる。 ◎ Once all ruby layout structures are properly parented, the UA can start to associate bases with their annotations.

注記： ~UAには、 これらの`匿名~box$ （および， `§ 注釈の~pair法＠#ruby-pairing$による［ `匿名$かつ空な`~level内の空白$ ~box ］）を，~~実際に内部~構造に作成することは要求されない — `~pair法$と~layoutが，それらが存在するかのように挙動する限り。 ◎ Note: The UA is not required to create any of these anonymous boxes (or the anonymous empty intra-level white space boxes in § 2.3 Annotation Pairing) in its internal structures, as long as pairing and layout behaves as if they existed.

2.3. 注釈の~pair法

注釈の `~pair法@ は、 `~ruby注釈$たちと`~ruby基底$たちとを結付ける処理nである： ◎ Annotation pairing is the process of associating ruby annotations with ruby bases.＼

• 各 `~ruby注釈$には、 1 個~以上の`~ruby基底$が結付けられる — このことを［ `~ruby注釈$は，それらの基底に `~span@ する ］という （複数個の基底に`~span$する`~ruby注釈$は、 `~spanning注釈@ と呼ばれる†）。 ◎ Each ruby annotation is associated with one or more ruby bases, and is said to span those bases. (A ruby annotation that spans multiple bases is called a spanning annotation.)

  【† この訳では，この用語は利用せず、 複数に限定する必要がある所では，明示的に “複数個の基底に~spanする” と記す。 “~spanする” が単数も複数も含意するのに対し， “~spanning（~spanしている）” が単数の否定を含意することは、 （少なくとも~~日本語の感覚としては，）直感的でないので。 】

• ある`~ruby基底$に結付けられる`~ruby注釈$の個数は、 `注釈~level$ごとに 1 個までである。 `注釈~level$が複数個あれば、 同じ~ruby基底に複数個の`~ruby注釈$が結付けられ得る。 ◎ A ruby base can be associated with only one ruby annotation per annotation level. However, if there are multiple annotation levels, it can be associated with multiple ruby annotations.

【 `文字~間の注釈$は、 自前の~ruby~colを形成する。 それ以外の点では、 `~ruby~col$と`~ruby区分$は，同一視できよう （これらの用語は、 同じ概念の 2 つの側面 — 順に，~layout上の側面, 構造~上の側面 — を表す）。 】

2.4. 注釈の隠法： `visibility:collapse^p と自動で隠される~ruby

`~ruby注釈$のうち，その `visibility$p が `collapse$v にされたものは、 `隠される注釈@ になる。 他の`~ruby注釈$のうち，その~text内容が対応する`~ruby基底$と正確に同じであるものも、 ~UAにより自動的に`隠され$る。 後者は、 `自動で隠され@ ると称される。 ◎ A ruby annotation whose visibility is collapse is a hidden annotation. Additionally, if a ruby annotation has the exact same text content as its base, it is automatically hidden (auto-hidden) by the UA.

`~ruby注釈$は、 `隠され$ても，注釈の`~pair法$には影響しない。 しかしながら，`隠され$た注釈は、 可視にはならず，［ 同~levelの中で隣接な`~ruby注釈~box$の並びを分離する ］以外には，~layoutへの影響iはない — 当の注釈が別々な`~ruby区分$に所属していて，［ 対応する基底は`~ruby基底$ではなく介在な行内であった ］かのように。 ◎ Hiding a ruby annotation does not affect annotation pairing. However the hidden annotation is not visible, and it has no impact on layout other than to separate adjacent sequences of ruby annotation boxes within its level, as if they belonged to separate segments and the hidden annotation’s base were not a ruby base but an intervening inline.

`~ruby注釈~容器$の `ruby-merge$p の`算出d値$が `merge$v の場合、 注釈を`隠す$ふるまいは不能化される。 算出d値が `auto$v の場合、 ~UAは，それを不能化するかどうか裁定してもヨイが、 ~UAの~layout~algoが `separate$v による結果と類似な結果を生産する場合には，可能化することが推奨される。 ◎ When the computed value of ruby-merge on the annotation container is merge, hiding is disabled. When that value is auto, the user agent may decide whether to disable hiding of its annotations, but it is recommended to enable hiding if the user agent’s layout algorithm produces the results similar to separate.

`自動で隠す$ための内容~比較は、［ （ `white-space$p による）空白の縮約-法 ／ （ `text-transform$p による）~text変形n ］に先立って行われ，要素は無視される（~boxの `textContent^c のみを考慮する）。 ◎ The content comparison for auto-hiding takes place prior to white space collapsing (white-space) and text transformation (text-transform) and ignores elements (considers only the textContent of the boxes).

注記： ~CSS~Rubyの将来の~levelでは，`自動で隠す$ための制御も追加され得るが、 この~levelでは常に強制される。 ◎ Note: Future levels of CSS Ruby may add controls for auto-hiding, but in this level it is always forced.

2.5. 空白の縮約-法

`§ 匿名~ruby~boxの生成＠#box-fixup$ にて論じたとおり、 ~ruby構造の中の空白のうち次のいずれかに該当するものは， `破棄される＠#anon-gen-discard-space$： ◎ As discussed in § 2.2 Anonymous Ruby Box Generation, white space within a ruby structure is discarded:

• ［ `~ruby容器$／`~ruby注釈~容器$／`~ruby基底~容器$ ］の先頭や末尾にあるもの。 ◎ at the beginning and end of a ruby container, annotation container, or base container,
• `~ruby基底~容器$と, それに後続する`~ruby注釈~容器$との合間にあるもの。 ◎ between a base container and its following annotation container,
• `~ruby注釈~容器$たちの各~合間にあるもの。 ◎ between annotation containers.

しかしながら，［ `~ruby区分$どうしの合間 ／ `~ruby基底$どうしの合間 ／ `~ruby注釈$どうしの合間 ］にある空白は、 破棄されず，［ `区分~間の空白$ ／ `基底~間の空白$ ／ `注釈~間の空白$ ］として描画するために保守される （上述した `~level内の空白を解釈する＠#anon-gen-interpret-space$ を見よ）。 ◎ Between ruby segments, between ruby bases, and between ruby annotations, however, white space is not discarded, and is maintained for rendering as inter-base, inter-annotation, or inter-segment white space. (See Interpret intra-level white space, above.)

破棄されない空白が`縮約-可能$になる所では、 標準な `CSS-TEXT-3$r `§ 空白~処理~規則$ に従って，各~行l~box内の隣接な~boxたちに わたって縮約されることになる。 ［ 別々な`~ruby区分$に属する注釈どうし／ `隠される注釈$で分離された注釈どうし ］は、 隣接な注釈とは見なされない。 しかしながら，`基底~level$の内容 — `不可分な行内$として扱われる`文字~間の注釈$も含む — においては、 そのような~~例外はない。 したがって，［ `~ruby区分$たちの合間にある`縮約-可能$な空白（`区分~間の空白$）用に， `区分~分断の変形n＠~CSSTEXT#line-break-transform$ を決定する ］ための文脈を成す前後の~textは、 両~側にある`~ruby基底$により与えられる — それらは、 文書~順序において，~source内で当の空白の両~側にある~textになるとは限らない （そのような~textは、 `行l間の注釈$を含み得るので）。 ◎ Where undiscarded white space is collapsible, it will collapse across adjacent boxes in each line box following the standard white space processing rules [CSS-TEXT-3]. Annotations in separate ruby segments or separated by hidden annotations are not considered adjacent; however all base-level content (including inter-character annotations, which are treated as atomic inlines) is. For collapsible white space between ruby segments (inter-segment white space), the contextual text for determining segment break transformations is thus given by the ruby bases on either side, not necessarily the text on either side of the white space in source document order (which could include interlinear annotations).

3.1. 行l間の~ruby~layout

同じ`注釈~level$に属する`行l間$の`~ruby注釈$は、 まず，［ それらが，同じ`行内~整形~文脈$に関与している`行内~box$であった ］かのように~lay-outされ、 実質的に，当の`~ruby容器$内で それらの注釈~用の`行l~box$を確立する。 `~ruby注釈$と`~ruby基底$どうしは、 以下に述べるとおりに間隔法を調整することにより，互いに整列される。 ◎ Interlinear ruby annotations within a level are initially laid out as if they were inline boxes participating in the same inline formatting context, effectively establishing a line box for that level of annotation in the ruby container. Annotations and bases are aligned to each other by adjusting their spacing as described below.

3.2. 文字~間~rubyの~layout

`文字~間の注釈$の~layoutは、 特別になる。 `文字~間$の`~ruby注釈~box$は、 `基底~level$の~layoutの一部として継合され, 測定される。 そのような注釈~boxは、［ それが`~span$している`~ruby基底$のうち最も右端にあるもの ］の直後に配置され、 以下に述べることを除けば，`行内~塊$と正確に同じに~lay-outされる。 ◎ Inter-character annotations have special layout. Inter-character ruby annotation boxes are spliced into and measured as part of the layout of the base level. Each ruby annotation is inserted to the right of the ruby base it is paired with; a spanning inter-character annotation is placed after the rightmost of all the bases that it spans. Inter-character ruby annotations are laid out exactly like inline blocks, except as described below.

注記： `inter-character$v の定義により，`文字~間の注釈$は、 その `writing-mode$p は常に `vertical-rl$v になり，それが属する`~ruby容器$が`横書き$の場合にしか存在し得ない。 ◎ Note: As per the definition of inter-character, inter-character annotations always have a vertical-rl writing-mode, and only exist in horizontal ruby containers.

`文字~間$の`~ruby注釈~容器$【！`~ruby注釈$】 %容器 は、 対応する`~ruby基底$の右端に, `基底~間の空白$（または`区分~間の空白$）の直前に配置される。 %容器 内に`文字~間$の`~ruby注釈~box$が複数個ある【`注釈~level$が複数個ある】場合、 それらの`~margin~box$は — 介在な間隔を伴わずに，`注釈~level$の~~昇順で — 右方へ堆積される†。 ◎ Each ruby annotation is placed immediately to the right of the relevant ruby base, before any inter-base white space (or inter-segment white space). If multiple inter-character ruby annotation boxes are placed against the same ruby base, their margin boxes are stacked rightwards without intervening space, in increasing level order.

【† 右横書きの下では、 `~ruby基底$の左端から，左方へ堆積されよう （そのような利用事例は無いであろうが、 理論的には）。 】

`文字~間$の`~ruby注釈~box$ %注釈 の`内容~区画$の縦幅が`自動的~size$にされていて — %注釈 を配置した後において — 対応する`~ruby基底$の`内容~box$の縦幅より短くなる場合、 %注釈 の`内容~box$の縦幅は、 その縦幅に正確に合致するよう増やされる。 ◎ If the automatic height of the ruby annotation box’s content area would be shorter than the height of the content box of the ruby base after which it is placed, its content box height is increased to match that height exactly.

`文字~間$の`~ruby注釈~box$ %注釈 の整列は、 その `ruby-align$p ~propに依存する — ［ %注釈, 対応する`~ruby基底$ ］の`内容~box$は ⇒＃ `ruby-align$p は `start$v ならば，上端~辺どうしが整列される／ ~ELSE_ 縦方向において中央どうしが整列される ◎ The alignment of the ruby annotation box depends on the ruby-align property on the ruby annotation: • If ruby-align is start, the top edge of the ruby annotation's content box is aligned with the top edge of the ruby base's content box. • Otherwise, the center of the ruby annotation's content box is vertically aligned with the center of the ruby base's content box.

`文字~間$の`~ruby注釈~容器~box$は、 その`内容~box$が対応する`~ruby基底~容器$の`内容~box$と正確に一致するよう，~sizeされ, 配置される。 ◎ The ruby annotation container box of an inter-character annotation is sized and placed so that its content box coincides exactly with that of the ruby base container box.

注記： `文字~間$の`~ruby注釈~容器~box$の~sizeと位置には、 ~layoutに対する効果は無い。 上の定義は、 単に，それらを~program的に問い合わせることで決定的な結果を生産するためにある【？】。 ◎ Note: The size and position of inter-character ruby annotation container boxes has no effect on layout. The above definition is merely so that programmatically inquiring about them produces deterministic results.

［ `ruby-align$p による整列, `~ruby~col$の~sizing ］の目的においては、 `文字~間$の`~ruby注釈$は， （`§ ~ruby~layout＠#ruby-layout$にて論じたように）［ 対応する基底と同じ`~ruby~col$の一部を成す ］とは見なされない — それは、 実質的に自前の`~ruby~col$を形成する。 ◎ For the purpose of alignment and column sizing (as discussed in § 3 Ruby Layout), inter-character ruby annotations are not considered to be part of the same column as the base to with they are attached; rather, they effectively form a column of their own.

3.3. ~ruby~boxの~style法

次に挙げる~propは、［ `~ruby基底~容器$／`~ruby注釈~容器$ ］には適用されない ⇒＃ ~margin~prop【 `margin$p, その下位prop】, ~padding~prop【 `padding$p, その下位prop】, ~border~prop【 `border$p, その下位prop】, `行内~box$には適用されない~prop ◎ Neither the margin, padding, border properties nor the any properties that do not apply to inline boxes apply to base containers or annotation containers.＼

`line-height$p ~propは、 `~ruby注釈~容器$には適用されない。 ◎ Additionally, line-height does not apply to annotation containers.

［ `~ruby基底~容器~box$ ／ `~ruby注釈~容器~box$ ］に対しては： ◎ ↓

• 次に挙げる~propの~supportは、 ~UAには要求されない ⇒＃ 背景~prop【 `background$p, その下位prop】 ／ 外形線~prop【 `outline$p, その下位prop】／ 当の~boxの限界域を~~露わにするような他の~prop ◎ The UA is not required to support any of the background properties or outline properties, or any other property that illustrates the bounds of the box on ruby base container boxes or ruby annotation container boxes.＼
• ~UAは、 これらの~boxを，単純に［ その内容の~layoutに対する［ 継承, 制御 ］用の抽象-化 ］として実装してもヨイ。 ◎ The UA may implement these boxes simply as abstractions for inheritance and control over the layout of their contents.

3.4. 複数~行lへの分断-法

`~ruby容器$全体が 1 行lに収まり切らない, かつ すべての~levelが同時に分断を許容している場合、 ~rubyは，分断されてもヨイ （行l分断法の詳細は、 `CSS-TEXT-3$r `§ 行l分断法と単語~境界＠~CSSTEXT#line-breaking$ を見よ）。 ~rubyは，［ 基底, 注釈 ］が成す集合どうしの合間にて分断することが最も多いが、 `~ruby基底$（および, それに結付けられ, それに並行する各`~ruby注釈~box$たち）の中でも，分断できる — `行-分断ng規則$がそれを許容するならば。 ◎ When there is not enough space for an entire ruby container to fit on the line, the ruby may be broken wherever all levels simultaneously allow a break. (See CSS Text 3 §5 Line Breaking and Word Boundaries for details on line breaking.) Ruby most often breaks between base-annotation sets, but if the line-breaking rules allow it, can also break within a ruby base (and, in parallel, its associated ruby annotation boxes).

~rubyを複数~行lに分断するときは、 各`~ruby注釈$と対応する`~ruby基底$たちは — `文字~間の注釈$の事例においても — 一緒であり続けるモノトスル。 注釈と基底たちの合間では，行lを`分断しない^emモノトスル。 ◎ Whenever ruby breaks across lines, ruby annotations must stay with their respective ruby bases. The line must not break between a ruby base and its annotations, even in the case of inter-character annotations.

各~断片は、 行lを分断した後，独立に ⇒＃ まず，`~lay-outされ＠#ruby-layout$、 次に， `ruby-align$p による整列が施される。 ◎ After line-breaking, each fragment is laid out independently, and ruby alignment takes place within each fragment.

3.5. 双向~並替ng

同じ段落の中で，方向性が互いに反対向きな用字系に属する文字が混在する場合、 ~Unicode双方向-~algoにより，論理-順序で格納された~textは 視覚的な呈示~用に並替えられる。 ◎ The Unicode bidirectional algorithm reorders logically-stored text for visual presentation when characters from scripts of opposing directionalities are mixed within a single paragraph.

`~ruby注釈$と対応する`~ruby基底$との対応関係を保全するため、 次の制約が課される： ◎ To preserve the correspondence of ruby annotations to their respective ruby bases, a few restrictions must be imposed:

• ［ `~ruby基底$／`~ruby注釈$ ］の内容の連続性は、 ~~保つモノトスル。 ◎ The contents of a ruby base or ruby annotation must remain contiguous.
• `~ruby基底$と，対応する`~ruby注釈$たちとは、 一緒に並替えるモノトスル。 ◎ Ruby annotations must be reordered together with their ruby bases.
• `~ruby注釈$が`~span$している`~ruby基底$たちの連続性は、 ~~保つモノトスル。 ◎ All ruby bases spanned by a single ruby annotation must remain contiguous.

その結果： ◎ To this end,

• `双向~隔離$は、［ すべての`内部~ruby~box$と, `~ruby容器$ ］に対し，強制される — すなわち， `unicode-bidi$p の`算出d値$は、 `指定d値$に応じて，次に従う ⇒＃ `normal$v ならば `isolate$v ／ `embed$v ならば `isolate^v ／ `bidi-override$v ならば `isolate-override$v ◎ Bidi isolation is forced on all internal ruby boxes and the ruby container: the normal and embed values of unicode-bidi compute to isolate, and bidi-override computes to isolate-override.

  注記： このことは、［ 暗黙的な双向~並替ngが，~ruby基底たちに わたって働く ］ことはないことを意味する。 よって，作者は、［ `~ruby容器$に宣言される方向性は，その内容に~~実際に合致する ］ことを確保する必要がある。 ◎ Note: This means that implicit bidi reordering does not work across ruby bases, so authors will need to ensure that the ruby container’s declared directionality does indeed match its contents.

• ~layoutの間，同じ`~ruby容器$の中にある`~ruby区分$たちは、 `~ruby容器$の `direction$p ~propにより順序付けられる。 ◎ During layout, ruby segments are ordered within the ruby container by the direction property of their ruby container.

• 同じ`~ruby区分$の中の［ `~ruby注釈$たち／`~ruby基底$たち ］は、 その~ruby区分の`~ruby基底~容器$の `direction$p ~propにより，それらが属する［ `~ruby基底~容器$／`~ruby注釈~容器$ ］の中で順序付けられる。 ただし，`併合される注釈$を成す`~ruby注釈~容器$に属する`~ruby注釈$たちは、 当の容器の `direction$p ~propにより順序付けられる — それらが，正確に［ 当の容器の中の`行内~box$並びであった ］かのように。 ◎ Within a segment, ruby bases and ruby annotations that are not merged are ordered within their respective containers by the direction property of the segment’s ruby base container. Merged annotations are ordered by the direction property of their annotation container, exactly as if they were a sequence of inline boxes within their annotation container.

  注記： このことは、 `併合される注釈$を成さない`~ruby注釈~容器$の `direction$p ~propは，~layoutの目的においては無視されることを意味する。 しかしながら，容器の子へは依然として継承できる — その結果，それが包含するどの`~ruby注釈$の`行内~基底~方向$にも影響する。 ◎ Note: This means the direction property on ruby annotation containers is ignored for the purpose of layout of non-merged annotations. However, it can still inherit into the container’s children and thereby affect the inline base direction of any ruby annotations it contains.

他の`行内~level$の内容と同じく、 `内部~ruby~box$たちの双向~並替ngは、 `行-分断ng$の後に起こる — 内容が複数~行lに分割0されるときには、 自身の論理-順序に則るようにするため。 ◎ As with other inline-level content, the bidi reordering of internal ruby boxes happens after line-breaking so that content is divided across lines according to its logical order.

注記： これらの規則を［ 特定0の`~ruby注釈~容器$の `ruby-merge$p が `merge$v のときに、 個々の注釈に対し`双向~隔離$を強制しないで，それらが一緒に処理されるのを可能化する ］よう，少し調整すると有用にもなり得る。 しかしながら，これは、 実装に複階性を追加することになり、 この状況を取扱う需要が無い下では，正当化されないと見受けられる。 これが取扱われるようにする必要がある者は、 ~CSS~WGに連絡することが奨励される。 ◎ Note: It could be useful to adjust these rules slightly so that when ruby-merge is merge on a particular annotation container, bidi isolation is not forced onto the individual annotations, enabling them to be processed together. However, this would add complexity to implementations, which does not seem justified in the absence of demand to handle this situation. Anyone with a need for this to be handled is encouraged to contact the CSS Working Group.

~CSSにおける双方向-~textについての より深い論は、 `CSS3-WRITING-MODES$r を見よ。 ◎ See [CSS3-WRITING-MODES] for a more in-depth discussion of bidirectional text in CSS.

3.6. 行l間の間隔法

~CSSでは、 `line-height$p ~propが，各~行lの合間の間隔法を制御する。 ある行l上の行内~内容【の行l高さ】が `line-height$p より短いときは、 `CSS-INLINE-3$r `§ 論理-縦幅と行-間の間隔法＠~CSSINLINE#line-height$ に指定されるとおり，内容の両~側に半-~leadingが追加される。 `CSS2$r ◎ The line-height property controls spacing between lines in CSS. When inline content on line is shorter than the line-height, half-leading is added on either side of the content, as specified in CSS Inline Layout 3 § 5 Logical Heights and Inter-line Spacing.

各 行l間の間隔法が一貫することを確保するため、 ~rubyを伴う文書における `line-height$p は、 概して，~textの各~行lの合間に置かれる~rubyを収容するに十分な大きさが確保されるようにされる。 したがって，普通は、［ `~ruby注釈~容器$／`~ruby注釈~box$ ］は，行lの行内~内容に測定される縦幅には寄与しない — どの［ 整列（ `vertical-align$p を見よ） ／ 行高~計算 ］も、 それが正確に通常の行内であったかのように，`~ruby基底~容器$のみを利用して遂行される。 ◎ In order to ensure consistent spacing of lines, documents with ruby typically ensure that the line-height is large enough to accommodate ruby between lines of text. Therefore, ordinarily, ruby annotation containers and ruby annotation boxes do not contribute to the measured height of a line’s inline contents; any alignment (see vertical-align) and line-height calculations are performed using only the ruby base container, exactly as if it were a normal inline.

しかしながら，`~ruby容器$に指定された `line-height$p が、［ 上端にある`~ruby注釈~容器$の上端から，下端にある`~ruby注釈~容器$の下端 ］までの距離に満たない場合、［［ 塊が 3 個の行lからなっていて, その各~行lが これと一致する~rubyを包含している ］場合にも，互いの`~ruby容器$は重合しない ］ように，`~ruby基底~容器$の適切な側（たち）に~leadingが追加される。 ◎ However, if the line-height specified on the ruby container is less than the distance between the top of the top ruby annotation container and the bottom of the bottom ruby annotation container, then additional leading is added on the appropriate side(s) of the ruby base container such that if a block consisted of three lines each containing ruby identical to this, none of the ruby containers would overlap.

注記： これは、 `~ruby注釈$たちを`行l~box$の中に~~保つことは確保しない。 これは単に、 `各 行l間の間隔法がすべて等しい^em, かつ `~ruby注釈$たちの量と位置決めも互いに等価な場合に，重合するのを避けるに十分な部屋を確保するに過ぎない。 ◎ Note: This does not ensure that the ruby annotations remain within the line box. It merely ensures that if all lines had equal spacing and equivalent amounts and positioning of ruby annotations, there would be enough room to avoid overlap.

作者は、 ~rubyを収容するに適切な［ `line-height$p ／ `padding$p ］を確保するべきである。 また、 特に，塊の［ 先頭／末尾 ］の所, および 行lが［ 段落の既定の~font~sizeより高い`行内~level$の内容 （画像, `行内~塊$, `vertical-align$p でズラされた要素たち，など） ］を包含するときに，特に気を付けるべきである。 ◎ Authors should ensure appropriate line-height and padding to accommodate ruby, and be particularly careful at the beginning or end of a block and when a line contains inline-level content (such as images, inline blocks, or elements shifted with vertical-align) taller than the paragraph’s default font size.

注記： ~rubyが［ 整列／行l~layout ］にどう影響するかについての更なる制御は、 `CSS Line Layout Module Level 3^cite 【 `CSS-INLINE-3$r ？】 の一部になる。 それは現在，開発の探求段階にあるので、 新たな特能の記述は，まだ それに依拠するべきでない。 ◎ Note: More control over how ruby affects alignment and line layout will be part of the CSS Line Layout Module Level 3. Note, it is currently in the exploratory stages of development; descriptions of new features should not yet be relied upon.

4.1. ~rubyの位置決め： `ruby-position^p ~prop

この~propは、 基底から~~相対的な，`~ruby注釈$の位置を制御する。 各種 値の意味は： ◎ This property controls position of the ruby annotation with respect to its base. Values have the following meanings:

`alternate@v

~~先行する`~level$の注釈と［ `over$v, `under$v ］が交替するように挙動させる。 すなわち、 当の`~ruby注釈~容器$が属する`~ruby区分$において，~~先行する`注釈~level$を成す`行l間の注釈$が： ◎ Different levels of annotations alternate between over and under.

• 無い場合 ⇒＃ この値が `under$v と伴に指定されているならば `under^v と同じに挙動する／ ~ELSE_ `over$v と同じに挙動する ◎ If the annotation container is the first level of annotation in its ruby segment, or if all prior levels are inter-character,＼ then alternate, either on its own or in combination with over, behaves the same as over, while alternate in combination with under behaves the same as under.
• 在る場合、 そらのうち最後のものが［ `over$v ／ `under$v ］として挙動するならば［ `under$v ／ `over$v ］と同じに挙動する。 （この事例では、 `over^v や `under^v の有無に関わらず，挙動に相違は無い。） ◎ Otherwise, if the previous level of interlinear annotation is over, alternate behaves like under, and vice versa.＼ (In this case, whether alternate is specified alone or in combination with over or under makes no difference.)

`over@v

~ruby注釈は、 基底の`行-上面$に現れる。 ◎ The ruby annotation appears line-over the base.

`under@v

~ruby注釈は、 基底の`行-下面$に現れる。 表語的 東Asian書記体系で利用されるのは 相対的に稀な設定であり、 教育用~textに最も見出され易い。 ◎ The ruby annotation appears line-under the base. This is a relatively rare setting used in ideographic East Asian writing systems, most easily found in educational text.

`inter-character@v

この~ruby注釈~容器 %注釈~容器 が属する`~ruby容器$の`書字~mode$に応じて： ◎ ↓

• `縦書き$の場合、 この値による効果は `over$v と同じになる。 ◎ If the writing mode of the enclosing ruby container is vertical, this value has the same effect as over.

• `横書き$の場合、 %注釈~容器 は `文字~間@ の（ `inter-character^en な）`~ruby注釈~容器$になる。 そのような注釈は、 対応する（横書きな）基底たちの右端に現れる。 この場合、 %注釈~容器 の子である各`~ruby注釈$の `writing-mode$p の`算出d値$は， `vertical-rl$v に強制される。 ◎ Otherwise, the ruby annotation becomes an inter-character annotation. The annotation appears on the right of the base in horizontal text. This forces the computed value of writing-mode of the ruby annotation children of this ruby annotation container to be vertical-rl.

  注記： %注釈~容器 自体の `writing-mode$p の算出d値は影響されない。 これは、 同じ要素~上の［ `writing-mode$p, `display$p, `ruby-position$p ］~propの算出d値どうしの循環依存を避けるため。 ◎ Note: The computed value of writing-mode on the ruby annotation container itself is not affected. This is to avoid circular dependencies between computed values on the writing-mode, display, and ruby-position properties on the same element.

  【 `~ruby注釈~容器$内の`~ruby注釈$は、 `文字~間$の`~ruby注釈$と呼ばれる。 原文には明示的に述べられていないが、 “`文字~間の注釈$” は，これらの総称を表す。 】

この値は、 とりわけ台湾で利用されている，繁体字~中国語の特別な事例~用に供されている。 その文脈においては、 （`注音符号$用の~glyphたちからなる）~rubyは — 基底~文字の~layoutは横書きであっても — 基底~glyphの右端~側に沿って縦書きに現れる： ◎ This value is provided for the special case of traditional Chinese as used especially in Taiwan: ruby (made of bopomofo glyphs) in that context appears vertically along the right side of the base glyph, even when the layout of the base characters is horizontal:

注記： 継承は — ~ruby~layout用に作成される匿名~boxを織り込むことなく — 要素~treeに対し働くので、 `文字~間の注釈$を利用する作者は，［ 要素に基づく`~ruby注釈~容器$, 匿名な`~ruby注釈$, 更なる子孫~要素 ］を孕んでいる~markup~patternを避けるよう気を付ける必要がある — それらの子孫は、 自身の書字~modeを［ `writing-mode$p が `vertical-rl$v に変更された`~ruby注釈$ ］ではなく，`~ruby注釈~容器$から継承することになるので。 ◎ Note: As inheritance works on the element tree without accounting for anonymous boxes created for ruby layout, when using inter-character annotations authors need to be careful to avoid markup patterns involving an element-based ruby annotation container, an anonymous ruby annotation, and further descendant elements, as those descendants would inherit their writing mode from the ruby annotation container, and not from the ruby annotation whose writing-mode has been changed to vertical-rl.

ruby { ruby-position: inter-character; }

`inter-character-1^xCode

上の~markupでは、 “~~問題になり得る~~注釈” 全体を包装するために， 匿名な`~ruby注釈~box$が `rtc^e 要素の子として作成される。 それは，［ `ruby-position$p が `inter-character$v になる`~ruby注釈~容器$ ］の子なので、 その `writing-mode$p は期待されるとおり `vertical-rl$v になる。 しかしながら、 `em^e 要素は，自身の `writing-mode$p を［ `vertical-rl$v に強制されていない `rtc^e 要素 ］から直に継承する。 ◎ In the above markup, an anonymous ruby annotation box is created as a child of the <rtc> element to wrap the whole “problematic annotation”. Since it is a child of an annotation container whose ruby-position is inter-character, its writing-mode will be vertical-rl, which is expected. However, the <em> element inherits its writing-mode directly from the <rtc> element, which has not been forced to vertical-rl.

この例では，`~ruby注釈~容器$を与える要素は明示的に必要yでないので、 代わりに`~ruby注釈$を与える要素を利用して，問題を避けることになろう： ◎ In this example, the explicit ruby annotation container element was not necessary, so using a ruby annotation element instead would avoid the problem:

`inter-character-2^xCode

`~ruby注釈~容器$を与える要素が明示的に必要になる場合、 `~ruby注釈$を与える要素を利用して，問題に取組むことになろう： ◎ If an explicit ruby annotation container element is needed, then using a ruby annotation element as well would also address the problem:

`inter-character-3^xCode

`~ruby注釈~容器$のうち，`文字~間$のそれでないものは、 `行l間@ の（ `interlinear^en な）`~ruby注釈~容器$ と呼ばれる。 ◎ Annotation containers that are not inter-character annotations are called interlinear annotations.

【 そのような容器~内の`~ruby注釈$は、 `行l間$の`~ruby注釈$と呼ばれる。 原文では明瞭に述べられていないが、 “`行l間の注釈$” は，これらの総称を表す。 】

【同じ`~ruby~col$内の】 複数個の`~ruby注釈~容器$に対し `ruby-position$p が同じになる場合、 それらは，基底~textから外方に堆積される。 ◎ If multiple ruby annotation containers have the same ruby-position, they stack outwards from the base text.

4.2. 注釈~間隔の共有-法： `ruby-merge^p ~prop

注記： `文字~間$の`~ruby注釈~容器$は、 常に別々であり，この~propは適用されない。 ◎ Note: Inter-character annotations are always separate, and this property does not apply.

各種 値の意味は： ◎ Possible values:

`separate@v

各~ruby注釈~boxは、 それが`~span$する基底~box（たち）と同じ`~ruby~col$（たち）の中に描画される — すなわち、 両~側にある隣接な基底と重合しない。 この~styleは、 `JLREQ$r では “~mono~ruby”【！モノルビ】 と呼ばれている。 ◎ Each ruby annotation box is rendered within the same column(s) as its corresponding base box(es), i.e. without overlapping adjacent bases on either side. This style is called “mono ruby” in [JLREQ].

例えば、 次の 2 つの行lを描画した結果は，同じになる： ◎ For example, the following two lines render the same:

`mujo-separate^xCode

`merge@v

同じ`~ruby区分$の中の同じ行l上にある すべての`~ruby注釈~box$は、 それらが属する`~ruby注釈~容器$の中で`行内~box$として連結され，［ 対応する`~ruby基底~box$たち すべてに`~span$している，単独の`~ruby注釈~box$ ］内に~lay-outされる。 この~styleによる描画は、 単独の行lに~lay-outされるときは， `JLREQ$r による “~group~ruby” に類似する。 しかしながら、 複数~行lに分断されるときは，各［ `~ruby注釈$と対応する`~ruby基底$たち ］は一緒に保たれる。 ◎ All ruby annotation boxes within the same ruby segment on the same line are concatenated as inline boxes within their annotation container, and laid out in a single anonymous ruby annotation box spanning all their associated ruby base boxes. When laid out on a single line, this style renders similar to “group ruby” in [JLREQ]. However, when it breaks across lines, ruby annotations are kept together with their respective ruby bases.

次の 2 つの行lの描画は、 両者とも文字~並びは 1 行lに収まるならば，同じになる： ◎ The following two lines render the same if both characters fit on one line:

`mujo-collapse^xCode

しかしながら，後者は、 2 つの基底が複数~行lに分割されるときには， `separate$v のときと同じに描画される。 ◎ However, the second one renders the same as ruby-position: separate when the two bases are split across lines.

`auto@v

【！with the intention that】 ~UAは、 各~ruby注釈~boxが，対応する基底~boxに どう描画するか決定するときには、 次が満たされる限り，どのような~algoを利用してもヨイ：

• すべての注釈が，それらに対応する基底の上面に収まる場合の結果は、 `separate$v と一致する。
• ある注釈が それが~spanする基底より幅広になる場合には、 それらの基底と隣接な基底との合間に間隔が課されないよう，何らかの仕方で空間が共有される。

◎ The user agent may use any algorithm to determine how each ruby annotation box is rendered to its corresponding base box, with the intention that if all annotations fit over their respective bases, the result is identical to separate, but if some annotations are wider than their bases the space is shared in some way to avoid imposing space between bases.

注記： この挙動は、 複合語~用に意図される。 `QA-RUBY$r `“~rubyとは何か？” 内の “熟語~ruby”＠https://www.w3.org/International/questions/qa-ruby#jukugo$ を見よ。 ◎ Note: This behavior is intended for compound words, see “Jukugo Ruby” in “What is ruby?”. [QA-RUBY]

この型の~rubyを描画するための規約には様々なものがあり、 それに応じて複階性も変わる — 例えば，次を見よ ⇒＃ `SIMPLE-RUBY$r `熟語~rubyの配置＠~TR/simple-ruby/#placement-of-jukugo-ruby$, `JLREQ$r `熟語~rubyの位置決め＠~TR/jlreq/#positioning_of_jukugoruby_with_respect_to_base_characters$, `JISX4051$r 4.12.3(c) 熟語~rubyの処理 ◎ There are various conventions for rendering this type of ruby, see Placement of Jukugo-ruby in [SIMPLE-RUBY], Positioning of Jukugo-ruby in [JLREQ], and 4.12.3(c) 熟語ルビの処理 in [JISX4051] for examples of varying complexity.

最も単純な，そのような規約は、 次に従うことである ⇒ ［ 次が満たされるならば `separate$v ／ 他の場合は `merge$v ］として描画する ⇒ どの`~ruby注釈~box$も，それが`~span$する`~ruby基底~box$たちの送幅の中に収まる ◎ The simplest of these is to render as separate if all ruby annotation boxes fit within the advances of their corresponding base boxes, and render as merge otherwise.

注記： `双向~隔離$があるので、［ 複数個の`~ruby注釈$／複数個の~ruby基底 ］にわたって，~textが合字を形成する（または合字に形状付けられる）ことはない — 前者が`併合される注釈$を成す場合でも。 `§ 双向~並替ng＠#bidi$, `CSS-TEXT-3$r `§ 要素~境界をまたがる形状付け＠~CSSTEXT#boundary-shaping$ を見よ。 ◎ Note: Text does not shape or form ligatures across ruby annotations or bases, even merged ones, due to bidi isolation. See § 3.5 Bidi Reordering and CSS Text 3 §7.3 Shaping Across Element Boundaries.

4.3. ~ruby~textの分布： `ruby-align^p ~prop

この~propは、 各種~ruby~boxの中で，その内容が対応する~boxを正確に埋めないときに，~textが どう分布するかを指定する。 `ruby-align$p により分布される間隔は、 両端揃えに因り分布される間隔とは無関係であり，独立になることに注意。 ◎ This property specifies how text is distributed within the various ruby boxes when their contents do not exactly fill their respective boxes. Note that space distributed by ruby-align is unrelated to, and independent of, any space distributed due to justification.

この~propは、 `文字~間$の注釈に対しては，~box自身の整列にも影響し得る （ `§ 文字~間~rubyの~layout＠#inter-character-layout$ を見よ）。 他の注釈に対しては、 ~boxの中の内容の整列には影響するが，~box自身の［ ~size／位置 ］には影響しない。 ◎ For inter-character annotations, this property can also affect the alignment of the box itself (see § 3.2 Inter-character Ruby Layout). It otherwise only affects the alignment of content within the box, not the size or position of the box itself.

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

`start@v

~ruby内容は、 ~boxの始端~辺に整列される。 ◎ The ruby content is aligned with the start edge of its box.

`四^xF`五^xF`六^xF`七^xF`4^xP `一^xF`二^xF`三^xF 【！ra-r】 `三^xF`四^xF`五^xF`六^xF`七^xF`八^xF `一^xF`二^xF`2^xP

“肩付き~ruby” は、 この値に近いが，まったく同じではない。 特に，それが基底から張出すときの挙動は、 周囲の文脈に依存して，始端への整列と相違する。 `JLREQ$r `§ ~mono~rubyの基底~文字に~~相対的な位置決め＠~TR/jlreq/#positioning_of_monoruby_with_respect_to_base_characters$ を見よ。 肩付き~rubyはまた，縦書きにしか利用されたことはなく、 JLTF【？】 は，それを特に重要ではないものと見なすので、 この値は，肩付き~rubyを処するほど十分~賢くする労をかけるに価しないであろう。 この値は、 他の何らかの目的で必要になるなら，保たれるべきであるが、 他の場合，単に落とすことにもなろう。 ◎ "Katatsuki ruby" (肩付きルビ) is close to, but not quite the same as, this start value. In particular, its behavior when overhanging its base can differ from start alignment depending on surrounding context, see JLREQ. Also, it’s only ever used in vertical writing, and the JLTF considers it not particularly important, so it may not be worth the effort to make this value smart enough to deal with katatsuki ruby. If start is needed for some other purpose, we should keep it. Otherwise, maybe just drop it?

`center@v

~ruby内容は、 ~boxの中で中央化される。 ◎ The ruby content is centered within its box.

`四^xF`五^xF`六^xF`七^xF `一^xF`二^xF`三^xF 【！ra-c-rb】 `三^xF`四^xF`五^xF`六^xF`七^xF`八^xF `一^xF`二^xF

`space-between@v

~ruby内容は（ `text-justify$p により定義される）通常の~text両端揃えに対するときと同じように拡がる — ただし，`両端揃え機会$が無い場合、 内容は中央化される。 ◎ The ruby content expands as defined for normal text justification (as defined by text-justify), except that if there are no justification opportunities the content is centered.

`四^xF`1.33^xP`五^xF`1.33^xP`六^xF`1.33^xP`七^xF `一^xF`二^xF`三^xF 【！ra-dl-rb】 `三^xF`四^xF`五^xF`六^xF`七^xF`八^xF `一^xF`2^xP`二^xF

`space-around@v

`両端揃え機会$が余分に存在する場合には，間隔のうち半分は~ruby内容の前, 半分は後に分布されることを除いて、 `space-between$v のときと同じになる。 ◎ As for space-between except that there exists an extra justification opportunities whose space is distributed half before and half after the ruby content.

`四^xF`1^xP`五^xF`1^xP`六^xF`1^xP`七^xF `一^xF`二^xF`三^xF 【！ra-ds-rb】 `三^xF`四^xF`五^xF`六^xF`七^xF`八^xF `一^xF`1^xP`二^xF

`既定の~UA~stylesheet＠#default-ua-ruby$は、 `~ruby注釈$に `text-justify:ruby$p を適用する。 それは，`両端揃え機会$を［ 隣接な~CJK`文字$たちの各~合間には定義するが， 隣接な［ ~Latin／注音符号 ］`文字$たちの各~合間には定義しない ］ので、［ `space-around$v, `space-between$v ］どちらであろうが，後者を成す`文字$たちは中央化される結果になる： ◎ The default UA style sheet applies text-justify: ruby to ruby annotations, defining justification opportunities between every adjacent pair of CJK characters but not between adjacent pairs of Latin or Bopomofo characters. Thus, the space-around and space-between values will nevertheless result in Latin or Bopomofo characters centered:

`4^xH`5^xH`6^xH`7^xH `一^xF`二^xF`三^xF 【！ra-dc-rb-h】 `四^xF`五^xF`六^xF`七^xF`八^xF`九^xF `1^xH`2^xH`3^xH

間隔の分布は、 `text-justify$p を介して制御できる。 `CSS-TEXT-3$r ◎ The distribution of space can be controlled via text-justify. [CSS-TEXT-3]

［ `~ruby注釈~box$／`~ruby基底~box$ ］の内容は、 当の~boxの `ruby-align$p の値に基づいて，当の~boxの中で整列される。 ただし，`併合される注釈$を成す`~ruby注釈~容器$ %容器 に属する`~ruby注釈$たちに対しては、 それらの `ruby-align$p は無視され、 それらの内容は， %容器 の `ruby-align$p の値に基づいて %容器 の中で整列される。 ◎ Content in ruby bases and ruby annotations, except those that span due to ruby-merge: merge, is aligned within its box based on the value of ruby-align on that box. Content in merged annotations is aligned within the ruby annotation container based on the value of ruby-align on the annotations container, ignoring the value of ruby-align on the individual ruby annotations.

`併合される注釈$が`~ruby区分$より幅広になる場合、 どうする？ 現在~指定されるとおり，各~基底を`併合される注釈$に~spanしているかのように~~拡げるか？ これは例えば、 `併合される注釈$の方が長いときに，複-基底な基底~容器~内の~textを中央化することを許容しない【？】。 代わりに、 基底~容器にも `ruby-merge$p を適用するのを許容するべきであろう — これは、 次のいずれかを要求することになる ⇒＃ 1 個の基底が複数個の注釈に~spanするのを許容する（基底は併合される一方で，併合されない注釈~levelもある）／ 基底が併合される場合、すべての注釈~levelも併合されなければならない。 ◎ What if a merged annotation causes the ruby segment to be wider? Does it cause each base to grow as if it were spanning them, as currently specified? This does not allow e.g. centering the text in a multi-base base container when its merged annotation is longer. Instead, maybe we should allow ruby-merge to apply to base containers as well, but this would require us either to allow a single base to span multiple annotations (if the base is merged but some annotation levels are not), or to require that if the base is merged, then all annotation levels must be merged as well.

`ruby-merge$p が `auto$v のときに内容が整列される仕方は，~UAに委ねられるが、 どの注釈も それに対応する基底たちに収まるときには， `separate$v による整列と一致させるモノトスル。 ◎ The way content is aligned when ruby-merge is auto is up to the user agent, but must be identical to that of ruby-merge: separate when all annotations fit over their respective bases.

4.4. ~ruby~text装飾

~text装飾は、 基底~textから各 注釈へは伝播しない。 ◎ Text decoration does not propagate from the base text to the annotations.

~rubyの先祖に~text装飾が指定されたときは、 その装飾は，~ruby基底~容器の内容~区画 全体にわたって — 長い注釈を収容するために~ruby基底~内容の各~側に追加された余分な間隔も含め — 描かれる。 この余分な間隔は、 ~text装飾が~ruby基底~自身に指定されている場合には，装飾されない — ~text装飾が その~boxに直に指定されたときに，~boxの自前の~paddingは装飾されないのと類似に。 `CSS3-TEXT-DECOR$r ◎ When text decoration is specified on an ancestor of the ruby, it is drawn across the entire content area of the ruby base container, including any extra space added on either side of the ruby base contents to accommodate long annotations. When text decoration is specified on a ruby base itself, this extra space is not decorated, similar to how a box’s own padding is not decorated when text decoration is specified directly on that box. [CSS3-TEXT-DECOR]

~text装飾は、 直に［ ~ruby基底~容器／~ruby注釈~容器 ］に指定されてもヨイ — そのような事例では、 その装飾は，容器のすべての［ 基底／注釈 ］（同順）に伝播され，継続性のため，それらの各~合間にも描かれる。 ◎ Text decoration may be specified directly on ruby base containers and ruby annotation containers: in such cases it is propagated to all of the container’s bases or annotations (respectively), and is also drawn between them for continuity.

~ruby注釈の位置は、 基底~textに適用されている［ 上線／下線 ］装飾との競合を避けるため，調整されてもヨイ。 基本的な，~font~sizeと基底線~整列が一貫である事例では、［ 上線／下線 ］は，当の`基底~level$と その側にある注釈との合間に位置される。 ◎ The positions of ruby annotations may be adjusted to avoid potential conflicts with overline and underline decorations applied to the base text. In the basic case of consistent font size and baseline alignment, an underline or overline is positioned between the base level and any annotations on that side.

この節は、 隣接な［ 基底／注釈 ］を成す内容の合間に装飾を描くことについて，何らかの明確化が必要である。 それは、 それらの各~boxとそれが属する`~ruby~col$の幅広さが~~等しくなるかどうかに依存する。 ◎ This section needs some clarification about drawing decorations between the content of adjacent bases/annotations. Depends on if those boxes are as wide as their column or not.

5.1. 張出ng~ruby： `ruby-overhang^p ~prop

`ruby-overhang$p ~propは、 `~ruby注釈$が［ `~ruby容器$の外側にある隣接な~text ］に重合しても【すなわち，張出しても】よいかどうかを制御する。 各種 値の意味は： ◎ The ruby-overhang property controls whether ruby annotations may overlap adjacent text outside the ruby container. Values have the following meanings:

`~auto0@v

`~ruby注釈~容器$は、 対応する`~ruby基底~容器$より長くなるときは，隣接な~boxに部分的に重合してもヨイ。 ◎ When a ruby annotation container is longer than its corresponding ruby base container, the ruby annotation container may partially overlap adjacent boxes.

どの条件の下で，どれだけ張出すかは、 ~UAが決定する。 ◎ Whether, how much, and under which conditions to overhang are determined by the UA.

`none@v

`~ruby注釈~容器$は、 自身の外へ拡張することは，決して許容されない。 ◎ A ruby annotation container is never allowed to extend past the ruby annotation container.

`~ruby注釈$が張出すのは許容されないときには、 `~ruby容器$は，伝統的な`行内~box$の様に挙動する。 すなわち、 ~boxの境界の中に描画されるものは，~boxの自前の内容に限られ、 隣接な要素がその境界を超えて~~侵入することはない： ◎ When ruby annotations are not allowed to overhang, the ruby container behaves like a traditional inline box, i.e. only its own contents are rendered within its boundaries and adjacent elements do not cross the box boundary:

しかしながら，`~ruby注釈~容器$に張出nが許容される場合、 それが属する`~ruby容器$は，隣接している内容と重合してもヨイ — すなわち、 当の`~ruby注釈$（たち）を周囲の`行内~level$の内容の［ 上面／下面 ］に部分的に描画することも許容される。 張出nが許容されるのは、 隣接している内容と［ `~ruby注釈~容器$に属する`~ruby注釈~box$／重合した`~ruby基底$の内容 ］とが衝突しない所までに限られる。 ◎ However, if a ruby annotation container is allowed to overhang, neighbouring content may overlap the ruby container box, allowing its ruby annotation(s) to partially render over/under surrounding inline-level content. Overhang is only allowed to the extent that it does not cause collisions between the neighboring content and the ruby container’s annotation boxes or its overlapped base’s contents.

注記： ある`~ruby基底$に対応する`~ruby注釈$が別の`~ruby基底$に張出せるかどうかは、 `ruby-merge$p により制御される。 ◎ Note: Whether ruby annotations related to a ruby base can overhang another ruby base is controlled by ruby-merge.

［ 基底／注釈 ］の内容の整列は、 概して，張出ngの挙動には影響されない — ［ 整列／間隔の分布 ］（ `ruby-align$p を見よ）は、 張出nが許容されるかどうかに関わらず，同じ仕方で達成され、 重合するために可用な間隔を決定する前に算出される。 しかしながら，~UAは、 張出nが許容される所では，それを考慮する下で［ 注釈や基底における間隔の分布／ 注釈と基底どうしの整列 ］を決定してもヨイ。 ◎ Typically, the alignment of the contents of the base or the annotation is not affected by overhanging behavior: alignment and space distribution (see ruby-align) is achieved the same way regardless of the overhang allowance, and is computed before the space available for overlap is determined. However, UAs may consider allowed overhang when determining space distribution and/or alignment of annotations and bases.

編集者は、 一部の事例では，張出ngが整列と相互作用する必要もあると疑っている — 要検討。 ◎ I suspect overhanging interacts with alignment in some cases; might need to look into this later.

~UAは、 張出す長さの最大として， `JIS4051$r により推奨される `0.5ic$v （~~全角~文字の半分）を利用してよい。 日本語において，［ ~ruby~textが隣接な文字に どう張出せるか ］についての詳細な規則は、 `JLREQ$r に述べられる。 ◎ The user agent may use [JIS4051] recommendation of using 0.5ic (half of a full-width character) in the annotation’s font as the maximum overhang length. Detailed rules for how ruby text can overhang adjacent characters for Japanese are described by [JLREQ].

5.2. 行l端~辺における整列

`~ruby基底$より長い`~ruby注釈~box$が，行lの［ 始端／終端 ］辺を超えるときは、 ~UAは行lの辺に触れる側の `~ruby注釈$を基底の対応する辺に整列するように`強制してもヨイ^em。 この型の整列は、 `JLREQ$r にて述べられている。 ◎ When a ruby annotation box that is longer than its ruby base is at the start or end edge of a line, the user agent may force the side of the ruby annotation that touches the edge of the line to align to the corresponding edge of the base. This type of alignment is described by [JLREQ].

この挙動を制御する仕組みは、 この~levelの仕様では供されない。 ◎ This level of the specification does not provide a mechanism to control this behavior.

A.1. 既定の~UA~stylesheet

~HTML／~XHTML による~ruby~markupを~ruby~layoutとして描画するための 既定の~UA~stylesheetは、 次で表現される： ◎ The following represents a default UA style sheet for rendering HTML and XHTML ruby markup as ruby layout:

ruby { display: ruby; }
rp   { display: none; }
rbc  { display: ruby-base-container; }
rtc  { display: ruby-text-container; }
rb   { display: ruby-base; white-space: nowrap; }
rt   { display: ruby-text; }
ruby, rb, rt, rbc, rtc { unicode-bidi: isolate; }

rtc, rt {
  font-variant-east-asian: ruby;  /* 
`CSS-FONTS-3^r を見よ
◎
See [[CSS-FONTS-3]]
 */
  text-justify: ruby;             /* 
`CSS-TEXT-4^r を見よ
◎
See [[CSS-TEXT-4]]
 */
  text-emphasis: none;            /* 
`CSS-TEXT-DECOR-3^r を見よ
◎
See [[CSS-TEXT-DECOR-3]]
 */
  white-space: nowrap;
  line-height: 1;
}

rtc, :not(rtc) > rt {
  font-size: 50%;
}
rtc:lang(zh-TW),
:not(rtc) > rt:lang(zh-TW),
rtc:lang(zh-Hanb),
:not(rtc) > rt:lang(zh-Hanb) {
  font-size: 30%;                /* `注音符号$ */
}

【 存在しない言語~tag "zh-Hanb" は "zh-Hant" の誤記と思われる （ § 変更点には "zh-Hant" と記されているので、 "zh-Hans" の誤記ではないであろう）。 】

注記： 作者は、 上の規則を利用するべきでない — ~ruby~layoutを~supportする~UAは、 上の規則を既定で供するべきである。 ◎ Note: Authors should not use the above rules: a UA that supports ruby layout should provide these by default.

利用者が “最小~font~size” を制御できる特能を実装している~UAは、 ~ruby注釈~用の最小を縮小することも考慮するベキである。 ◎ UAs implementing a user-controlled “minimum font size” feature should consider scaling that minimum down for ruby annotations.

A.2. ~ruby注釈の行内~化法

~HTML／~XHTML による~ruby~markupを~inline注釈として描画するための 見本~stylesheetは、 次で表現される: ◎ The following represents a sample style sheet for rendering HTML and XHTML ruby markup as inline annotations:

ruby, rb, rt, rbc, rtc, rp {
  display: inline;
  white-space: inherit;
  font: inherit;
  text-emphasis: inherit;
}

A.3. 丸括弧の生成-法

あいにく，選択子は~text~nodeには合致し得ないので、［ ~HTMLにおいてアリな，どの~ruby~markup~patternに対しても、 丸括弧を伴わない~ruby注釈に，丸括弧を自動的かつ正しく追加する ］ための規則を~CSSで表出することはアリでない （このことは、 ~HTMLの~rubyでは，［ 対応する要素が無い生の~textが`~ruby基底$を含意する ］ことも許容されるためである）。 ◎ Unfortunately, because Selectors cannot match against text nodes, it’s not possible with CSS to express rules that will automatically and correctly add parentheses to unparenthesized ruby annotations for all possible ruby markup patterns in HTML. (This is because HTML ruby allows implying the ruby base from raw text without a corresponding element.)

しかしながら，［ `rb^e ／ `rtc^e ］が厳格に利用されている事例に対しては、 次の規則が，各~注釈~並びの前後に丸括弧を追加することになる。 ◎ However, these rules will add parentheses around each annotation sequence in cases where either <rb> or <rtc> is used rigorously:

/* 
`rtc^e の前後に丸括弧を追加する
◎
Parens around <rtc>
 */
rtc::before { content: "（"; }
rtc::after  { content: "）"; }

/* 
最初の `rt^e の前に丸括弧を追加する
— `rtc^e の内側ではなく
◎
Parens before first <rt> not inside <rtc>
 */
rb  + rt::before,
rtc + rt::before { content: "（"; }

/* 
`rt^e の後に丸括弧を追加する
— `rtc^e の内側ではなく
◎
Parens after <rt> not inside <rtc>
 */
rb ~ rt:last-child::after,
rt + rb::before  { content: "）"; }
rt + rtc::before { content: "）（"; }

別法として、 ~markupが純粋に交互に挟まれる~styleで利用されていて （例： `<ruby>A<rt>a</rt>B<rt>b</rt>C<rt>c</rt><ruby>^c ）， 隣接な~ruby注釈は無いことが既知な場合、 次の規則が，各~注釈の前後に丸括弧を追加することになる： ◎ Alternatively, if it is known that a purely alternating style of markup is used (<ruby>A<rt>a</rt>B<rt>b</rt>C<rt>c</rt><ruby>) where there are no adjacent ruby annotations, the following rules will add parentheses around each annotation:

/* 
各 `rt^e の前後に丸括弧を追加する
◎
Parens around each <rt>
 */
rt::before { content: "（"; }
rt::after  { content: "）"; }