Copyright © 1998-2001 W3C® (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学), All Rights Reserved. W3Cの免責(liability), 商標(trademark), 文書利用(document use), ソフトウェア使用許諾(software licensing)規則が適用される。
「ルビ」とは、ベーステキストの脇の短いテキスト列であり、典型的には、東アジアの文書において、発音を示したり短い注釈をつけるために使われる。この仕様書は、ルビを表すためのマークアップを、XHTMLモジュール [XHTMLMOD] の形式で定義するものである。
この節は、この文書の公開時における位置づけを説明したものである。他の文書がこの文書に取って代わることがある。この文書シリーズの最新の位置づけは、W3Cにおいて管理されている。
この文書は、W3C会員およびその他の利害関係者によりレビューされ、ディレクターによってW3C勧告として公示されている。この文書は安定的な文書であって、参照素材として利用したり、他の文書から規範的参照としての引用に用いてもかまわない。勧告を作成する際のW3Cの役割は、仕様に対する注意を引き、その広範な普及を推進することにある。このことはウェブの機能と相互運用性とを高める。
この文書は、the Internationalization Interest Group (I18N IG) の助力を得て、Internationalization Working Group (I18N WG, members only) によって、the W3C Internationalization Activity の一部として作成されたものである。コメントは、公開アーカイブメーリングリスト www-i18n-comments@w3.org へ送られたい。英語以外の言語、とりわけ日本語でのコメントも歓迎する。この文書についての公開の議論は、www-international@w3.org メーリングリストで行われる (アーカイブを見よ)。
その問題の性質上、また用例を現実的なものにするため、この文書には広範囲のキャラクタを使った用例が組み込まれている。全てのユーザエージェントが全てのキャラクタを表示できるとは限らないかもしれない。ユーザエージェントによっては、設定を変更すれば状況が改善できる。また、広範囲のユーザエージェントや設定をカバーするため、この文書をさまざまなキャラクタエンコーディングで配信するよう、相当な注意が施されている。
この文書に関連する情報は、公開のルビページ (http://www.w3.org/International/O-HTML-ruby) で見ることができる。ここには、この仕様書の翻訳や、潜在的ながらエラッタがある。現行のW3C勧告およびその他の技術文書の一覧は、http://www.w3.org/TR で見ることができる。
the Internationalization Working Group 内部には、この仕様書に関連する特許に関する宣言はない。
rp
要素の代替物
この節は参考 (informative) である。
この文書は、ルビ付注の概観を提示し、それを表すためのマークアップを定義するものである。用例がいくつか用意されている。しかしながら、この文書は、ルビ付注の表現やスタイリングのためのメカニズムについて、何ら規定するものではない。これは、それぞれのスタイルシート言語の受け持ち部分である。
この文書は、以下のように組み立てられている。
第1節1は、ルビ付注の概観を与える。
第1節2は、ルビ付注を表すマークアップの概観を与える。
第2節は、ルビマークアップの規範的定義を提供する。
第3節は、ルビテキストの典型的なレンダリングやスタイリングについて論じる。
第4節は、適合性の判断基準を提供する。
ルビ (ruby) とは、ベーステキスト と呼ばれる別のテキスト並びに結び付けられたテキスト並びである。ルビテキストは、結び付けられた先のベーステキストについての短い注釈をつけるために使われる。読みがな (発音ガイド) をつけるために使われることが最も多い。ルビ付注は、日本では、書籍や雑誌を含め、多種の出版物で頻繁に使われる。ルビは、中国でも、特に学校教科書で使われる。
ルビテキストは、小さめの活字を用いて、ベーステキストの脇に表されるのが普通である。「ルビ」という名前は、実は、イギリス印刷業界での 5.5 ポイント活字サイズの名前に由来する。これは、一般に地のテキストに使われる 10 ポイントの活字サイズの約半分である。図 1.1 は、ベーステキストとしての表意文字 (漢字) 3個と、 読みがなを与える平仮名6個 (しんかんせん - 日本の弾丸列車) とがある用例である。
東アジアの印刷術は、西洋の印刷術には見られない多様な特徴を発達させている。これらのほとんどは、CSS や XSL といったようなスタイルシート言語を用いて適切に扱うことができる。しかしながら、ベーステキストとルビテキストとの間の結び付きを定義するには、追加のマークアップが必須である。
この仕様書は、特別な迂路やグラフィックスを使わなくとも、ウェブ上でルビを利用できるよう、そうした、XHTMLと一緒に使えるよう設計されたマークアップを定義するものである。この仕様書は、ほとんどの読者がマークアップを理解しやすくなるよう、実際のレンダリング例を与えているけれども、そうした用例はすべて参考にすぎない。この文書は、表現やスタイリングのためのメカニズムを規定するものではない。これは、それぞれのスタイルシート言語の受け持ち部分である。
ときには、同じベーステキストに2つ以上のルビテキストが結び付けられることがある。同じベーステキストについて意味と読みがなとの両方を示すというのが典型的な例である。そうした場合には、ルビテキストがベーステキストの両側に出現してもよい。ベーステキストの前側にあるルビテキストは、読みがなを示すことが多い。ベーステキストの後側にあるルビテキストは、意味を示すことが多い。図 1.2 は、平仮名を用いた読みがなとラテン文字とを与える2個のルビテキストを有するベーステキストの例を示している。
さらに、以下の例のように、ベーステキストのうち別々の、しかし重なり合う部分にそれぞれのルビテキストを結び付けてもよい。
Month | Day | Year |
10 | 31 | 2002 |
Expiration Date |
図 1.3: ベーステキストに2個のルビテキストがあり、別々の結びつけが用いられている。
この例では、ベーステキストは "10 31 2002" という日付である。一方のルビテキストは、"Expiration Date" というフレーズである。このルビテキストは、ベーステキスト全体に結び付けられている。もう一方のには、"Month", "Day", "Year" という3つの部分がある。各部分が、ベーステキストのうちの異なる部分に結び付けられている。"Month" は "10" に結び付けられ、"Day" は "31" に結び付けられ、"Year" は "2002" に結び付けられるのである。
この仕様書で定義されるマークアップは、上記のケースの全て、すなわち同じベーステキストに1個または2個のルビテキストが結び付けるマークアップと、ベーステキストの構成部分にルビテキストの部分文字列を結び付けるマークアップとをカバーするよう設計されている。
ルビマークアップには、単純ルビマークアップと呼ばれるものと複雑ルビマークアップと呼ばれるものとの2つの変種がある。単純ルビマークアップは、ベーステキストの並び1個を、単一のルビテキストに結び付けるものである。単純ルビマークアップは、ルビマークアップを知らない (古めの) ブラウザがルビテキストを表示できるよう、バックアップメカニズムを指定することもできる。複雑ルビマークアップは、1個のベーステキストに2個のルビテキストを結び付けることができ、ベーステキストやルビテキストの構成部分の間にさらにきめ細かい結び付きを定義することができる。しかしながら、複雑ルビマークアップは、ルビマークアップを理解しないブラウザのためのバックアップメカニズムを用意することができない。
この節は、この仕様書で定義されるルビを表すためのマークアップの概観を与える。完全な形式面定義は第2節で見ることができる。
最も単純な場合、ルビマークアップは、ベーステキストを表す rb
要素1個とルビテキストを表す rt
要素1個とを包含する ruby
要素を定義する。したがって、この ruby
要素は、ベーステキストとルビテキストとの間に結び付きを作り出すのであり、ほとんどのケースに十分なのである。こちらにあるのは、単純ルビマークアップの一例である。
<ruby> <rb>WWW</rb> <rt>World Wide Web</rt> </ruby>
図 1.4: 単純ルビマークアップの例
図 1.5: 図 1.4 の単純ルビマークアップのレンダリングの例
註: この囲い込み側要素 "<ruby
>" の名前は、その内容がルビテキストをベーステキストに結び付けていることを意味するものと解釈されるべきである。内側にあるものが、ベーステキストを含めてすべてルビであることを意味するものと誤解してはならない。囲い込み側要素の名前は、マークアップ構造の機能をコンパクトかつ明確に見分けられるよう選ばれた。その他の要素の名前は、全体的な長さを短くするよう選ばれた。
ユーザエージェントのなかには、ルビマークアップを理解しなかったり、ルビテキストを適切にレンダリングできないものがあるかもしれない。どちらの状況においても、一般論として、情報が失われないよう、ルビテキストをレンダリングすることが好ましい。一般に受け入れることのできるバックアップは、ベーステキストの直後にルビテキストを置き、ルビテキストを括弧で囲むというものである。括弧は、ルビテキストを他のテキストと混同する可能性を小さくする。(日本の印刷術では括弧内のテキストを「ルビ」と呼ぶことはないので注意するべきである。)
ルビマークアップを理解せず、理解しない要素の内容を単純にレンダリングする古いユーザエージェントとの互換性のため、rp
要素を単純ルビマークアップに追加してルビテキストを区別することができる。
rp
という要素名は、「ルビ括弧 (ruby parenthesis)」を表す。rp
要素と、その内部にある括弧 (またはその他のキャラクタ) は、パックアップメカニズムとしてのみ提供される。未知の要素を無視するがその内容はレンダリングするユーザエージェントは、それぞれの rp
要素の内容を表示することになる。したがって、rp
要素を使って、ルビテキストの始まりと終わりとの両方を示すことができる。
ルビマークアップについて知識のあるユーザエージェントは、rp
要素を認識し、意図的にその内容を表示しないであろう。代わりに、単純ルビマークアップを、もっと適切な方法でレンダリングすることになる。
<ruby> <rb>WWW</rb> <rp>(</rp><rt>World Wide Web</rt><rp>)</rp> </ruby>
図 1.6: 単純ルビマークアップにバックアップのための rp
要素を組み込んだ例
ユーザエージェントは、上記のマークアップをつぎのようにレンダリングすることになる。
WWW (World Wide Web)
図 1.7: バックアップの括弧を用いた単純ルビマークアップのレンダリング
ルビマークアップについて知識があり、かつ、ルビテキスト用にもっと洗練された表現スタイルを有しているユーザエージェントは、括弧をレンダリングしないことを選ぶであろう。たとえば、図 1.6 のマークアップは、次の図に示したようにレンダリングすることができる。
複雑ルビマークアップは、1個のベーステキストに2個以上のルビテキストを結び付け、またはベーステキストの一部分にルビテキストの一部分を結び付けるために使われる。
複雑ルビマークアップは、複数の rb
要素や rt
要素に対応できる。この仕様書は、個別の要素の間の結び付きを明確にするコンテナ要素を定義している。ルビテキストコンテナ要素 rbc
は、rb
要素を囲い込む。ルビテキストコンテナ要素 rtc
は1個または2個ありうるが、これは rt
要素を囲い込む。このことにより、2つのルビテキストコンテナを同じベーステキストに結び付けることが可能になるのである。複雑ルビマークアップを用いると、何個かの rb
要素と、これに対応する個数の rt
要素とを用いることにより、ベーステキストの一部分をルビテキストの一部分に結び付けることも可能となる。さらに、rt
要素は、rbspan
属性を使用して、単一の rt
要素が複数の rb
要素にまたがる (結び付けられる) こと示してもよい。これは、テーブル ([HTML4], section 11.2.6) の th
要素や td
要素の colspan
に似ている。
複雑ルビマークアップの各部分がどこにどのようにレンダリングされるかは、それぞれのスタイルシート言語の一部として定義される。詳しい情報については第3節も見よ。
<ruby> <rbc> <rb>10</rb> <rb>31</rb> <rb>2002</rb> </rbc> <rtc> <rt>Month</rt> <rt>Day</rt> <rt>Year</rt> </rtc> <rtc> <rt rbspan="3">Expiration Date</rt> </rtc> </ruby>
図 1.9: 複雑ルビマークアップが、同じベーステキストの異なる部分に2つのルビテキストを結び付けている。
この例では、最初のルビテキストコンテナが、3つの構成部分 ("Month", "Day", "Year") を囲い込んでいる。これらの構成部分はそれぞれ、ベーステキストのうちの対応する構成部分 ("10", "31", "2002") に結び付けられている。2つ目のルビテキストコンテナ ("Expiration Date") は単一のルビテキストからなり、ベーステキスト全体に結び付けられている。これは図 1.10 に示したようにレンダリングされてもよい。
Month | Day | Year |
10 | 31 | 2002 |
Expiration Date |
図 1.10: 図 1.9 の複雑ルビマークアップのレンダリング
この例は、ルビテキストとベーステキストとの結び付けの粒度を、必要に応じて上下できることを示している。たとえば、ルビテキストは、つぎのような場合にはベーステキスト全体に結び付けることができる。
関係が分かるときには、きめ細かい結び付けをすることも可能である。したがって、こうした状況のために、改良されたレンダリングを提供することができる。たとえば、人の名前は、氏と名とに分解することができるし、漢字の熟語やフレーズは、意味論的な下位部分や個別のキャラクタに分解することができる。粒度を高めたり低めたりして、対応する間隔取りをルビテキストの中にとりながら、ルビテキストの区間取りを設定することが可能であって、読みやすさやバランスのよいレイアウトが実現されることがある。
rp
要素は、複雑ルビマークアップの場合には利用できない。これには理由が2つある。第1に、rp
要素はバックアップメカニズムにすぎず、これは頻度の高い単純なケースにとって遙かに重要であると考えられたからである。第2に、複雑なほうの場合では、合理的なバックアップ的表示を作るのが困難であり、そうした場合のためのマークアップを構築することは、不可能ではないとしても遙かに困難なものになりうるからである。
まとめると、ruby
要素は、以下のうち1つのコンテナとして機能する。
rb
要素、rt
要素と、場合によってはrp
要素の組み合わせたもの (単純ルビマークアップ)
rbc
要素と1個または2個の rtc
コンテナ要素とを組み合わせたもの (複雑ルビマークアップ)
この節は規範的 (normative) である。
この節は、ルビマークアップの形式的な構文定義や機能の仕様を内容とする。XHTMLモジュラ化フレームワーク、とりわけ"Modularization of XHTML" [XHTMLMOD] 仕様書にある程度馴染みのあることが前提とされる。
以下は、ルビマークアップのための要素の抽象的定義である。これは、XHTMLモジュラ化フレームワーク [XHTMLMOD] と一貫性をもたせられている。XHTML 抽象モジュールの詳しい定義は [XHTMLMOD] で見ることができる。
要素 | 属性 | 最小内容モデル |
---|---|---|
ruby | 共通 | (rb, (rt | (rp, rt, rp))) |
rbc | 共通 | rb+ |
rtc | 共通 | rt+ |
rb | 共通 | (PCDATA | Inline - ruby)* |
rt | 共通, rbspan (CDATA) | (PCDATA | Inline - ruby)* |
rp | 共通 | PCDATA* |
ruby
要素の最大内容モデルは、以下のとおりである。
((rb, (rt | (rp, rt, rp))) | (rbc, rtc, rtc?))
ruby
要素の最小内容モデルは、単純ルビマークアップに対応する。ruby
要素の最大内容モデルの (rbc, rtc, rtc?)
という択一選択肢は、複雑ルビマークアップに対応する。
この抽象的定義の XHTML DTD モジュールとしての実装は、付録 A で見ることができる。XMLスキーマ [XMLSchema] 実装は、現在作業中である ([ModSchema] を見よ)。
ruby
要素
ruby
要素は、全体のコンテナとして機能するインライン (またはテキストレベル) 要素である。この要素は、rb
要素、rt
要素とオプションの rp
要素と (単純ルビマークアップ) か、rbc
要素と rtc
要素と (複雑ルビマークアップ) かのいずれか一方を包含する。
単純ルビマークアップの場合、ruby
要素は、rb
要素1個に rt
要素1個が続いたものか、rb
要素1個、rp
要素1個、rt
要素1個、もう1個のrp
要素が連なったものかのいずれか一方を包含する。rt
要素の内容は、ルビテキストと解釈され、ベーステキストとしての
要素の内容と結び付けられる。rb
rp
要素の内容は、存在しても無視される。
複雑ルビマークアップの場合、ruby
要素は、rbc
要素1個に、1個または2個の rtc
要素が続いたものを内容とする。それぞれの rtc
要素の下位要素の内容は、ルビテキストとして解釈され、ベーステキストとしての rbc
要素の下位要素の内容に結び付けられる。
ruby
要素は、共通属性のみをとる。共通属性の例としては、つぎのようなものがある。id
, class
, xml:lang
. 共通属性は、ルビマークアップと一緒に使われるマークアップ言語による。[XHTML 1.1] の場合、これらは XHTML Modularization, Section 5.1 [XHTMLMOD] で定義されている。
rbc
要素
rbc
(ルビテキストコンテナ) 要素は、複雑ルビマークアップの場合には、rb
要素のコンテナとして機能する。1個の ruby
要素の中に出現してよい rbc
要素は1個だけである。
rbc
要素は、共通属性のみをとる。
rtc
要素
rtc
(ルビテキストコンテナ) 要素は、複雑ルビマークアップの場合には、rt
要素のコンテナとして機能する。1個の ruby
要素の中に出現してよい rtc
要素は1個または2個であり、これらは、ルビテキストを、1個の rbc
要素で表される単一のベーステキストに結び付ける。1個の ruby
の中に3個以上の rtc
要素が出現してはならない。
rtc
要素は、共通属性のみをとる。
rb
要素
rb
(ルビベース) 要素は、ベーステキストをマークアップする機能を果たす。単純ルビマークアップでは、出現してよい rb
要素は1個だけである。複雑ルビマークアップでは、1個の rbc
要素の中に複数の rb
要素が出現してもかまわない。ルビ表現をきめ細かく制御するため、rb
要素はそれぞれ、対応する rt
要素に結び付けられる。
rb
要素は、その内容として、インライン要素またはキャラクタデータを包含してよいが、ruby
要素はその子孫要素として許容されない。
rb
要素は、共通属性のみをとる。
rt
要素
rt
要素は、ルビテキストを表すマークアップである。単純ルビマークアップでは、出現してよい rt
要素は1個だけである。複雑ルビマークアップでは、1個の rtc
の中に複数の rt
要素が出現してもよく、rt
要素はそれぞれ、対応する rb
によって表される関連するベーステキストに対するルビテキストを包含する。
rt
要素は、その内容として、インライン要素またはキャラクタデータを包含してよいが、ruby
要素はその子孫要素として許容されない。
rt
要素は、共通属性と rbspan
属性とをとる。複雑ルビマークアップでは、rbspan
属性により、1個の rt
要素が複数の rb
要素にまたがることが可能となる。値は、0 より大きい整数値でなければならない。この属性のデフォルト値は 1 である。rbspan
属性は、単純ルビマークアップでは用いるべきではなく、ユーザエージェントは、rbspan
属性が単純ルビマークアップの中に出現してもそれを無視するべきである。
rp
要素
rp
要素は、単純ルビマークアップの場合、ユーザエージェントがルビテキストをベーステキストと区別して表す方法を他に有していないときに、ルビテキストの始まりと終わりとを示すことができるキャラクタを指定するために使うことができる。括弧 (または類似のキャラクタ) は、受け入れることのできるバックアップを提供することができる。この状況では、ルビテキストは、インラインにレンダリングされて、バックアップ括弧に囲まれるよう格下げされるにすぎないことになる。これは、インラインのレンダリングだけしか利用できない条件下では、最も不適切でないレンダリングである。rp
要素は、複雑ルビマークアップと一緒に使うことはできない。
rp
要素は、共通属性のみをとる。
バックアップのために括弧を使うことにより、ルビテキストにするつもりのテキスト並びと、たまたま括弧に囲まれた他のテキスト並びとが混同されるかもしれない。文書またはスタイルシートの制作者は、この混同の潜在的可能性を意識するべきであり、バックアップには曖昧さのない区切り文字を選ぶようアドバイスされる。
この節は参考 (informative) である。
この節は、この文書で定義されているルビマークアップの文脈におけるレンダリングおよびスタイリングの多様な側面について論じる。しかしながら、この文書は、表現/スタイリングのメカニズムを規定するものではない。これは、それぞれのスタイルシート言語に委ねられている。ルビをスタイリングするためのフォーマッティングプロパティは、CSS用およひXSL用が開発中である。詳細については、たとえば "CSS3 module: Ruby" [CSS3-RUBY] (進行中の作業) を見よ。
日本語の印刷の文脈におけるルビフォーマッティングの詳細は JIS-X-4051 [JIS4051] で見ることができる。
日本語の「ルビ」という用語は、ベーステキストの脇に視覚的にレンダリングされたテキストを表すためにのみ用いられる。そうした場合についての考慮事項は、第3節2 (フォントサイズ), 第3節3 (ポジショニング), 第3節4 (ルビマークアップの表現) に与えられている。この種の表現は、可能な限りどこででも用いられるべきである。しかしながら、ルビをウェブに導入することにより、伝統的な印刷術には存在しない現象や問題に至ることがある。この仕様書で定義されているように、ルビを表す構造的マークアップは、ルビテキストがつねにベーステキストの脇にレンダリングされることを保証することができない。XHTMLでマークアップされた文書のための出力デバイスは、現在も将来も、とても広く多様なものがある。以下は、いろいろなレンダリングについて考えられるシナリオと理由である。
典型的な利用法では、ルビテキストのフォントサイズは、ベーステキストのサイズの約半分というのが普通である。実際、「ルビ」という名前は、イギリス印刷業界での 5.5 ポイント活字サイズの名前に由来するものである。これは、一般に地のテキストに使われる 10 ポイント活字サイズの約半分である。
ベーステキストを基準として、ルビテキストが出現できる位置はいくつかある。東アジアのテキストは、縦組みにも横組みにもレンダリングされるから、ここでは、「上側」「下側」や「右側」「左側」という用語よりも、「前側 (before)」「後側 (after)」という用語を用いる。「前側」「後側」という言葉は、ベーステキストを包含する行の「前側」/「後側」として理解されるべきでものである。以下のテーブルに対応関係を示す。
terminology |
横組みレイアウト (左から右へ、上から下へ) |
縦組みレイアウト (上から下へ、右から左へ) |
---|---|---|
前側 (before) | 上側 | 右側 |
後側 (after) | 下側 | 左側 |
ルビテキストは、ベーステキストの前側におかれるのがほとんどである (図 1.1 および図 3.2 を見よ)。ときには、特に縦組みの教育用の文書では、ルビテキストがベーステキストの後側、すなわち下側に出現することがある (図 3.1 を見よ)。中国語では、ベーステキストの後側にピンインのルビテキストが出現するのがむしろ一般的である。また、ルビテキストは、縦組みレイアウトのベーステキストの後側に出現することもある (図 3.3 を見よ)。これらすべての場合で、ルビテキストの筆記方向はベーステキストの筆記方向と同じ、すなわち、ベーステキストが縦組みならば縦組み、ベーステキストが横組みならば横組みである。
伝統的な中国語のテキストでは、横組みレイアウトの中であっても、「ボポモフォ」ルビテキストが、ベーステキストの右側に出現することができる。
ボポモフォの声調記号 (上記の例ではわかりやすいよう赤色で示した。) は、別のコマ (ボポモフォルビテキストの右側) にあるように見え、そのため「ルビのルビ」と見られることもあるので注意すること。しかしながら、これはルビテキストの一部としてエンコードされているにすぎない。このエンコードの詳細については、この文書では扱わない。
この仕様書は、ルビマークアップがどのように表示されるかを解説するものではない。ルビマークアップの正確な挙動を規定するには、一般的にはスタイルシートが使われることになる。
註. ルビテキストのレンダリングはスタイルシートによって制御されるべきものであるが、制作者やユーザによってスタイル情報が提供されていない場合には、視覚的ユーザエージェントは、使われているルビテキストが1個だけであるときには、ベーステキストの前側にルビテキストを置くことが推奨される。単純ルビの場合も同じである。ルビテキストが2つあるときは、一つ目のルビテキストはベーステキストの前側に置かれるべきであり、二つ目のルビテキストはベーステキストの後側に置かれるべきである。このフォーマッティングを記述したユーザエージェントのデフォルトスタイルシートの例は、[CSS3-RUBY] またはその後継文書によって提供されることになる。
非視覚的レンダリングについては、スタイルシート情報がないときは、ベーステキストとルビテキストとを、それぞれの位置づけを示して (例. 声を変える、ピッチを変えるなど) 両方ともレンダリングすることが推奨される。
<ruby xml:lang="ja"> <rbc> <rb>斎</rb> <rb>藤</rb> <rb>信</rb> <rb>男</rb> </rbc> <rtc class="reading"> <rt>さい</rt> <rt>とう</rt> <rt>のぶ</rt> <rt>お</rt> </rtc> <rtc class="annotation"> <rt rbspan="4" xml:lang="en">W3C Associate Chairman</rt> </rtc> </ruby>
図 3.5: class
属性および xml:lang
属性をもつルビマークアップ
横組みテキストを規定し、ベーステキストの前側に読みがなをレンダリングし、ベーステキストの後側に注釈をレンダリングするスタイルシートを用いると、上記のマークアップはこのようにレンダリングすることができる。
場合によっては、ルビマークアップを含んでいる文書が、音声ブラウザや点字ユーザエージェントといったような非視覚的ユーザエージェントでレンダリングされる必要があるかもしれない。そうしたレンダリングシナリオにとっては、つぎのことを理解することが重要である。
ユーザの必要に応じて、とても高速な「斜め読み」から、とても注意深く丹念な読み上げまで、テキストの読み上げ方が違うことがある。このため、非視覚的レンダリングにおけるルビテキストの扱いも、速読ではルビテキストを飛ばすし、精読ではルビ構造や、使われている実際のキャラクタを詳細に検討するというように、違ってくることがある。
ルビテキストが読みがなを表す場合はよくあるが、この場合にベーステキストとルビテキストとの両方をレンダリングすると、煩わしい重複を生じることがある。音声合成装置は、大規模な辞書に基づいてベーステキストを正確に発音できるのでもよいし、そうでなければ、ルビテキストによって与えられた読みがなに基づいて正しい発音を選択できるのでもかまわない。
すべてのルビテキストが発音を表しているわけではない。制作者は、いろいろな目的のために用いられているルビテキストを、class
属性を用いて区別するべきである。これは、上記では、読みがなを示すのに使われているルビテキストには class="reading" を使って示されている。
読みがなを示すルビテキストが、一見すると完全に発音通りのように見える場合でも、正確な発音を生み出さないことがある たとえば、ボポモフォは、ベーステキストのキャラクタそれぞれに独立に結び付けられる。文脈依存的な音や声調の変化は反映されないのである。同様に、日本語では、助詞の「は」を用いて「わ」と発音させたり、母音を用いて長音を示すといったように、綴り字の例外が起こりうる。そうした場合に備えて、制作者は、その発音を表すよう設計された特殊なマークアップを用いて実際の発音を補いたいと思ってもよいし、音声レンダリングシステムがそうしたケースを正確に処理できることに信頼してもかまわない。
rp
要素の代用品
制作者が、ルビマークアップを知らず、CSS2 [CSS2] や XSL [XSL] のスタイルシートもサポートしないユーザエージェントのための善後策について関心がないのであれば、rp
要素は不要である。
にもかかわらず、たとえばデバイスの解像度が伝統的なルビレンダリングに適していないならば、善後策としてのルビテキストを強調することが可能である。[CSS2] を用いると、以下のスタイル断片の例のように、:before および :after 擬似要素 ([CSS2], section 12.1) とともに 'content' プロパティ ([CSS2], section 12.2) を用いて、括弧を生成することができる。
rt:before { content: "(" } rt:after { content: ")" }
図 3.8: rt
要素の周囲に括弧を生成するための CSS2 スタイルの断片
上記の例では、rt
要素の周囲に自動的に括弧が生成されることになる。上記のスタイルルールは、ルビテキストをインラインにポジショニングするスタイルシートとともに用いられる。XSLT [XSLT] では、括弧の生成は素直である。
この節は規範的 (normative) である。
この仕様書の文脈の中では、マークアップ、文書型、モジュール実装、文書、ジェネレータ、インタプリタについて適合性を主張することができる。これらの場合のほとんどで、単純適合と完全適合という2つのレベルの適合性が利用可能である。単純適合とは、適合するオブジェクトが、第2節1 にあるルビ要素の最小内容モデル、すなわち単純ルビマークアップのみをサポートすることを意味する。完全適合とは、適合するオブジェクトが、第2節1 にあるルビ要素の最大内容モデル、すなわち単純ルビマークアップと複雑ルビマークアップとの両方がサポートされることを意味する。
マークアップが適合的な単純ルビマークアップであるのは、それが1個以上の ruby
要素を包含し、それらの (子要素を含む) 全ての要素の内容が 第2章1 にある最小内容モデルに適合している場合である (すなわち単純ルビマークアップだけが許容される)。マークアップが適合的な完全ルビマークアップであるのは、それが1個以上の ruby
要素を包含し、それらの (子要素を含む) 全ての要素の内容が 第2節1 の最大内容モデルに適合している場合である (すなわち、単純ルビマークアップと複雑ルビマークアップとの両方が許容される)。
文書型が適合的な単純ルビマークアップ文書型であるのは、それが、ruby
要素に (インライン要素といったような) 適切な要素を追加し、必要な要素や属性を定義することにより、適合的な単純ルビマークアップを統合している場合である。文書型が適合的な完全ルビマークアップ文書型であるのは、それが、ruby
要素に (インライン要素といったような) 適切な要素を追加し、必要な要素名属性を定義することにより、適合的な完全ルビマークアップを統合している場合である。
モジュール実装 (たとえばDTDやXMLスキーマテクノロジーを用いたもの) が適合的な単純ルビモジュール実装であるのは、それが、上述のように、単純ルビマークアップを、他のモジュールと一緒に文書型へと統合するよう設計されている場合である。モジュール実装が適合的な複雑ルビモジュール実装であるのは、それが、上述のように、完全ルビマークアップを、他のモジュールと一緒に文書型へと統合するよう設計されている場合である。モジュール実装が適合的な完全ルビモジュール実装であるのは、それが、上述のように、(たとえばスイッチを提供したり、別個のモジュール実装を2つ用意することにより) 単純ルビマークアップか完全ルビマークアップかのいずれかを、他のモジュールと一緒に文書型へと統合するよう設計されている場合である。
文書が適合的な単純ルビマークアップ文書であるのは、それが、適合的な単純ルビマークアップを包含し、かつ、複雑ルビマークアップや非適合的なルビマークアップを包含しない場合である。文書が適合的な完全ルビマークアップ文書であるのは、それが、適合的な完全ルビマークアップを包含し、かつ、非適合的なルビマークアップを包含しない場合である。
ジェネレータが適合的な単純ルビマークアップジェネレータであるのは、それが、適合的な単純ルビマークアップを生成し、かつ、複雑ルビマークアップや非適合的なルビマークアップを生成しない場合である。ジェネレータが適合的な完全ルビマークアップジェネレータであるのは、それが、適合的な完全ルビマークアップを生成し、かつ、非適合的なルビマークアップを生成しない場合である。
インタプリタが適合的な単純ルビマークアップインタプリタであるのは、それが、非適合的な単純ルビマークアップを拒絶し、適合的な単純ルビマークアップを受容し、かつ、それがルビマークアップを解釈するところではこの仕様書に従って解釈をする場合である。インタプリタが適合的な完全ルビマークアップインタプリタであるのは、それが、非適合的なルビマークアップを拒絶し、完全ルビマークアップを受容し、かつ、それがルビマークアップを解釈するところではこの仕様書に従って解釈をする場合である。インタプリタの例としては、サーバ側分析変換ツールやレンダリングプログラムがある。
XHTMLモジュラリゼーション適合性については、[XHTMLMOD] の第3節をご覧いただきたい。
この付録は参考 (informative) である。この付録の内容は、ラストコール=レビューの間に受け取った質問やコメントに基づいた、設計上の決断に関する注記である。
たとえば <rbc><rb>...</rbc> を <rb><rbc>...</rb> に変更してはどうか (rt/rtc についても同様) という提案があった。これは、ある意味、自然であるように見える。しかしながら、XMLでは、要素の内容は混合内容 (キャラクタデータと要素との両者があり、並びや出現の制約はない。) か要素内容 (要素のみで制約あり) かのいずれかである。これは、<rb> が包含するのが <rbc> 要素だけか、キャラクタデータとインライン要素とだけかを判断することができないことを意味する。
最小内容モデルから rp
要素を外すさまざまな提案があった。それらの案は検討されたが、以下の理由から不採用となった。
rp
を認識して除去することは、実装がきわめて容易である。実装物の負担は最小限である。CSSもXSLも、rp
要素を除去したり、その表示を避けたりするための簡単なメカニズムを容易している。
要素の名前を変えてはどうか、とりわけ <ruby> を <gloss> に変えてはどうかという提案があった。しかしながら、ルビマークアップは、ある意味、傍注 (gloss) に必要であろうマークアップに似るよう意図されているが、その目的のために設計されたものではない。
この付録は参考 (informative) である。
歴史的な理由から、オーサリングツールの中には、
<ruby> <rb>三毛猫</rb> <rp>(</rp><rt>みけねこ</rt><rp>)</rp> </ruby>
のようにではなく、
<ruby> 三毛猫 <rp>(</rp><rt>みけねこ</rt><rp>)</rp> </ruby>
のように、rb
要素の開始タグや終了タグをつけずにルビマークアップを生成するものがあるかもしれない。
後者のマークアップは、この仕様書には適合していないが、そうしたオーサリングツールによって生成された文書との後方互換性について気を配るユーザエージェントは、後者のマークアップを、あたかも前者のように書かれたものであるかのように扱ってもかまわない。
この付録は参考 (informative) である。
この付録は参考 (informative) である。
勧告案 (Proposed Recommendation. http://www.w3.org/TR/2001/PR-ruby-20010406) からの変更点:
この節は参考 (informative) である。
Takao Suzuki (鈴木 孝雄) と Chris Wilson は、編集者として以前の草稿に協力いただいた。
W3C国際化ワーキンググループのメンバー、とりわけ Mark Davis および Hideki Hiura (樋浦 秀樹)、ならびにW3C国際化インタレストグループのメンバーからの助力がなければ、この仕様書はあり得なかったであろう。
このほかの協力者としては、 Murray Altheim, Laurie Anna Edlund, Arye Gittelma, Koji Ishii, Rick Jelliffe, Eric LeVine, Chris Lilley, Charles McCathieNevile, Shigeki Moro (師 茂樹), Chris Pratley, Nobuo Saito (斎藤 信男), Rahul Sonnad, Chris Thrasher が挙げられる。
この仕様書で定義されているマークアップは、日本規格協会の電子文書処理システム標準化調査研究委員会の第2作業部会 (組み版) によって開発された [JIS4052] のルビマークアップに合わせて調整されている。我々は、第2作業部会のメンバー、とりわけ Kohji Shibano (芝野 耕司, 部会長), および Masafumi Yabe (家辺 勝文, 連絡担当) の協働に感謝したいと思う。技術的には、[JIS4052] におけるルビのマークアップは、2つの点において、この仕様書のマークアップと異なる。第1として、特殊記号に基礎を置き、XMLと互換的でない代替的なマークアップ形式があり、第2として、rp
要素が許容されていないのである。
価値あるラストコールコメントを、つぎの方々からいただいた。HTMLワーキンググループ、 CSSワーキンググループ、 XSLワーキンググループ、 WAI P&F ワーキンググループ、 Steven Pemberton, Trevor Hill, Susan Lesch, Frank Yung-Fong Tang. Akira Uchida (内田 明) には、翻訳者の観点からのフィードバックを提供いただいた。
属性を用いた初期のルビマークアップの提案は、[DUR97] で解説されている。