HTML5(2010/06/27作業ドラフト)のルビ仕様がcomplex rubyを廃して入れ子対応となってゐる点について、JIS X 5042:2000とW3C Ruby Annotation仕様(2001/03/31勧告)の調整を図られた家辺勝文氏がご自身のウェブサイト「ウェブノート * 2010」において、次のように記されてゐる。
TML5 の ruby element 方式は、現状では Ruby Annotation における complex ruby を含んでいません。
「EPUB仕様の日本語組版拡張を目指して」(Version 0.8)
という電子書籍のためのマークアップ試案では、HTML5 ruby element のネストで「両側ルビ」を表現しようとしていますが、 JIS X 4052:2000 および Ruby Annotation の原案作成過程で「ネスト」方式には不具合があることがわかったため、 complex ruby の構造定義に至ったという経緯があります。上記仕様は、そもそも日本語文書の組版仕様としては簡略すぎる内容ですが、 それさえ既存の規格類、W3C勧告の内容、成立経緯をまともに調べているのかどうか疑問です。 ルビ・マークアップに限っていえば、将来的にHTML5に complex ruby も含めたいのであれば、 要する ruby element としては、Ruby Annotation 方式をそのまま採用すればいいのです。
ルビのマーク付けに関して家辺氏が過去に記された2つの文書を眺めてみても、具体的にcomplex rubyが必要とされる事例は示されてゐない。
『“JIS X 4052:2000(日本語文書の組版指定交換形式)”と “Ruby Annotation, W3C Recommendation 31 May 2001”におけるルビ・マークアップ方式の開発』― テキスト形態構造の交換可能性と国際整合性を求めて ―
『ルビ付きテキストのマークアッフ』―組版処理対象要素の構造化と複数の構造モデルを内包するXHTML Ruby DTDモジュール―
実は今年3月、(日本語で)HTML5を考えるW3Cメーリングリストに、Webkit実装を手がけるRoland Steiner氏が、複雑ルビと入れ子ルビの問題を整理する記事を書かれてゐた。複雑ルビの実装には幾つかのレベルがあるといふ。
- 親文字列の「後」につくルビを実現すること
- 親文字列の「前」と「後」の2つのルビを実現すること
- 親文字列の「前」あるいは「後」に複数のルビ(重ねルビ)を実現すること(仕様に明記されてゐないがMLでの議論の過程で指摘された)
- 親文字列の「前」と「後」に各々異なる係りのルビ振りを実現すること
まず、@koueiheiさんによるルビの例。「労働者階級意識」といふ親文字列のうち、「労働者階級」に「プロレタリアート」といふルビ。同時に「階級意識」に「かいきゅういしき」といふルビ。これは入れ子方式ではマーク付けできない。
もっとも、日本語でも英語でも「階級」と「意識」は2つの単語に分解できるんぢゃないか、したがって無理にcomplex rubyで扱ふ必要な無いんぢゃないか、といふ指摘もあらう。
では、@MnjaMniaさんによる次の事例はどうだらう。
ボーカロイド重音テトの音声データは「小山乃舞世(おやま のぶよ)(おやまの まよ)」さんのものです。
ぎなた読みが可能な漢字表記の名乗りについて、どう読んでもよいというスタンスであるため、「小山・乃舞世(おやま・のぶよ)」でもあり「小山乃・舞世(おやまの・まよ)」でもあるといふ状態であるらしい。
先日の記事に記した通り、JIS X 4052:2000の解説4.7には、次の記述がある。
親文字の両側にルビが組まれる指定を
の入れ子で指定する方法では、片側のルビに対応する親文字列と、反対側の文字列に対応する親文字列とが食い違う場合に記述できなくなる。この入れ子による指定方法ではなく、W3C案の親文字列を分割するRB要素の数を数えるrbspan属性を使用する指定方法のほうがよいのではないか。
この「食ひ違ひ両側ルビ」が、可能性の問題ではなく具体事例として存在する以上、やはり「五百年先まで使う」ため、HTML5仕様にはcomplex rubyが必要なのではなからうか。
