1. 序論
~INFORMATIVE1.1. ~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 疑似要素には適用されない。 ◎ None of the properties in this module apply to the ::first-line or ::first-letter pseudo-elements.
1.2. 値
【 この節の内容は CSS 日本語訳 共通ページ に委譲 】
1.3. 図式の表記規約
東Asiaの~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 ◎ alt= Symbolic wide-cell glyph representation
- これは、~text連なり内の 4 個目の文字を指す,全角~glyphを表す(例: `漢字$)。 全角~glyphとして描画される文字は、このように漢数字で表される。 ◎ Wide-cell glyph (e.g. Han) that is the nth character in the text run. They are typically sized to 50% when used as annotations.
- `4^xH ◎ alt= Symbolic narrow-cell glyph representation
- これは、~text連なり内の 4 個目の文字を指す,半角~glyphを表す(例: ~roman )。 半角~glyphとして描画される文字は、このように洋数字で表される。 ◎ Narrow-cell glyph (e.g. Roman) which is the nth glyph in the text run.
いずれも,注釈においては、概して,基底の~~半分~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 ]を意味するようにも見受けられる)。 が、原文でも説明されていないので,深く立ち入らないことにする。 】
1.4. ~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.
次の例では、単独の注釈を利用して基底~textを注釈している。 ◎ In this first example, a single annotation is used to annotate the base text.
ラ イ セ ン ス | ← ~ruby~text |
利用許諾 | ← ~ruby基底 |
日本語~typographyでは、これは,[ 対語~ruby/~group~ruby(単語~~単位の~ruby) ]と呼ばれることもある — 当の注釈は、一体として,複-文字からなる単語に結付けられているので。 ◎ In Japanese typography, this case is sometimes called taigo ruby or group-ruby (per-word ruby), because the annotation as a whole is associated with multi-character word (as a whole).
次の例では、基底~並びに 2 個の~levelの注釈が添付けられている。 上端にある`平仮名$による文字たちは,基底を成す各 `日本漢字$の発音を示している一方で、下端にある単語[ “`Keio^en” , “`University^en” ]は,英語~翻訳を述べている注釈である。 ◎ In this second example, two levels of annotations are attached to a base sequence: the hiragana characters on top refer to the pronunciation of each of the base kanji characters, while the words “Keio” and “University” on the bottom are annotations describing the English translation.
`平仮名$からなる注釈の各 文字~並びと, 対応する`日本漢字$からなる基底~textの各 文字とが, 【表示において】 正しく結付けられるようにするため、これらの日本漢字の各~合間の間隔は調整されていることに注目(上の図では、 4 個目の日本漢字の前後に生じている)。 上の例で,`平仮名$が成す`注釈を畳む$ように~styleをアテガえば、日本漢字たちの各~合間の間隔が可変になるのを避けれる — それは、先に示した~group~rubyの例に似た見かけにするが、~ruby構造~内には,( 基底, 注釈 ) の各~pair法が記録されるので、~textが複数~行lに分断される場合でも,注釈~文字は,対応する基底~文字と正しく~pairになるように~~位置する。 ◎ Notice that to allow correct association between the hiragana characters and their corresponding Kanji base characters, the spacing between these Kanji characters is adjusted. (This happens around the fourth Kanji character in the figure above.) To avoid variable spacing between the Kanji characters in the example above the hiragana annotations can be styled as a collapsed annotation, which will look more like the group-ruby example earlier. However because the base-annotation pairings are recorded in the ruby structure, if the text breaks across lines, the annotation characters will stay correctly paired with their respective base characters.
日本語に利用される`~ruby$整形は、 JIS X-4051 `JIS4051$r (日本語), および Requirements for Japanese Text Layout `JLREQ$r (日本語~版は “日本語組版処理の~~要件” )に述べられる。 ~HTMLにおいては、~ruby構造とそれを表現する~markupは, Ruby Markup Extension 仕様にて述べられる。 この~moduleは、そのような~markupの~ruby~layoutに関連する,~CSSによる描画~modelと整形~制御について述べる。 ◎ Ruby formatting as used in Japanese is described in JIS X-4051 [JIS4051] (in Japanese) and in Requirements for Japanese Text Layout [JLREQ] (in English and Japanese)]. 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.
2. ~ruby~box~model
~CSS~ruby~modelは、 W3C HTML5 Ruby Markup ~model, XHTML Ruby Annotation Recommendation `RUBY$r に基づく。 この~modelにおける~ruby構造は、次のものからなる: ◎ The CSS ruby model is based on the W3C HTML5 Ruby Markup model and the XHTML Ruby Annotation Recommendation [RUBY]. In this model, a ruby structure consists of\
- 基底~text(注釈が付与される~text)を表現する, 1 個以上の[ `~ruby基底$を指示する要素 ]。 ◎ one or more ruby base elements representing the base (annotated) text,\
- それぞれが基底~textに結付けられる注釈を表現する, 1 個以上の~level — 各~levelは, 1 個以上の[ `~ruby注釈$を指示する要素 ]からなる。 ◎ associated with one or more levels of ruby annotation elements representing the annotations.\
~rubyの構造は、~tableのそれに類似する: そこには、一連の “~row” (`基底~level$の~text, および各 `注釈~level$)と, 一連の “~col” (各 `~ruby基底$と,それに対応する[ 各~levelに属する`~ruby注釈$ ])がある。 ◎ The structure of ruby is similar to that of a table: there are “rows” (the base text level, each annotation level) and “columns” (each ruby base and its corresponding ruby annotations).
連続する[ 基底たちと注釈たち ]は、`~ruby区分$の中に一緒に~group化される。 `~ruby区分$の中では、`~ruby注釈$は,複数の`~ruby基底$に`~span$することもある。 ◎ Consecutive bases and annotations are grouped together into ruby segments. Within a ruby segment, a ruby annotation may span multiple ruby bases.
注記: ~HTMLにおいては、単独の `ruby^e 要素が,複数の`~ruby区分$を包含することもある。 ( XHTML Ruby ~modelでは、単独の `ruby^e 要素が包含し得る`~ruby区分$は, 1 個だけである。) ◎ In HTML, a single <ruby> element may contain multiple ruby segments. (In the XHTML Ruby model, a single <ruby> element can only contain one ruby segment.)
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$v | `ruby-base$v | `ruby-text$v | `ruby-base-container$v | `ruby-text-container$v ◎表終次に挙げる新たな `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では廃されているので, `rbc^e と同様に,~HTMLにおいては,匿名~boxとして生成されることになる(この仕様に現れる “XHTML” は、 ~XML構文を利用する~HTMLではなく,過去に策定された方の仕様を指す)。 】
専用の~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.1.1. ~ruby整形~文脈
`~ruby容器$は、`可分な行内level$の~boxである。 それは、行内~boxの様に複数~行lに分断され得る。 また,その包含塊は、先祖の, 最も近傍の`塊~容器$である。 また、行内~boxの内容が[ 行内~boxを包含する同じ`行内~整形~文脈$ ]に関与するのと同じく,`~ruby容器$とその`基底~level$の内容は[ `~ruby容器$を包含する同じ`行内~整形~文脈$ ]に関与する。 ◎ Ruby containers are non-atomic inline-level boxes. Like inline boxes, they break across lines, and their containing block is the nearest block container ancestor. And just as the contents of an inline box participate in the same inline formatting context that contains the inline box itself, a ruby container and its base-level contents participate in the same inline formatting context that contains the ruby container itself.
しかしながら,`~ruby容器$はまた、 `~ruby整形~文脈@ も確立する — すなわち、[ `行内~整形~文脈$内の一~区分である,自身 ]の周りに,更なる構造を築く。 `内部~table要素$と同様に、[ `~ruby基底$/`~ruby注釈$/`~ruby基底~容器$/`~ruby注釈~容器$ ]は, `内部~ruby~box@ と総称される — これらは、~ruby~layoutにおいて特有の役割を有し,`~ruby容器$の`~ruby整形~文脈$に関与する。 ◎ However ruby containers also establish a ruby formatting context that builds further structure around their segment of the inline formatting context. Ruby bases, ruby annotations, ruby base containers, and ruby annotation containers are internal ruby boxes: like internal table elements, they have specific roles in ruby layout, and participate in their ruby container’s ruby formatting context.
行内~boxの内容と同様に、`~ruby容器$の内容(および,その すべての`内部~ruby~box$)用の包含塊は,~ruby容器の包含塊になる。 よって,例えば浮動体を囲い込むのは、各種~ruby~box型ではなく,~ruby容器の包含塊になる。 ◎ As with the contents of inline boxes, the containing block for the contents of a ruby container (and all its internal ruby boxes) is the containing block of the ruby container. So floats, for example, are trapped by the ruby container’s containing block, not any of the ruby box types.
内部~ruby~boxは行内levelなのか? ◎ Are internal ruby boxes inline-level?
2.1.2. 非~行内~ruby
要素の[ `内縁~表示~型$が `ruby$v,`外縁~表示~型$が `inline$v 以外 ]である場合、 2 個の~box — `外縁~表示~型$から要求される `主要~box$, および 【その中に】 行内levelの`~ruby容器$ — が生成されることになる。 要素~上に指定される~propは、すべて,`主要~box$に適用される(また,継承-可能であれば,`~ruby容器~box$にも継承される)。 これにより、要素を — その内部の~ruby構造は,正しく保守しつつ — 塊として~styleさせられる。 ◎ If an element has an inner display type of ruby and an outer display type other than inline, then it generates two boxes: a principal box of the required outer display type type, and an inline-level ruby container. All properties specified on the element apply to the principal box (and if inheritable, inherit to the ruby container box). This allows styling the element as a block, while correctly maintaining the internal ruby structure.
注記: [ 絶対~位置にされた/浮動された ]要素の`外縁~表示~型$は、`塊~化$される( `CSS-DISPLAY-3$r / `CSS2$r 9.7 節を見よ)。 `内部~ruby要素$( `内部~ruby~box$を生成させる要素 )用には、これにより算出される `display$p 値は `block$v になる。 ◎ Note that absolute positioning or floating an element causes its display value to compute to a block-level equivalent. (See [CSS-DISPLAY-3] or [CSS2] section 9.7.) For the internal ruby display types, this causes their display value to compute to block.
2.2. 匿名~ruby~boxの生成
~CSS~modelでは、文書~言語が,各種~ruby~boxのそれぞれに対応する要素を含むことは、要求されない。 文書~構造に欠けている部分に対しては、以下に与えられる, ~tableを正規化するときに利用される規則 に似た規則を通して、匿名~boxが暗黙に生成される。 `CSS2$r ◎ 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]
- 塊level~boxを`行内~化$する: ~flow内にある~boxに直に包含されている[ `~ruby容器$/`~ruby基底~容器$/`~ruby注釈~容器$/`~ruby基底~box$/`~ruby注釈~box$ ]は — 行内levelの内容のみを包含するよう — “`行内~化$” され、 `display$p 値はそれに則って算出される。 例えば,~flow内の要素が[ 自身の `display$p は `block^v にされていて,親の `display$p は `ruby-text$v にされている ]場合、要素の `display$p ~propは, `inline-block$v に算出される。 `CSS-DISPLAY-3$r ◎ Inlinify block-level boxes: 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.
-
匿名~ruby容器を生成する: 不適正に包含されている[ `~ruby基底~容器$/`~ruby注釈~容器$/`~ruby基底$/`~ruby注釈$ ](および介在する`空白$)からなる,連続する並びは、匿名`~ruby容器$内に包装する。 この段の目的においては、次のものが不適正に包含されているとされる: ◎ Generate anonymous ruby containers: 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
-
親が違えられた行内level内容を包装する: 連続する[ ~textや行内level~box ]からなる並びであって,その親が[ `~ruby容器$/`~ruby基底~容器$ ]であるものは、匿名`~ruby基底$内に包装する。 類似的に,連続する[ ~textや行内level~box ]からなる並びであって,その親が`~ruby注釈~容器$であるものは、匿名`~ruby注釈$内に包装される。 (この目的においては、親が違えられた`内部~table要素$は,`行内level$の内容として扱われる — 親が~ruby~boxにされるものは、最終的に行内~tableで包装されることになるので。) ◎ Wrap misparented inline-level content: 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. Similarly, any consecutive sequence of text and inline-level boxes directly parented by a ruby annotation container is wrapped in an anonymous ruby annotation. (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 table.)
ただし,そのように構築された匿名~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.
- 頭部/尾部にある空白を刈取る: `~ruby内 空白$のうち,親の唯一の子でない, かつ[ `~ruby容器$/`~ruby注釈~容器$/`~ruby基底~容器$ ]内の先頭や末尾に生じるものは、その `display$p が `none^v にされていたかのように除去する。 ◎ Trim leading/trailing white space: Any intra-ruby white space that is not the sole child of its parent and occurs at the beginning or end of a ruby container, ruby annotation container, or ruby base container is removed, as if it had display: none
-
他の`~ruby内 空白$は、その直前, 直後の同胞~box( `~ruby基底$/`~ruby注釈$/`~ruby基底~容器$/`~ruby注釈~容器$ )に応じて,次の表に挙げる下位型に分類される:
直前の~box 直後の~box ~box型 下位型 任意 `~ruby注釈~容器$ なし `~level間 空白@ `~ruby注釈$でない `~ruby注釈$ なし 同上 `~ruby注釈$ `~ruby注釈$ `~ruby注釈$ `注釈~間 空白@ `~ruby基底$ `~ruby基底$ `~ruby基底$ `基底~間 空白@ 上に挙げたもの以外の任意の組み合わせ `~ruby基底$ `区分~間 空白@ これらのうち,`~level間 空白$以外のものは、 `~level内 空白@ と総称される。
◎ ↓ - `~level間 空白$を除去する: `~level間 空白$は、 `display$p が `none^v にされていたかのように除去する。 ◎ Remove inter-level white space: Any intra-ruby white space whose immediately adjacent 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
- `~level内 空白$を解釈する: `~level内 空白$には、上の表に示した対応する~box型をアテガう — これらは、~pair法と~layoutにおいては,後述するように特別に扱われる。 ◎ Interpret intra-level white space: Any intra-ruby white space box whose immediately adjacent 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.
-
行l分断を抑止する: `~ruby注釈$の内側にあるすべての`強制~行l分断$は、`縮約-可能$な`区分~分断$として, 区分~分断の~~変換~規則 `CSS3TEXT$r による定義に従って変換する( `white-space$p 値に関わらず)。 ◎ Suppress line breaks: 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.
-
匿名~level容器を生成する:
- 連続する[ `~ruby基底$/`基底~間 空白$ ]からなる並びであって,親は`~ruby基底~容器$でないものは、匿名`~ruby基底~容器$内に包装する。
- 連続する[ `~ruby注釈$/`注釈~間 空白$ ]からなる並びであって,親は`~ruby注釈~容器$でないものは、匿名`~ruby注釈~容器$内に包装する。
この図式 を例に取り込む。 ◎ Make this diagram into an example.
この節の規則により,~ruby~layout構造~内の親子関係がすべて適正にされたなら、~UAは,基底とそれらの注釈とを結付けることになる。 ◎ Once all ruby layout structures are properly parented, the UA can start to associate bases with their annotations.
注記: ~UAには、これらの匿名~box(および, ~pair法~節 による[ 匿名かつ空の`~level内 空白$ ~box ])を,~~実際に内部~構造に作成することは要求されない — ~pair法と~layoutが,それらが存在するかのように挙動する限り。 ◎ Note that the UA is not required to create any of these anonymous boxes (or the anonymous empty intra-level white space boxes in the pairing section) in its internal structures, as long as pairing and layout behaves as if they existed.
2.3. 注釈の~pair法
注釈の `~pair法@ は、`~ruby注釈$たちと`~ruby基底$たちとを結付ける処理-である: ◎ 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 is 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.
~pair法が完了したなら、~ruby “~col” 単位が定義される — そのそれぞれは、`~ruby区分$内の[ 1 個の`~ruby基底$と, [ 各`注釈~level$ごとに それに属する 1 個の(場合によっては匿名かつ空の)`~ruby注釈$ ]]で表現される。 ◎ Once pairing is complete, ruby “column” units are defined, each represented by a single ruby base and one ruby annotation (possibly an empty, anonymous one) from each annotation level in its ruby segment.
2.3.1. 区分の~pair法と注釈~level
~ruby構造は、いくつかの `~ruby区分@ に分割される — 各`~ruby区分$は、次のものからなる:
- 先頭の`~ruby基底~容器$。 それは、`~ruby区分$の `基底~level@ を表現する。
-
後続する 1 個以上の`~ruby注釈~容器$ — そのそれぞれは:
- 基底~text用のある 1 つの `~level@ を成す注釈を表現する — `N^V 個目のそれは、 `N^V 個目の~levelを成す注釈を表現する。
- `基底~level$の`~ruby基底~容器$と~pairにされる。
退化した事例を取扱うため、次のような,匿名かつ空の容器が存在するものと見做される: ◎ In order to handle degenerate cases, some empty anonymous containers are assumed:
- `~ruby容器$の最初の子が`~ruby注釈~容器$である場合、その前に,匿名かつ空の`~ruby基底~容器$が存在するものと見做される。 ◎ If the first child of a ruby container is a ruby annotation container, an anonymous, empty ruby base container is assumed to exist before it.
- `~ruby容器$が 連続する複数の`~ruby基底~容器$を包含する場合、それらの各~合間に,匿名かつ空の`~ruby注釈~容器$が存在するものと見做される。 ◎ Similarly, if the ruby container contains consecutive ruby base containers, anonymous, empty ruby annotation containers are assumed to exist between them.
`区分~間 空白$は、実質的に,自前の`~ruby区分$を成す。 ◎ Inter-segment white space is effectively a ruby segment of its own.
2.3.2. 単位ごとの~pair法, 複数の基底に~spanする注釈
`~ruby区分$の中では、`~ruby基底~容器$内の各`~ruby基底$は、同じ`~ruby区分$内の各`~ruby注釈~容器$に属する 1 個の`~ruby注釈$と,~pairにされる。 ◎ Within a ruby segment, each ruby base in the ruby base container is paired with one ruby annotation from each ruby annotation container in its ruby segment.
`~ruby注釈~容器$が単独の, 匿名`~ruby注釈$のみを包含する場合、その`~ruby注釈$は,その`~ruby区分$内のすべての`~ruby基底$と~pairにされる(すなわち,それらに`~span$する)。 ◎ If a ruby annotation container contains only a single, anonymous ruby annotation, then that ruby annotation is paired with (i.e. spans across) all of the ruby bases in its ruby segment.
他の場合、各`~ruby注釈$と, その区分~内の対応する`~ruby基底$とが、順に~pairにされる。 ~ruby注釈と~ruby基底の個数が一致しない場合:
- 対応する`~ruby注釈$がない`~ruby基底$は、[ `~ruby注釈~容器$の末尾に挿入される,匿名かつ空の注釈 ]と~pairにされる。
- 対応する`~ruby基底$がない`~ruby注釈$は、[ `~ruby基底~容器$の末尾に挿入される,匿名かつ空の基底 ]と~pairにされる。
複数の基底に明示的に~spanさせる~ruby~markup(例: XHTML Complex Ruby Annotations )を~supportする実装は、そのような各~注釈と, それが`~span$している基底たちとが~pairにされるように,~pair法~規則を適切に調整し~MUST。 ◎ If an implementation supports ruby markup with explicit spanning (e.g. XHTML Complex Ruby Annotations), it must adjust the pairing rules to pair spanning annotations to their bases appropriately.
`~level内 空白$は、注釈に対する標準の`~pair法$には関与しない — ただし:
- `~level内 空白$を挟んで隣接する[ 2 個の`~ruby基底$ / 2 個の`~ruby注釈$ ]が[ 2 個の`~ruby注釈$ / 2 個の`~ruby基底$ ]と~pairにされている下では、その空白も,後者の 2 個に挟まれた`~level内 空白$ — 無いならば、匿名かつ空の`~level内 空白$~boxが存在するものと見做す — と~pairにされる。
- `~level内 空白$を挟んで隣接する 2 個の`~ruby基底$が,同じ`~ruby注釈$と~pairにされている下では(注釈は それらの基底に`~span$している)、その空白も,その~ruby注釈と~pairにされる。
図式を挿入する。 ◎ Insert diagram
2.3.3. 入子の~rubyを伴う複雑な~span法
`~ruby容器$が `入子に@ されたときの~pair法は、最も深い`~ruby容器$から始まり,外へ拡がる。 外縁`~ruby容器$の~pair法の視点からは、その中に入子にされた各`~ruby容器$は、~levelごとに単独の[ `~ruby基底$ /`~ruby注釈$ ]を表現しているものと数えられる。 したがって、[ 外縁`~ruby容器$を成す`~ruby注釈$のうち,ある`入子の~ruby$と~pairにされているもの ]たちは,[ その入子にされた`~ruby容器$を成す`~ruby基底$すべて ]と~pairにされる(それらに`~span$する)。 入子にされた`~ruby容器$内の各`~ruby注釈~容器$は、[ 自身と同じ`注釈~level$の,外縁`~ruby容器$における`~ruby注釈~容器$ ]の一部を占め,[ 外縁`~ruby容器$内に直に包含されていた ]かのように~layoutに関与する。 ◎ When ruby containers are nested, pairing begins with the deepest ruby container, then expands out. From the pairing perspective of the outer ruby container, each ruby container nested within another ruby container counts as representing a single ruby base/annotation per level. The outer ruby container’s ruby annotations paired to the nested ruby are therefore paired with (and span) all of the nested ruby container’s ruby bases. Each ruby annotation container in the nested ruby container occupies the same annotation level in the outer ruby container as it does in the inner one and participates in its layout as if it were directly contained in the outer ruby container.
この処理-は再帰的である。 したがって,入子の`~ruby容器$の利用すれば、複雑な~span法の関係性を表現できるようになる。 ◎ This process is recursive. Thus, using nested ruby containers allows the representation of complex spanning relationships.
これが,~ruby基底たちの内側にある~ruby容器に対する~layoutの取扱いから外されるのか,特別に取扱われる必要があるどうかは、明らかでない。 見出すための~layoutがより良く定義されるまで,待っている所にある… ◎ It’s not clear whether this falls out of layout handling of ruby containers inside ruby bases or needs to be handled specially. Waiting until layout is better-defined to find out...
2.4. 基底と一致する注釈を自動で隠す法
`~ruby注釈$の~text内容が それの基底と正確に同じである場合、それは `隠され@ る。 `~ruby注釈$を隠すことは、[ 注釈の~pair法 / 他の`~level$における~boxの塊-軸~沿いの位置決め ]には影響しない。 しかしながら,`隠され$た注釈は、可視にならず,[ 同~levelの中で隣接する`~ruby注釈~box$の並びを分離する ]以外には,~layoutに波及しない — それが別々の区分に所属していて,[ `隠され$た注釈の基底は`~ruby基底$ではなく介在する行内であった ]かのように。 ◎ If a ruby annotation has the exact same text content as its base, it is hidden. Hiding a ruby annotation does not affect annotation pairing or the block-axis positioning of boxes in other levels. 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.
このことは、`日本漢字$と`平仮名$が混在する日本語~単語~用の注釈の表示を,正しく行内~化できるようにするためにある。 例えば、単語 "振仮名" は、次のように行内~化されるべきである: ◎ This is to allow correct inlined display of annotations for Japanese words that are a mix of kanji and hiragana. For example, the word 振り仮名 should be inlined as
したがって、次のように~mark-upされる: ◎ and therefore marked up as
`furigana-separate^xCodeしかしながら,~rubyとして表示されるときは、 “り” は,`隠され$るべきである。 ◎ However, when displayed as ruby, the “り” should be hidden
`ruby-merge$p の算出値が `collapse$v になる場合、自動で隠すのは不能化される。 `ruby-merge$p の算出値が `auto$v になる場合,~UAは自動で隠すかどうか決めて~MAYが、~UAが選んだ~algoが `separate$v が生産する結果と類似するものを生産する場合には,自動で隠すことが推奨される。 ◎ When the computed value of ruby-merge is collapse, the autohiding is disabled. When the computed value of ruby-merge is auto, the user agent may decide whether to autohide or not, but it is recommended to autohide if the algorithm the user agent chose produces the results similar to separate would produce.
この自動で隠す挙動~用の内容~比較は、[ ( `white-space$p による)空白の縮約-法 / ( `text-transform$p による)~text変形 ]よりも先に行われ,要素は無視される(~boxの `textContent^c のみを考慮する)。 ◎ The content comparison for this auto-hiding behavior 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では常に強制される。 ◎ Future levels of CSS Ruby may add controls for auto-hiding, but in this level it is always forced.
2.5. 空白の縮約-法
~ruby構造の中の空白のうち,次のいずれかに該当するものは、 破棄される: ◎ White space within a ruby structure is discarded
- [ `~ruby容器$ / `~ruby注釈~容器$ / `~ruby基底~容器$ ]の先頭や末尾にあるもの。 ◎ at the beginning and end of a ruby container, ruby annotation container, or ruby base container,
- `~ruby基底~容器$と, それに後続する`~ruby注釈~容器$との合間にあるもの。 ◎ between a ruby base container and its following ruby annotation container,
- `~ruby注釈~容器$たちの各~合間にあるもの。 ◎ between ruby annotation containers.
例えば,次の~markupは、間隔を伴わずに表示されることになる: ◎ For example, the following markup will display without any spaces:
`tokyo^xCodeしかしながら,[ `~ruby区分$たちの各~合間 / `~ruby基底$たちの各~合間 / `~ruby注釈$たちの各~合間 ]では、空白は破棄されず,[ `区分~間 空白$ / `基底~間 空白$ / `注釈~間 空白$ ]として描画するために保守される(匿名~ruby~boxの生成節を見よ)。 ◎ 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 Anonymous Ruby Box Generation, above.)
空白を保全する規則により、~Latinなどの~spaceで分離される用字系にも,~rubyを利用できるようになる。 例えば: ◎ The rules preserving white space allow ruby to be used with space-separated scripts such as Latin. For example,
`WWW^xCodeそれはまた、注釈付き空白も保全されることを確保する。 例えば: ◎ They also ensure that annotated white space is preserved. For example,
`Gainsboro^xCode破棄されない空白が`縮約-可能$になる所では、標準の`空白~処理~規則$ `CSS3TEXT$r に従って縮約することになる。 しかしながら,`~ruby区分$たちの合間にある`縮約-可能$な空白(`区分~間 空白$)用には、[ 縮約するときの挙動を決定するための文脈的~text ]は,両~側にある`~ruby基底$により与えられる — ~source文書~順序における空白の両~側にある~textではなく。 ◎ Where undiscarded white space is collapsible, it will collapse following the standard white space processing rules. [CSS3TEXT] For collapsible white space between ruby segments (inter-segment white space), however, the contextual text for determining collapsing behavior is given by the ruby bases on either side, not the text on either side of the white space in source document order.
`空白~処理~規則$では、`区分~分断$( `line feed^en など)を包含している空白~並びは,[ `漢字$, および`仮名$ ]文字たちの合間では, 無に縮約される。 これは、[ 中国語/日本語 ]~rubyでは、~ruby~markupの字下げに,空白を安全に利用できることを意味する。 例えば,次の~markupは、間隔を伴わずに表示されることになる: ◎ Note that the white space processing rules cause a white space sequence containing a segment break (such as a line feed) to collapse to nothing between Han and Kana characters. This means that Chinese and Japanese ruby can safely use white space for indentation of ruby markup. For example, the following markup will display without any spaces:
`nosmoke-1^xCodeしかしながら、`区分~分断$を包含しない空白は,完全には縮約しないので、次の~markupは, 1 個目と 2 個目の~ruby~pairの合間に間隔を伴って表示されることになる: ◎ However, white space that does not contain a segment break does not collapse completely away, so this markup will display with a space between the first and second ruby pairs:
`nosmoke-2^xCode3. ~ruby~layout
~ruby構造が~lay-outされるときは、それの`基底~level$は,[ それの`~ruby基底$たちが行内~boxたちの定例の並びであった ]かのように、当の行l上に~lay-outされた上で,それの `vertical-align$p ~propに正確に則って整列される。 各`~ruby基底~容器$は、それの各`~ruby基底$の~margin~boxすべてを正確に包含するように,~sizeされ位置される。 ◎ When a ruby structure is laid out, its base level is laid out on the line, aligned according to its vertical-align property exactly as if its ruby bases were a regular sequence of inline boxes. Each ruby base container is sized and positioned to contain exactly all of its ruby bases’ margin boxes.
次に、`基底~level$に結付けられている各`~ruby注釈$が, 適用-可能な `ruby-position$p 値に則って,それぞれの`~ruby基底~box$を基準に位置される。 ある~levelの中の(単独の`~ruby容器$の中の) `~ruby注釈$たちは、[ それらが同じ`行内~整形~文脈$に関与している行内~boxたち ]であったかのように,互いに整列される。 各`~ruby注釈~容器$は、各`~ruby注釈$の~margin~boxをすべてを正確に包含するように,~sizeされ位置される。 ◎ Ruby annotations associated with the base level are then positioned with respect to their ruby base boxes according to the applicable ruby-position values. Ruby annotations within a level (within a single ruby container) are aligned to each other as if they were inline boxes participating in the same inline formatting context. Each ruby annotation container is sized and positioned to contain exactly all of its ruby annotations’ margin boxes.
各`~ruby注釈~容器$は、対応する`~ruby基底~容器$の 上面/下面 から外方へ,介在する間隔を伴わずに堆積される。 ◎ Ruby annotation containers are stacked outward over or under their corresponding ruby base container, without any intervening space.
塊-軸~marginは縮約するべきか? これは,~layoutをより堅牢にするが、行内-軸~沿いにおける行内の挙動と一貫しなくなる。 ◎ Should block-axis margins collapse? This makes layout more robust, but is inconsistent with how inlines behave along the inline-axis.
~ruby容器(または それの断片)は、それの最も幅広な~levelの内容と同じ幅広に計測される。 類似的に,~ruby “~col” の中の[ `~ruby基底~box$/`~ruby注釈~box$ ]たちは、その “~col” 内の最も幅広な内容に計測される。 複数の基底に`~span$している注釈に対しては(実際に複数の基底に`~span$しているか, `ruby-merge$p により~spanするように装っているかを問わず)、[ それを成す`~ruby注釈~box$たち, そのそれぞれを結付けている`~ruby基底~box$たち ]の計測結果の総和は,合致し~MUST。 ◎ A ruby container (or fragment thereof) measures as wide as the content of its widest level. Similarly, ruby base boxes and ruby annotation boxes within a ruby “column” have the measure of the widest content in that “column”. In the case of spanning annotations (whether actually spanning or pretending to span per ruby-merge), the measures of the ruby annotation box and the sum of its associated ruby base boxes must match.
~ruby内容がそれを成す~boxの計測結果より狭小なときに 余分の間隔を分布する方法は、 `ruby-align$p ~propにより指定される。 ◎ How the extra space is distributed when ruby content is narrower than the measure of its box is specified by the ruby-align property.
~ruby[ 基底/注釈 ]たちの~sizeは、~colか内容のどっちに合わせるべきか? ◎ Should the ruby bases and annotations size to the column, or size to the content?
3.1. 文字~間~rubyの~layout
文字~間の注釈の~layoutは特別になる。 `ruby-position$p が `inter-character$v 注釈を指示する場合、影響される`~ruby注釈~box$たちは,継合され, `基底~level$の~layoutの一部として計測される。 当の`~ruby基底~容器$は、[ `~ruby基底~box$たち, および `inter-character$v `~ruby注釈~box$たち ]の両者を含むように~sizeされ~MUST。 類似的に、影響される`~ruby注釈~容器$は,それの内容~boxが`~ruby基底~容器$のそれと一致するように~sizeされる。 ◎ Inter-character annotations have special layout. When ruby-position indicates inter-character annotations, the affected ruby annotation boxes are spliced into and measured as part of the layout of the base level. The ruby base container must be sized to include both the ruby base boxes as well as the inter-character ruby annotation boxes. The affected ruby annotation container is similarly sized so that its content box coincides with that of the ruby base container.
他の~levelたちの注釈たちを~lay-outする目的においては、 `inter-character$v 注釈は、実質的に,それの基底の一部になる。 あるいは、 2 つの基底の合間の “準” 基底になるべきか? `inter-character$v 注釈は、それが`~span$しているどの基底よりも後に配置される。 ◎ For the purpose of laying out other levels of annotations, an inter-character annotation effectively becomes part of its base. Or should it become a quasi-base between two bases? A spanning inter-character annotation is placed after all the bases that it spans.
3.2. ~ruby~boxの~style法
~ruby~boxは、ほとんどの面で行内~boxと類似的に~styleできる。 しかしながら,~UAには、[ `~ruby基底~容器~box$ / `~ruby注釈~容器~box$ / ~ruby内部の~ruby容器~box ]上では、次に挙げるものを~supportすることは要求されない:
- 各種 ~box~prop(~border, ~margin, ~padding)
- 各種 背景~prop /
- 各種 外形線~prop /
- ~当の~boxの境界部が~~露わになるような他の任意の~prop
~UAは、これらの~boxを単純に,その内容の~layoutに対する[ 継承と制御 ]用の抽象化として実装してよい。
◎ In most respects, ruby boxes can be styled similar to inline boxes. However, the UA is not required to support any of the box properties (borders, margins, padding), any of the background properties or outline properties, or any other property that illustrates the bounds of the box on ruby base container boxes, ruby annotation container boxes, or ruby-internal ruby container boxes. The UA may implement these boxes simply as abstractions for inheritance and control over the layout of their contents.3.3. 複数~行lへの分断-法
`~ruby容器$全体が 1 行lに収まり切らない, かつ すべての~levelが同時に分断を許容している場合、~rubyは,分断されてよい。 ~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. 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基底$たちと一緒であり続け~MUST。 行lは,`~ruby基底$とその`注釈$たちの合間で 分断されては~MUST_NOT — `inter-character$v `注釈$の事例においても。 ◎ 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.
3.3.1. 基底~間の分断-法
代表的な事例では、[ `~ruby基底~box$/`~ruby注釈~box$ ]には,内部の行l折返しを禁止するように~styleがアテガわれ、強制~分断は包含しない( 付録 A を見よ)。 そのような事例では、`~ruby容器$を分断できる所は、隣接する`~ruby基底$どうしの合間であって,かつ それら複数の`~ruby基底$に`~span$している`~ruby注釈$も無いときに限られる。 ◎ In typical cases, ruby base boxes and ruby annotation boxes are styled to forbid internal line wrapping and do not contain forced breaks. (See Appendix A.) In such cases the ruby container can only break between adjacent ruby bases, and only if no ruby annotations span those ruby bases.
~ruby~text(上面) | 行l分断ng機会 | ~ruby~text |
~ruby基底 | ~ruby基底 | |
~ruby~text(下面) | ~ruby~text |
隣接する 2 つの`~ruby基底$の合間で ~rubyを分断できるかどうかは、基底~text用の通常の`行-分断ng規則$により — 正確に[ 当の`~ruby基底$たちが隣接する行内~boxたちであった ]かのように — 制御される。 (注釈たちは、`基底~level$用の自動折返し機会を決定するときには無視される。) ◎ Whether ruby can break between two adjacent ruby bases is controlled by normal line-breaking rules for the base text, exactly as if the ruby bases were adjacent inline boxes. (The annotations are ignored when determining soft wrap opportunities for the base level.)
例えば、隣接する~ruby基底が[ “蝴”, “蝶” ]であったなら、行lは,それらの合間で分断されてよい , — 2 個の`漢字$文字の合間では,通常は行lを分断することが許容されるので。 しかしながら, `word-break$p が `keep-all$v である場合、その行l分断は禁止される。 ◎ For example, if two adjacent ruby bases are “蝴” and “蝶”, the line may break between them, because lines are normally allowed to break between two Han characters. However, if word-break is keep-all, that line break is forbidden.
`kocho^xCode`基底~間 空白$は、`~ruby基底$たちの各~合間にある行l分断~機会を評価するときには 有意になり,行l分断がそこにあるときには縮約される — 行内たちの各~合間にある空白と同様に。 類似的に、`注釈~間 空白$も行l分断の所で刈取られる。 ◎ Inter-base white space is significant for evaluating line break opportunities between ruby bases. As with white space between inlines, it collapses when the line breaks there. Similarly, annotation white space is also trimmed at a line break.
例えば、次の~markupが与えられたとき: ◎ For example, given the following markup:
`onetwo^xCode~spaceに因り,行lは[ “one”, “two“ ]の合間で分断されてよい。 行l分断がそこにある場合、その~space, および “1”, “2” の合間にある~spaceは、標準の~CSS`空白~処理~規則$に則って消去る。 `CSS3TEXT$r ◎ Due to the space, the line may break between “one” and “two“. If the line breaks there, that space—and the space between “1” and “2”—disappears, in accordance with standard CSS white space processing rules. [CSS3TEXT]
3.3.2. 基底たちの中での分断-法
より長い基底~text用には、 ( 基底, 注釈 ) ~pairの中でも分断ngを許容した方が,適切になることもある。 例えば,英文を日本語~翻訳で注釈する場合、~textを折返すのを許容した方が,段落における行l分断-法は適度に挙動するようになる。 ◎ For longer base texts, it is sometimes appropriate to allow breaking within a base-annotation pair. For example, if an English sentence is annotated with its Japanese translation, allowing the text to wrap allows for reasonable line breaking behavior in the paragraph.
読者が これを単なる仕様~策定者の世迷言と考えないよう,~~具体的な例を挿入する。 ◎ Insert scanned example so people don’t think this is just the ramblings of an insane spec-writer.
`~ruby基底$の中で`行-分断ng$が許容されるのは、[ `~ruby基底$, および それに並行する どの`注釈$の `white-space$p ~propも,それを許容する ], かつ各[ 基底~box/注釈~box ]の内容の中(すなわち,始端でも終端でもない)に`自動折返し機会$が存在する場合に限られる。 `~ruby基底$の内容を成す各~断片と`注釈$のそれらとの間には,構造上の対応関係はないので、~UAは,[ 基底の中, 注釈の中 ]の機会たちの どの~~組み合わせで分断してもよいが、各~断片における[ 基底の内容, 注釈の内容 ]が成す分量比が互いに近くなるよう試みることが推奨される。 ◎ Line-breaking within a ruby base is only allowed if the white-space property of the ruby base and all its parallel annotations allow it, and there exists a soft wrap opportunity within (i.e. not at the start or end) the content of each base/annotation box. Since there is no structural correspondence between fragments of content within ruby bases and annotations, the UA may break at any set of opportunities; but it is recommended that the UA attempt to proportionally balance the amount of content inside each fragment.
`inter-character$v `注釈$の中には、行l分断ng機会はない。 ◎ There are no line breaking opportunities within inter-character annotations.
各~断片の中における~ruby整列は、`行-分断ng$より後になる。 ◎ Ruby alignment takes place within each fragment, after line-breaking.
3.4. 双向~並替え
単独の段落の中で,方向性が互いに反対向きの 用字系に属する文字が混在する場合、 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 correspondance of ruby annotations to their respective ruby bases, a few restrictions must be imposed:
- [ `~ruby基底$/`~ruby注釈$ ]の内容の連続性は、保たれ~MUST。 ◎ The contents of a ruby base or ruby annotation must remain contiguous.
- `~ruby基底$と,対応する`~ruby注釈$たちとは、一緒に並替えられ~MUST。 ◎ Ruby annotations must be reordered together with their ruby bases.
- `~ruby注釈$が`~span$している`~ruby基底$たちの連続性は、保たれ~MUST。 ◎ All ruby bases spanned by a single ruby annotation must remain contiguous.
その結果: ◎ To this end,
-
双向~隔離は、[ すべての`内部~ruby~box$と, `~ruby容器$ ]に対し,強制される — すなわち, `unicode-bidi$p の算出値は、指定値に応じて,次のようになる ⇒# `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.
注記: このことは、[ 暗黙的な双向~並替えが,~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基底~容器$の `direction$p ~propにより,対応する容器の中で順序付けられる。
注記: このことは、`~ruby注釈~容器$上の `direction$p ~propは,~layoutの目的においては無視されることを意味する。 しかしながら,容器の子へは依然として継承できる — その結果,それが包含するどの`~ruby注釈$の`行内~基底~方向$にも影響する。
◎ Within a segment, ruby bases and ruby annotations are ordered within their respective containers by the direction property of the segment’s ruby base container. Note this means the direction property on ruby annotation containers is ignored for the purpose of layout. 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$の後に起こる — 内容が複数~行lに分割されるときには、自身の論理的~順序に則るようにするため。 ◎ 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.
~CSSにおける双方向的~textについての より深い論は `CSS3-WRITING-MODES$r を見よ。 ◎ See [CSS3-WRITING-MODES] for a more in-depth discussion of bidirectional text in CSS.
3.5. 行l間の間隔法
~CSSでは、 `line-height$p ~propが,各~行lの合間の間隔法を制御する。 ある行l上の行内~内容が `line-height$p より短いときは、 CSS2.1, 10.8 節 に指定されるように,内容の両~側に半-行間が追加される。 `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 CSS2.1§10.8. [CSS2]
各 行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基底~容器$の適切な側に行間が追加される。 ◎ 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 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間の間隔法がすべて等しい, かつ `~ruby注釈$たちの量と位置決めも互いに等価な場合に,重合するのを避けるに十分な部屋を確保するに過ぎない。 ◎ Note that 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 の一部になる。 それは現在,書き直しの過程にあり、現在の草案には依拠するべきでない。 ◎ 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 process of being rewritten; the current drafts should not be relied upon.
4. 各種~ruby整形~prop
~rubyの 位置決め, ~text分布, 整列 を制御するため、以下の各種~propが導入される。 ◎ The following properties are introduced to control ruby positioning, text distribution, and alignment.
4.1. ~rubyの位置決め: `ruby-position^p ~prop
◎名 `ruby-position@p ◎値 `over$v | `under$v | `inter-character$v ◎初 `over$v ◎適 ~ruby注釈~容器 ◎継 される ◎百 利用不可 ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終この~propは、~ruby~textの 基底から~~相対的な位置を制御する。 各種 値の意味は: ◎ This property controls position of the ruby text with respect to its base. Values have the following meanings:
`Roland Steiner^en 氏から,既定の値として `auto^v を加えることが要請されている。 `this thread, this one^en を見よ。 現在の提案は、省略可能な `alternate^v? ~keywordを追加する。 ◎ Issue-107: Roland Steiner has requested the addition of an auto value as default. See this thread and this one. Current proposal is to add an optional alternate? keyword.
- `over@v
- ~ruby~textは、基底の`行-上面$に現れる。 ◎ The ruby text appears line-over the base.
- `under@v
- ~ruby~textは、基底の`行-下面$に現れる。 表語的 東Asiaの書記体系で利用されるのは 相対的に稀な設定であり、教育用~textに最も見出され易い。 ◎ The ruby text 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~textは、横組み~textにおいては基底の右端に現れる。 この値は、`~ruby注釈~容器$の `writing-mode$p の算出値を `vertical-rl$v に強制する。 ◎ The ruby text appears on the right of the base in horizontal text. This value forces the computed value of writing-mode of the ruby annotation container to be vertical-rl.
- この値は、とりわけ台湾で利用されている,繁体字~中国語の特別な事例~用に供されている: その文脈においては — 基底~文字の~layoutが横組みのときでも — (`注音符号$用の~glyphたちからなる)~rubyは,基底~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注釈~容器$が同じ `ruby-position$p になる場合、それらは,`~level$がより低い注釈ほど 基底~textに近くなるように,塊~軸~沿いに堆積される。 ◎ If multiple ruby annotation containers have the same ruby-position, they stack along the block axis, with lower levels of annotation closer to the base text.
4.2. 注釈~間隔の共有-法: `ruby-merge^p ~prop
◎名 `ruby-merge@p ◎値 `separate$v | `collapse$v | `auto$v ◎初 `separate$v ◎適 `~ruby注釈~容器$ ◎継 される ◎百 利用不可 ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終この~propは、~ruby容器~box内に~ruby注釈~boxが 1 つ以上あるときに,注釈は 次のどれに従って描画されるべきかを制御する:
- ~pairどうしの分離を保つ( `separate^v する)
- ひとまとめに `注釈を畳む@ ( `collapse^v する)
- 分離を保つかどうかを,可用な空間に基づいて決定する( `auto^v )
各種 値の意味は: ◎ Possible values:
- `separate@v
- 各~ruby注釈~boxは、それが`~span$する基底~box(たち)と同じ~col(たち)内に描画される。 この~styleは、 `JLREQ$r では “~mono~ruby” と呼ばれている。 ◎ Each ruby annotation box is rendered in the same column(s) as its corresponding base box(es). This style is called “mono ruby” in [JLREQ].
-
例えば、次の 2 つの~markupを描画した結果は,同じになる: ◎ For example, the following two markups render the same:
`mujo-separate-1^xCode◎ and:
`mujo-separate-2^xCode - `collapse@v
- 同じ行l上の同じ`~ruby区分$の中の すべての`~ruby注釈~box$は、連結され,それらの内容は[[ それぞれが`~span$する`~ruby基底~box$たちすべて ]に`~span$する,単独の`~ruby注釈~box$ ]に所属していたかのように~lay-outされる。 この~styleによる描画は、 `JLREQ$r による “~group~ruby” と類似的になる — ただし,複数~行lに分断されるときは、各`~ruby注釈$は,対応する`~ruby基底$と一緒に保たれる。 ◎ All ruby annotation boxes within the same ruby segment on the same line are concatenated, and laid out as if their contents belonged to a single ruby annotation box spanning all their associated ruby base boxes. This style renders similar to “group ruby” in [JLREQ], except that ruby annotations are kept together with their respective ruby bases when breaking lines.
-
次の 2 つの~markupの描画は、両者とも文字~並びは 1 行lに収まるならば,同じになる: ◎ The following two markups render the same both characters fit on one line:
`mujo-collapse-1^xCode◎ and:
`mujo-collapse-2^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
-
~UAは、各~ruby注釈~boxが,対応する基底~boxに描画される方法を決定する際には、次が満たされる限り,どのような~algoを利用してもよい:
- すべての注釈が,それらに対応する基底の上面に収まる場合の結果は、 “~mono~ruby” と一致する。
- ある注釈が それが~spanする基底より幅広になる場合には、それらの基底と隣接する基底との 合間に間隔が課されないよう,何らかの仕方で空間が共有される。
-
あり得る~algoとしては、次が挙げられる:
- `JLREQ$r にて “熟語~ruby” として述べられているもの。
- “熟語~ruby” をより単純化した別の~algoとして、 各~ruby注釈~boxが対応する基底~boxの送幅に収まる場合には, `separate$v として描画し、いずれかが収まらない場合は `collapse$v として描画する。
4.3. ~ruby~text 分布: `ruby-align^p ~prop
◎名 `ruby-align@p ◎値 `start$v | `center$v | `space-between$v | `space-around$v ◎初 `space-around$v ◎適 `~ruby基底$, `~ruby注釈$, `~ruby基底~容器$, `~ruby注釈~容器$ ◎継 される ◎百 利用不可 ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終この~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.
各種 値の意味は: ◎ Values have the following meanings:
- `start@v
- ~ruby内容は、~boxの始端~辺に整列される。 ◎ The ruby content is aligned with the start edge of its box.
- `center@v
- ~ruby内容は、~boxの中で中央寄せにされる。 ◎ The ruby content is centered within its box.
- `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.
- `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.
-
典型的な実装は、既定では,`両端揃え機会$を[ 隣接する~CJK`文字$たちの各~合間には定義し, 隣接する~Latin`文字$たちの各~合間には定義しない ]ので、これによる結果は `JLREQ$r に推奨される挙動になるべきである: ◎ Since a typical implementation will by default define justification opportunities between every adjacent pair of CJK characters and not between adjacent pairs of Latin characters, this should result in the behavior recommended by [JLREQ]:
-
全角~ruby内容に対しては,次のように分布される: ◎ for wide-cell ruby content to be distributed...
-
一方で、半角~glyph~rubyは中央寄せにされるように: ◎ ... and narrow-cell glyph ruby to be centered.
-
複数の基底に`~span$している注釈が伴われる状況で,間隔を分布する方法を説明する段落を追加する。 ◎ Add a paragraph explaining how to distribute space in situations with spanning annotations.
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とそれが属する~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. 辺における効果
5.1. 張出し~ruby
`~ruby注釈~box$は、対応する`~ruby基底~box$より長い場合に,隣接する~boxへ部分的に張出すこともある。 ◎ When ruby annotation box is longer than its corresponding ruby base box, the ruby annotation box may partially overhang adjacent boxes.
この~levelの仕様では、[ どの条件の下で張出しが許容され,その場合にどこまで張出せるか ]は,定義しない。 ◎ This level of the specification does not define how much the overhang may be allowed, and under what conditions.
~ruby~textの張出しが許容されない場合、~rubyは,伝統的な行内~boxの様に挙動する。 すなわち、~boxの境界の中に描画される内容は,~boxの自前のそれに限られ、隣接する要素がその境界を超えて~~侵入することはない: ◎ If the ruby text is not allowed to overhang, then the ruby 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注釈$の内容が隣接する要素まで張出すことが許容されている下では、その内容が基底より幅広なときには、隣接する要素の内容は,`~ruby容器~box$区画の中に部分的に描画され、`~ruby注釈$は,隣接する内容の~~傍にある空いた場所に部分的に重合することになる: ◎ However, if ruby annotation content is allowed to overhang adjacent elements and it happens to be wider than its base, then the adjacent content is partially rendered within the area of the ruby container box, while the ruby annotation may partially overlap the upper blank parts of the adjacent content:
`~ruby基底$に関係する`~ruby注釈$は、決して,別の`~ruby基底$に張出しては~MUST_NOT。 ◎ The ruby annotations related to a ruby base must never overhang another ruby base.
張出しの挙動が[ 基底/~ruby~text ]内容の整列に影響することはない。 整列は、張出しの挙動に対する設定に関わらず,同じ仕方で得られ、重合するに可用な間隔が決定される前に算出される。 それは、 `ruby-align$p ~propにより制御される。 ◎ The alignment of the contents of the base or the ruby text is not affected by overhanging behavior. The alignment is achieved the same way regardless of the overhang behavior setting and it is computed before the space available for overlap is determined. It is controlled by the ruby-align property.
編集者は、一部の事例では,張出しが整列と相互作用する必要もあると疑っている — 要検討。 ◎ I suspect overhanging interacts with alignment in some cases; might need to look into this later.
この節~全体の~logicは、縦組み表語的~layoutにおいても,横縦を入れ替えた下で 同じ仕方で適用される。 ◎ This entire logic applies the same way in vertical ideographic layout, only the dimension in which it works in such a layout is vertical, instead of horizontal.
~UAは、張出す長さの最大として, `JIS4051$r により推奨される 1 個の~ruby~text文字の長さを利用してよい。 日本語において~ruby~textが 隣接する文字に張出せる方法についての詳細な規則は、 `JLREQ$r に述べられている。 ◎ The user agent may use [JIS4051] recommendation of using one ruby text character length 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注釈$を基底の対応する辺に整列するように強制してよい。 この型の整列は、 `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. 既定の~stylesheet
~INFORMATIVEA.1. ~ruby~layoutを~supportするとき
~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; /* `CSS3-FONTS^r を見よ */ text-emphasis: none; /* `CSS3-TEXT-DECOR$r を見よ */ white-space: nowrap; line-height: 1; } rtc:lang(zh), rt:lang(zh) { ruby-align: center; } rtc, :not(rtc) > rt { font-size: 50%; } rtc:lang(zh-TW), :not(rtc) > rt:lang(zh-TW) { font-size: 30%; } /* `注音符号$ */
注記: 作者は、上の規則を利用するべきでない — ~ruby~layoutを~supportする~UAは、上の規則を既定で供するべきである。 ◎ Authors should not use the above rules: a UA that supports ruby layout should provide these by default.
A.2. ~ruby 注釈たちの行内~化法
~HTML/~XHTML による~ruby~markupを行内~注釈として描画するための 見本~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. 丸括弧の生成-法
あいにく, Selectors は~text~nodeには合致し得ないので、~HTMLにおける 丸括弧を伴わない~ruby注釈に,丸括弧を 自動的かつ正しく追加する規則を~CSSで表すことはできない。 (このことは、~HTMLの~rubyでは,対応する要素の無い 生の~textによる暗黙の`~ruby基底$も可能にされているためである。) しかしながら,[ `rb^e / `rtc^e ]が厳格に利用されている事例に対しては、次の規則で取扱える。 ◎ 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 in HTML. (This is because HTML ruby allows implying the ruby base from raw text, without a corresponding element.) However, these rules will handle cases where either <rb> or <rtc> is used rigorously.
/* Parens around <rtc> */ rtc::before { content: "("; } rtc::after { content: ")"; } /* Parens before first <rt> not inside <rtc> */ rb + rt::before, rtc + rt::before { content: "("; } /* Parens after <rt> not inside <rtc> */ rb ~ rt:last-child::after, rt + rb::before { content: ")"; } rt + rtc::before { content: ")("; }
6. 用語集
- `注音符号@ ( `bopomofo^en )
- 中国語の発音に利用される 37 文字と 4 声調からなる符~法 — とりわけ標準中国語( `standard Mandarin^en )。 【台湾のそれ。大陸の中国語に標準の拼音( `pinyin^en )ではない。】 ◎ 37 characters and 4 tone markings used as phonetics in Chinese, especially standard Mandarin.
- 注記: ~UAは、~textを表示する際に,各~glyphを — [ それが,~ruby注釈~内で生じるか, 通常の行内~textとして生じるか ]に応じて — 正しく[ 位置させる/相対的に整列させる ]責を負う — 声調~符(声調~用の注音符号)も含め。 声調~符は、各~基底~文字に対し,~ruby~textの(~~論理順で)末尾に生じる文字であり、間隔法を要する。 それらは、通例では,別々の~col内に, 注音符号の右肩に表示される。 また、声調~符の位置は,音節~内の文字~数に依存する。 しかしながら, `one^en 声調~符は、注音符号の `over^en ではなく `before^en に配置される 【声調~符が複数個ある場合でも、うち一つは最後の注音符号の右肩に配置される?】 。 ◎ Note that the user agent is responsible for ensuring the correct relative alignment and positioning of the glyphs, including bopomofo tone marks, when displaying text, whether it occurs in ruby annotations or as normal inline text. Bopomofo Tone marks are spacing characters that occur (in memory) at the end of the ruby text for each base character. They are usually displayed in a separate column to the right of or above the bopomofo characters, and the position of the tone mark depends on the number of characters in the syllable. One tone mark, however, is placed before the bopomofo, not over it.
- `韓文漢字@ ( `Hanja^en )
- 韓国語~書記体系の下位集合であり,中国語~書記体系から[ 借用された/適応させた ]表語的~文字を活用するもの。 `日本漢字$も見よ。 ◎ Subset of the Korean writing system that utilizes ideographic characters borrowed or adapted from the Chinese writing system. Also see Kanji.
- `平仮名@ ( `hiragana^en )
- 日本語の音節的~用字系, または その用字系の文字。 筆記的には、丸まった外見。 日本語~書記体系の下位集合であり、`日本漢字$や`片仮名$と一緒に利用される。 近現代では、日本語~単語を書く際に[ 日本漢字が[ 可用でない/適切でない ]とき/ 単語の~~送り~~仮名( `ending^en )や~~助詞( `particle^en ) ]に利用されることがほとんどである。 `片仮名$も見よ。 ◎ Japanese syllabic script, or character of that script. Rounded and cursive in appearance. Subset of the Japanese writing system, used together with kanji and katakana. In recent times, mostly used to write Japanese words when kanji are not available or appropriate, and word endings and particles. Also see Katakana.
- `表語文字@ ( `ideograph^en )
- ~alphabeticなど音節的な用字系の文字とは対照的に、[ ~idea/単語/単語のある成分 ]を表現するときに利用される文字(用字系に応じて いくつか変種がある)。 東Asia(日中韓, 他)で利用されるものが、最もよく知られた表語的 用字系である。 ◎ A character that is used to represent an idea, word, or word component, in contrast to a character from an alphabetic or syllabic script. The most well-known ideographic script is used (with some variation) in East Asia (China, Japan, Korea,...).
- `漢字@ ( `Han^en )
- 【 この項は、この訳による補足。 明確に定義されてないが、日中韓で利用されている ~~漢字/表語文字 の総称と思われる(他の用字系 のそれも含むかもしれない)。 特に中国語のそれを指すこともあるかもしれないが、それは,一般に `Hanzi^en と称されている。 】
- `仮名@ ( `kana^en )
- `平仮名$, `片仮名$を併せた総称。 ◎ Collective term for hiragana and katakana.
- `日本漢字@ ( `Kanji^en )
- 日本語における,`表語文字$を指す用語 — 日本語で利用される`表語文字$。 日本語~書記体系の下位集合であり、`平仮名$, `片仮名$と一緒に利用される。 `韓文漢字$も見よ。 ◎ Japanese term for ideographs; ideographs used in Japanese. Subset of the Japanese writing system, used together with hiragana and katakana. Also see Hanja.
- `片仮名@ ( `katakana^en )
- 日本語の音節的~用字系, または その用字系の文字。 角張った外見。 日本語~書記体系の下位集合であり、`日本漢字$, `平仮名$と一緒に利用される。 近現代では、主に外来語を書くときに利用される。 `平仮名$も見よ。 ◎ Japanese syllabic script, or character of that script. Angular in appearance. Subset of the Japanese writing system, used together with kanji and hiragana. In recent times, mainly used to write foreign words. Also see Hiragana.
謝辞
この仕様は、次の方々からの助力~抜きには成し遂げられなかった: ◎ This specification would not have been possible without the help from:
以前の編集者たちにも特別な謝意を:
変更点
前回の作業草案からの~~主要な変更点は: ◎ The following major changes have been made since the previous Working Draft:
- 匿名~box生成~規則と空白の取扱い規則を書き直した。 匿名~空白~boxに特化された~pair法を定義した。 ◎ Rewrote anonymous box generation rules and white space handling rules, defined specialized pairing of anonymous white space boxes.
- ~pair法から,入子の~ruby取扱いを取り出した。 ( ~sizing/~layoutを介して取扱うことになる。)【?】 ◎ Took nested ruby handling out of pairing. (Will be handling it via sizing/layout.)
- ~ruby構造の双向~layoutを定義した。 ◎ Defined bidi layout of ruby structures.