著作権 ©1998-2001 W3C® (MIT、INRIA、 Keio)、全権利保有。 W3Cの免責、 商標、 文書利用及びソフトウエア使用許諾規則が適用される。
「ルビ」とは、主に東アジアの文書に見られる、ベーステキスト近傍にある短いテキストのことであり、ベーステキストの発音を示したりちょっとした注釈を加えたりする目的で使われる。本仕様書は、XHTMLモジュール[XHTMLMOD]の書式で、ルビのマーク付けを規定する。
この節は、本書の公開時における地位を述べるものである。他の文書がこの文書を引き継ぐ場合もあり得る。本書の系列にある文書に関する最新の地位についてはW3Cが管理する。
本書はW3C勧告提案である。すなわち、本仕様は安定しており、実装実験の集積によって本仕様の機能が実装可能であることが示されているということである。本コンソシアムの諮問委員会でのレビューを経た後、本仕様は本仕様を参照として含むXHTML 1.1と共に勧告文書となるか、または、(レビューによって変更が必要とされた場合)勧告候補あるいは作業文書として再発行される。 XHTML 1.1の変更の結果、表記の調整が必要となる場合もある。
本書は、W3C国際化作業部会 (I18N WG, メンバー限定)によって、W3C国際化活動の一環として、国際化関連部会(I18N IG)の助力を受けつつ、製作された。 技術的あるいは編集上のコメントは、公開アーカイブのメーリングリストwww-i18n-comments@w3.orgに送付されたい。英語以外の言語によるコメント、特に日本語のコメントも、歓迎する。 ルビについてのより開かれた討論には、www-international@w3.orgメーリングリスト(アーカイブ参照)を用意してある。
本書の主題の性質上、また凡例の現実味を増すため、この文書は多様な文字を用いた例を含んでいる。ユーザエージェントによっては全ての文字を表示できないこともあるであろう。設定を変えることで表示を改善できるユーザエージェントもあるかもしれない。 さらに、幅広いユーザエージェントやその設定に対応できるよう、本書の送信には慎重に注意を払い、多くの文字符号化方法を用いている。 【訳注: 邦訳文書の送信に用いる文字符号化方法は、多くありません。】
勧告提案としての出版は、W3Cメンバーによる支持を意味するものではない。本書は依然としてドラフト文書なのであり、更新されたり、上書きされたり、他の文書によって破棄されたりする可能性が常にある。W3C勧告提案を「作業中」のものとしてではなく引用することは、不適切である。W3C勧告及び他の技術文書の一覧は、http://www.w3.org/TRで得られる。
国際化作業部会において本仕様に関連する商標の宣言は存在しない。
本書のレビュー期間は、2001年5月7日で終了する。
rp
要素の代替この章は参考情報である。
本書は、ルビ注についての概観を示し、またそのマーク付けを定義する。幾つかの例も示す。しかしながら本書は、ルビを表示したりスタイリングしたりするためのメカニズムについては何らの規定も行なわない。それは各スタイルシート言語の守備範囲である。
本書は以下のような構成になっている。
第1章1節では、ルビについて概観する。
第1章2節では、ルビのマーク付けについて概観する。
第2章では、ルビの構文について規範的な定義を行なう。 ここには、XHTMLモジュール化機構[XHTMLMOD]の文脈における、ルビのマーク付けに関する公式な定義が含まれる。
第3章では、ルビテキストの典型的レンダリング及びスタイリングについての議論を行なう。
ルビとは、あるテキスト列のことを示す用語である。そのテキスト列は、ベースとして参照される他のテキスト列と結び付けられるものである。ルビテキストは、結び付けられるベーステキストの、短い注釈を示すために用いられる。最も多い用法は、読み(発音の手引き)を提供することである。ルビ注は、日本で、書籍や雑誌を含む様々な種類の出版物で多く用いられる。中国においても、ルビは、特に教科書において使われる。
ルビ注は、たいがい、ベーステキストに寄り添うようにして小さいタイプフェイスで表示される。実際「ルビ」という名は、イギリス印刷界における5.5ptフォントの呼称に語源があり、これは一般的に本文に用いられる10ptフォントのおよそ半分の大きさである。図1.1にルビの例を示すが、そこでは3つの表意文字(漢字)がベーステキストであり、6つのひらがなが読み――しんかんせん: 日本の弾丸列車――を表している。
図1.1: ルビテキストが、ベーステキストの文字の読みを示している。
東アジアのタイポグラフィは西洋のタイポグラフィには現れない様々な要素を開発してきた。その多くはCSSやXSL等のようなスタイルシート言語で適切に示すことができる。ところが、ルビは、ベーステキストとルビテキストとの結びつきを定義するためのマーク付けを必要とするのである。
この仕様書はそうしたマーク付けについて、特別な作業や画像に頼らずにWebでルビテキストを用いることが可能になるよう、XHTML で使えるように設計し、規定するものである。多くの読者にとってマーク付けの定義に関する理解が容易になるよう、本仕様は、ルビの実際のレンダリング例を示すようにはしているものの、この例は参考情報に過ぎないものである。本書はルビの表示及びスタイリングのメカニズムについては何らの規定も行わない。そのメカニズムは各スタイルシート言語の守備範囲である。
あるベースに対して、2つ以上のルビ注が結び付けられることもある。典型的な例は、1つのベーステキストに対して読みと意味とを示すものである。こうした場合、ルビ注はベーステキストの両側に出現するであろう。ベーステキストの前に出現するルビテキストは、たいがい、読みを示し、ベーステキストの後に出現するルビテキストは、たいがい、意味を示す。図1.2は、ひらがなルビテキストとラテン文字ルビテキストの2つが、同じベーステキストの読みを示している例である。
図1.2: 同じベーステキストに2つのルビテキストが振られている。
1つのベーステキストについて2つのルビ注がある場合で、各々のルビ注がベーステキストの異なる部分――しかし重なり合う部分――と結び付けられるようなケースもあり得る。次の例のようなケースである。
月 | 日 | 年 |
10 | 31 | 2002 |
有効期限 |
図1.3: ベーステキストについて異なる結びつきをしている2つのルビテキスト
この例では、ベーステキストは「10 31 2002」という日付である。ルビ注の一方は「有効期限」という語句である。このルビテキストは、ベーステキスト全体と結びついている。もう一方のルビ注は「月」「日」「年」という3つの部分から成る。各部分はベーステキストの別々の部分に結びついている。「月」は「10」と、「日」は「31」と、「年」は「2002」と結びついているのである。
本仕様が定義するマーク付けは、以上に述べた全てのケース――1つあるいは2つのルビテキストを同じベーステキストに結びつけるマーク付けと、ルビテキストの部分列をベーステキストの部分部分に結びつけるマーク付け――をカバーするように設計されている。
ルビのマーク付けには、異なる2つの種類がある。単純ルビマーク付けと呼ぶものと、複合ルビマーク付けと呼ぶものである。単純ルビマーク付けは、あるベーステキスト列と単一のルビテキストとを結びつけるのに用いる。単純ルビマーク付けは、ルビのマーク付けを認識しない(古い)ブラウザにおけるフォールバックのメカニズムを指定することもできる。複合ルビマーク付けは、1つのベーステキストと2つのルビテキストを結びつけることができ、またルビテキストの部分列とベーステキストとのより木目細かな結びつきとを指定できる。しかし、複合ルビマーク付けは、ルビのマーク付けを理解しないブラウザに対するフォールバックのメカニズムは提供しない。
この節では、本仕様が定義するルビのマーク付けを概観する。公式仕様の全体は、第2章で示す。
最も単純な場合、ルビのマーク付けは、ベーステキストたる1つのrb
要素とルビテキストたる1つのrt
要素とを含む1つのruby
要素によって示される。このruby
要素は、ベーステキストとルビテキストとの結びつきを生み出すものであり、多くの場合はこれで十分である。次に単純ルビのマーク付けを示す。
<ruby> <rb>WWW</rb> <rt>World Wide Web</rt> </ruby>
図1.4: 単純ルビマーク付けの例
図1.5: 図1.4に示した単純ルビマーク付けのレンダリング例
注意:
この親要素名 「ruby
」は、その内容がルビとベーステキストとの関連性を示すものとして解釈する必要がある。ベーステキストを含む、ruby
要素の内容全体がルビであるという誤解をしてはならない。
この名称は、マーク付け全体の働きを明確に示す簡略な名称として選んだ。他の要素名は短さを主眼に選んだ。
ルビのマーク付けを理解しないユーザエージェントもあるであろうし、またルビを適切にレンダリングできないものもあろう。どちらの状況においても、情報が欠落しないよう、ルビ要素の内容をレンダリングしようと試みるのが一般的に望ましい。広く受け入れられるフォールバックは、ルビテキストをベーステキストの直後に置き、ルビテキストをパーレンで囲うというものである。パーレンによって、ルビテキストが他のテキストと混同される可能性が減少する。(和文タイポグラフィにおいては、パーレンで挟まれたテキストが「ルビ」と呼ばれることは決してないということに、注意すべし。)
ルビのマーク付けを理解せず、理解不能な要素については単純にその内容をレンダリングするような、古いユーザエージェントとの互換性を保つため、単純ルビマーク付けにrp
要素を加え、ルビテキストの区別をつけさせることもできる。
要素名rp
は「ruby parenthesis (ルビパーレン)」の略である。rp
要素及びその内容であるパーレン(あるいは他の文字)は、フォールバックのメカニズムを提供するのみである。未知の要素を無視するがその内容をレンダリングするユーザエージェントは、各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.8: rp
要素を除いた高度なレンダリング
複合ルビマーク付けは、1つのベーステキストに2つ以上のルビ注を振る場合や、ルビテキストの部分列をベーステキストの部分部分に結び付ける場合に用いる。
複合ルビマーク付けは、複数のrb
要素と複数のrt
要素を提供する。
この仕様は、コンテナ要素が各要素間の結びつきを明示するよう定めている。ルビベースのコンテナ要素であるrbc
は、rb
要素群を含む。rt
要素群を含んでいるrtc
要素――ルビテキストのコンテナ要素――は、1つあるいは2つ存在できる。
これにより、同じベーステキストに対して、2つのルビテキストコンテナを結びつけることが可能である。複合ルビマーク付けにおいては、複数のrb
要素と、同数のrt
要素とを用いて、ベーステキストの部分列とルビテキストの部分列とを結びつけることもできる。更に、rt
要素のrbspan
属性を用いて1つのrt
要素が複数のrb
要素にまたがること(結びつけられること)を示すことも可能である。
これは、表のth
要素及びtd
要素のcolspan
属性([HTML4]、11.2.6節)と相似的である。
複合ルビマーク付けの各部を、どこにどのようにレンダリングするかは、各スタイルシート言語が定義するところである。この点については本書第3章をも参照されたい。
<ruby> <rbc> <rb>10</rb> <rb>31</rb> <rb>2002</rb> </rbc> <rtc> <rt>月</rt> <rt>日</rt> <rt>年</rt> </rtc> <rtc> <rt rbspan="3">有効期限</rt> </rtc> </ruby>
図1.9: 2つのルビテキストを同じベーステキストの異なる部分と結びつけている複合ルビマーク付け
この例では、最初のルビテキストコンテナが3つの部分(「月」「日」「年」)を含んでいる。この各ルビ部品は、各々が対応するベーステキスト部品(「10」「31」「2002」)と結びついている。第2のルビ部品(「有効期限」)は、単一のルビテキストから成り、ベーステキスト全体(「 10 31 2002」)と結びついている。 この例は、次の図1.10に示すようなレンダリングとなるであろう。
月 | 日 | 年 |
10 | 31 | 2002 |
有効期限 |
図1.10: 図1.9で示した複合ルビマーク付けのレンダリング
この例は、ルビテキストとベーステキストとの結びつけ方は必要に応じて細かくも粗くもできるということを示している。例えば次のような場合に、ルビテキストとベーステキスト全体を結びつけることができる。
関連性が既知である場合は、より木目細かい結びつきを示すこともできる。そうした状況においては、当然、高度なレンダリングが提供できる。例えば、人物の名前を姓と名とに分けることや、漢字熟語や成句を意味的な小部分に分けたり個々の文字に分解したりすることなどである。 細かく分ける場合も粗くする場合も、ルビテキストの跨り具合はベーステキストに対応する空間について設定でき、より良い可読性やバランスのよいレイアウトが実現できるであろう。
複合ルビマーク付けにおいては、rp
要素は利用できない。
これには2つの理由がある。第1は、rp
要素はフォールバックのメカニズムであるに過ぎず、よりありがちである単純なケースにおいて重要度が大きい点。第2は、より複雑なケースにおいては、合理的なフォールバック表示というものが困難であり、またそのためのマーク付けを構築することも不可能ではないとしても非常に難しい点である。
要するに、ruby
要素は、以下の何れかのコンテナとして働く。
rb
要素とrt
要素。更にrp
要素も出現し得る形態(単純ルビマーク付け) で、
rbc
コンテナ要素と1つあるいは2つのrtc
コンテナ要素とから成る1つの組み合わせ(複合ルビマーク付け)で、
for:
この章は規範情報である。
この章には、公式の構文規定と、ルビ要素の機能についての仕様とが含まれる。ここでは、XHTMLモジュラー化機構、とりわけ『XHTMLのモジュラー化機構』[XHTMLMOD]仕様に親しんでいることを前提としている。
以下は、XHTMLモジュラー化機構[XHTMLMOD]に合致する、ruby要素の抽象定義である。 XHTMLの抽象モジュールに関する詳細な定義は[XHTMLMOD]で得られる。
要素 | 属性 | 最小内容モデル |
---|---|---|
ruby | Common | (rb, (rt | (rp, rt, rp))) |
rbc | Common | rb+ |
rtc | Common | rt+ |
rb | Common | (PCDATA | Inline - ruby)* |
rt | Common, rbspan (CDATA) | (PCDATA | Inline - ruby)* |
rp | Common | PCDATA* |
ruby
要素の最大内容モデルは次の通り。
((rb, (rt | (rp, rt, rp))) | (rbc, rtc, rtc?))
ruby
要素の最小内容モデルは、単純ルビマーク付けと一致する。ruby
要素の最大内容モデルの代替である(rbc, rtc, rtc?)
は、複合ルビマーク付けと一致する。
この抽象定義の、XHTML DTDモジュールとしての実装は、附記Aにある。 XMLスキーマ[XMLSchema]での実装は、実現可能になった時点で提供する。
ruby
要素ruby
要素は、インライン(テキストレベル)の要素であり、全体のコンテナとなるものである。rb
要素及びrt
要素、並びにオプションのrp
要素のコンテナとして働く(単純ルビマーク付け)か、またはrbc
要素及びrtc
要素のコンテナとして働く(複合ルビマーク付け)。
単純ルビマーク付けのケースでは、ruby
要素は、1つのrb
要素とそれに続く1つのrt
要素とのコンテナとなるか、または、1つのrb
要素、1つのrp
要素、1つのrt
要素、もう1つのrp
要素という1連なりのコンテナとなる。
rt
要素の内容はルビテキストとして受け取られ、ルビベースたる
要素の内容と、結びつけられる。rb
rp
要素の内容は、もしそれが存在するならば、無視される。
複合ルビマーク付けのケースでは、ruby
要素は、1つのrbc
要素と、それに続く1つあるいは2つのrtc
要素とを含む。各rtc
要素の子要素の内容はルビテキストとして受け取られ、ルビベースたるrbc
要素の子要素の内容と、結びつけられる。
ruby
要素は、共通属性のみを持つ。
共通属性には、例えばid
属性、class
属性、xml:lang
属性などがある。
共通属性が何であるかは、ルビを取り込むマーク付け言語に依存する。[XHTML
1.1]の場合、XHTMLモジュラー化の5.1節[XHTMLMOD]で定義されている。
rbc
要素rbc
(ruby base container) 要素は、複合ルビマーク付けにおいて、rb
要素のコンテナとして働く。1つのruby
要素には、1つのrbc
要素だけが出現できる。
rbc
要素は、共通属性のみを持つ。
rtc
要素rtc
(ruby text container) 要素は、複合ルビマーク付けにおいて、rt
要素のコンテナとして働く。1つのruby
要素には、1つあるいは2つのrtc
要素だけが出現でき、rbc
要素が表す単一のルビベースと結びつく、ルビテキストを表す。
rtc
要素は、共通属性のみを持つ。
rb
要素rb
要素は、ルビベースのテキストをマーク付けする働きをする。単純ルビマーク付けにおいては、ただ1つのrb
要素しか出現できない。複合ルビマーク付けでは、1つのrbc
要素に複数のrb
要素が出現できる。
精密なルビ表現において、各rb
要素は、対応するrt
要素と結びつけられる。
rb
要素は、インライン要素か文字データを内容として含むことができる。しかしruby
要素はその子孫要素となることが許されない。
rb
要素は、共通属性のみを持つ。
rt
要素rt
要素は、ルビテキストのマーク付けに用いる。単純ルビマーク付けでは、ただ1つのrt
要素だけが出現できる。複合ルビマーク付けでは、rtc
要素中に複数のrt
要素が出現でき、各rt
要素が、対応するrb
要素が表すルビベースに結びつくところの、ルビテキストを内容とする。
rt
要素は、インライン要素か文字データを内容として含むことができる。しかしruby
要素はその子孫要素となることが許されない。
rt
要素は、共通属性と、rbspan
属性を持つ。rbspan
属性は、複合ルビマーク付けにおいて、1つのrt
要素が複数のrb
要素にまたがることを許容する。属性値はゼロより大きい整数でなければならない。デフォルト値は1である。単純ルビにおいてはrbspan
属性を用いてはならず、単純ルビマーク付けなのにrbspan
属性があった場合、ユーザエージェントはこれを無視しなければならない。
rp
要素rp
要素は、単純ルビマーク付けのケースにおいて、ユーザエージェントがベーステキストとルビテキストとを区別するための手段が他にない場合の、ルビテキストの冒頭と末尾を示す文字を指定するために用いることができる。
パーレン(あるいはそれに類似の文字)が、受け入れられるフォールバックを提供できる。
この状況では、ルビテキストは、インラインでフォールバックのパーレンで閉じられた状態でのレンダリングに格下げとなる。これは、インラインでのレンダリングしかできない状況で、最も不適切ではないレンダリングである。複合ルビマーク付けにおいては、rp
要素を用いることはできない。
rp
要素は、共通属性のみを持つ。
フォールバックの目的でパーレンを用いることは、ルビテキストを示すつもりのテキスト列と、他の意図でパーレンで囲ったテキスト列との識別に関する混乱の元となり得る。文書の書き手やスタイルシートの作り手は、こうした混乱が起き得ることに留意し、心配なケースでは両義的にならないようなフォールバック用区切り子を選ぶようにされたい。
この章は参考情報である。
この章では、本書が定めるルビのマーク付けに沿って、ルビのレンダリング及びスタイリングについて、様々な観点からの検討を行なう。しかしながら、本書はルビの表示及びスタイリングのメカニズムについては何らの規定も行なわない。それは各スタイルシート言語の守備範囲である。 ルビをスタイリングするための整形プロパティは、CSSとXSLで開発中である。より詳しくは、例えば 作業中 の『CSS3モジュール: Ruby』[CSS3-RUBY]を参照されたい。
和文印刷の文脈におけるルビ整形の詳細については、 JIS-X-4051 [JIS4051]に記述がある。
「ルビ」という用語は、日本語では、ベーステキストの脇に視覚的にレンダリングされるテキストについてのみ用いられる。このようなケースに関する考察は、第3章2節(フォントサイズ)、第3章3節(位置)、第3章4節(ルビマーク付けの表現)で行なう。 この方法での表示は、可能な限り行なわれるべきである。 しかしながら、Webにルビを導入することは、伝統的タイポグラフィには存在しなかった現象や問題を引き起こす。本仕様書が定める構造的ルビマーク付けは、ルビ注がベーステキストの脇に常にレンダリングされるということを、保証できない。XHTMLでマーク付けされた文書を出力するデバイスには、現在も将来も、非常に多種多様なものがある。以下に、あり得るシナリオと、異なるレンダリングになる理由とを示す。
典型的用法では、ルビテキストのフォントサイズはベーステキストのフォントサイズのおよそ半分である。実際「ルビ」という名は、イギリス印刷界における5.5ptフォントの呼称に語源があり、これは一般的に本文に用いられる10ptフォントのおよそ半分の大きさである。
ベースとの相対性において、ルビテキストが出現し得る位置には、複数のパターンがある。なぜなら東アジアのテキストは縦書きにも横書きにもされるからである。ここでは、「上」「下」や「左」「右」ではなく、「前」「後」という用語を用いる。「前」及び「後」という語は、ベーステキストを含む行の「前/後」のことを指すと理解すべし。この関係を、次表に示す。
用語 | 横書き (左から右、上から下) |
縦書き (上から下、右から左) |
前 | 上 | 右 |
後 | 下 | 左 |
ルビ注は、最も多くの場合、ベーステキストの前に置かれる(図1.3及び図3.2を参照)。 時には、特に教育用のテキストにおいて、ルビ注がベーステキストの後に出現することもある。例えば下図(図3.1)のように。 中国語では、併音ルビがベーステキストの後に出現するのが一般的である。 ルビはまた、縦書き時にベーステキストの後に出現し得る(図3.3参照)。 以上全てのケースで、ルビテキストの書記方向は、ベースの書記方向と等しい。ベースが縦書きならば縦書きであり、ベースが横書きならば横書きになる。
図3.1: 日本の表意文字から成るベーステキストの後/下に出現するラテン文字のルビ
図3.2: 縦書き時のルビ(前/右)
図3.3: 縦書き時のルビ(後/左)
伝統的な中文では、横書き時においても"Bopomofo"ルビがルビベースの右側に出現できる。
図3.4: 横書きした伝統的中文における"Bopomofo"ルビ(ルビテキストは青/赤で明示してある)
この例で、Bopomofo声調記号(赤で示してある)が、更に分離した枠(Bopomofoルビの右側)に記されていて、「ルビのルビ」といった状態に見えることに注意されたい。このように見えるものの、両者はルビテキストを成す部分として符号化されている。この符号化についての詳細は、本書では示さない。
本仕様書は、ルビマーク付けがどのようにディスプレイされるかについては規定しない。一般に、ルビマーク付けの実際の挙動を定めるのには、スタイルシートを用いる。
注意。 ルビテキストのレンダリングについてはスタイルシートで制御すべきなのではあるが、書き手やユーザから何のスタイル情報も提供されない場合、視覚系ユーザエージェントは、1つしかルビテキストがない場合のルビテキストをルビベースの前に置くよう推奨される。これは単純ルビの場合である。2つのルビテキストがある場合、最初のルビテキストをルビベースの前にし、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
属性を用いたルビのマーク付け
スタイルシートを用いて、横書きであることと、読みをベーステキストの前にすること、注釈をベーステキストの後にすることを指定すると、上記のマーク付けは次のようにレンダリングされる。
図3.6: 横書きで1つのルビベースに結びつく2つのルビテキスト
ルビマーク付けを含む文書を、音声ブラウザや点字ユーザエージェントなどの非視覚系ユーザエージェントでレンダリングする必要が生じる場合もあるだろう。こうしたレンダリングを行なう状況では、次の点を理解しておくことが肝要である。
ユーザのニーズによって、テキストの読まれかたは、非常に早い「拾い読み」的なものから、大変注意深く詳細な読み方まで、様々であろう。そのため、非視覚系のレンダリングでのルビの扱いは、素早い読みにおいてルビを飛ばしてしまうことから、念入りな読みにおいてルビの構造と実存する文字とを詳細に説明することまでの、異なるものになるであろう。
ルビ注が読みを表すような最も頻出する事例においては、ベーステキストとルビテキストとを両方ともレンダリングすることは、好ましくない重複を生じるかもしれない。大きな辞書を備えた音声合成装置はベーステキストを正確に発音できるであろうし、他のケースではルビテキストによって示された読みに基づいて正しい発音を選択できるであろう。
すべてのルビテキストが発音を表すわけではない。異なる目的で用いるルビテキストについて、書き手は、class
属性を用いて区別をつけるべきである。
この点については、読みを示すのに用いたルビにclass="reading"属性を使う方法を上に示してある。
読みを示しているルビが、たとえ完全に発音を示す表記系で示されているように一見して感じられたとしても、正確な発音を生み出すものではない場合もあり得る。 例えば、Bopomofoは各ベース文字の各々と独立して結びついているにすぎず、文脈依存の音や声調変化は反映されないのである。 同様に、日本語の場合、文の主題を示す語尾で「わ」と発音されるものが「は」と綴られたり、長音を示すのに母音文字が使われるなどの変則的な綴りがある。 こうしたケースで、書き手が、実際の発音を示す目的に適うような特別なマーク付けを行いたいと考える場合もあるだろうし、この状況を正しく扱える音声系レンダリングシステムに処理を委ねたいと考える場合もあるであろう。
rp
要素の代替もし、文書の書き手が、ルビマーク付けをサポートしておらずまたCSS2 [CSS2]あるいはXSL [XSL]のスタイルシートをサポートしてもいないようなユーザエージェントに対するフォールバックに関心がないのであれば、rp
要素は必要とされない。
それでも、例えば出力機器の解像度が伝統的なルビのレンダリングには不向きであるようなケースで、フォールバックとしてルビテキストをパーレンで囲むことは可能である。[CSS2]を利用すれば、:before 及び :after 疑似要素 ([CSS2]、12.1節)の'content' プロパティ ([CSS2]、12.2節)を用いて、次に示すスタイル断片のようにしてパーレンを生成することができる。
rt:before { content: "(" } rt:after { content: ")" }
図3.8: rt
要素を囲うパーレンを生成するCSS2スタイルシート断片
この例では、rt
要素の周囲にパーレンが自動的に生成される。ここでは、上記のスタイルルールはルビテキストの行内での位置を定めるスタイルルールと併用されると仮定される。
パーレンの生成は、XSLT [XSLT]を用いても容易である。
この附記は参考情報である。この附記には、ラストコール文書のレビューで寄せられた質問や意見に基づく、設計判断について注記する。
例えば、 <rbc><rb>...</rbc> を <rb><rbc>...</rb> に変えてはどうか(rt/rtcも同様)という意見があった。 これは、ある意味で、より自然であるように見える。しかしながら、XMLでは、ある要素の内容は、混合内容(文字データと要素の双方、連続・出現の制約なし)であるか、または要素内容(要素のみ、制約あり)であるかのどちらかとなる。 これはすなわち、<rb>が<rbc>のみを含むこととなるか、文字データと行内要素のみを含むこととなるか、を意味する。
最小内容モデルからrp
要素を削除するようにとの多数の意見が寄せられた。考慮対象とはなったが、次の理由により否決された。
rp
要素を認知し除去することは、極めて簡単に実装でき、実装上の負担は最小限で済む。CSSとXMLの双方が、rp
要素を簡単に除去できる機構や表示しないようにする機構を提供している。
要素名変更の提案、特に<ruby>を<gloss>に変えてはどうかというものがあった。 しかし、確かに実際ルビマーク付けが注釈用に必要なマーク付けに類似している点があるとはいえ、その目的で設計しているわけではない。
この附記は参考情報である。
歴史的な理由により、rb
要素の開始タグ及び終了タグを抜かしてルビマーク付けを生成するようなオーサリングツールがあるかもしれない。
<ruby> A <rp>(</rp><rt>aaa</rt><rp>)</rp> </ruby>
上のようになってしまい、下のようにはならないというのである。
<ruby> <rb>A</rb> <rp>(</rp><rt>aaa</rt><rp>)</rp> </ruby>
前者のマーク付けは、本仕様には適合しない。しかしながら、こうしたオーサリングツールが生成した文書との互換性に気を使うユーザエージェントは、前者のマーク付けを後者のように書かれたものとして扱ってくれるであろう。
この附記は参考情報である。
この附記は参考情報である。
http://www.w3.org/TR/2001/WD-ruby-20010216からの変更点: 編集上の僅かな変更のみ。
http://www.w3.org/TR/1999/WD-ruby-19991217からの変更:
実際のマーク付け定義での変更は、単純ルビマーク付けの内容モデルを (rb, rp?, rt, rp?)
から (rt |
(rp, rt, rp))) に変更し、ゼロまたは2つのrp
要素は許すが単一のrp
要素が出現することを許さないようにしたこと。
仕様書全体は、前の版から逸れないようにはしてあるが、実質的に書き直された。主要な編集上の変更は次の通り。
この章は参考情報である。
Takao Suzuki (鈴木孝雄) と Chris Wilson からは、前のドラフトについて編者としての貢献があった。
本仕様は、W3C I18N作業部会、とりわけ Mark Davis 及び Hideki Hiura (樋浦秀樹) の助力と、W3C I18N関連部会の助力抜きでは、成り立たなかった。
他に、 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と互換性のない特殊記号を用いた代替的マーク付けがある点。もう1つは、rp
要素が許されない点である。
有用なラストコールコメントが、HTML作業部会、CSS作業部会、XSL作業部会、WAI P&F作業部会、Steven Pemberton、 Trevor Hill、 Susan Lesch、 Frank Yung-Fong Tang から寄せられた。
ルビマーク付けに属性を用いる早期の提案は、[DUR97]に記されている。