[35] Unicode には annotation characters と称する特別Specialsな文字があります。 ルビを記述することを想定した並列文字列構造の一種のようですが、 ほとんど使われていません。

代替

[25] ほとんど実装されていないので、使うべきではありません。 ルビは HTML の ruby 要素など、 マーク付け言語などの機能によって記述するべきです。

仕様書

意味

[2] interlinear annotation は、 annotated 文字群の列に関係付けられた annotating text によって構成されます。 >>1 paired stateful controls です。

[3] 通常の編集やテキスト処理のアルゴリズムにあっては、 annotated 文字群はテキストストリームの一部として扱います。 >>1

[8] 適合実装は、 annotation character に対応する場合にあっては、 base text を annotate されていないテキストストリームの一部である場合と同様に解釈します。 >>1

[7] annotating text も内容の一部ですが、 テキスト処理の一部または全部においては主たるmainテキストストリームの一部を構成しません。 >>1

[4] ただし、 annotating text 中の文字は、 基底テキストbase textと同種の配置、 テキスト処理、 編集のアルゴリズムでアクセス可能です。 >>1

[9] 適合実装は、 annotation character に対応する場合にあっては、 annotating text 中の annotating character を通常の Unicode の意味semanticsによって解釈します。 >>1

[5] annotation character は、 annotating text と annotated text を区切り、 これを annotation の一部として示すものです。 >>1

[10] U+FFF9 INTERLINEAR ANNOTATION ANCHOR は、 interlinear annotation の前に来る anchor 文字です。 >>1

[11] U+FFFA INTERLINEAR ANNOTATION SEPARATOR は、 テキストストリーム中の base character 群を次の annotation character 群から区切るものです。 >>1

[12] U+FFFA は複数あっても構わず、 複数部分multipartの annotating text の各部を区切ります。 >>1

[13] U+FFFB INTERLINEAR ANNOTATION TERMINATOR は、 annotation object を終端する (通常のテキストストリームに復帰する) ものです。 >>1

[6] annotation character は、 外部out-of-band情報が文字ストリームに関連付けられているときに内部処理で使います。 annotation の正確な性質や書式付けformattingは、 平文ストリームの一部ではない追加の情報に依存します。 これは U+FFFC OBJECT REPLACEMENT CHARACTER とよく似ていますが、 U+FFFC はこの文字によって不透明なオブジェクトを隠すのに対し、 annotation の場合それ自体はテキストなのであります。 >>1

[26] Unicode Standard の規定はあやふやで用語も揺れまくっていて、 行間を読む他ない惨状です。 HTML の ruby を知っていれば、だいたい何をやりたかったのかは推測できます。

構文

[17] anchor 文字は、 対応する terminator 文字の前になければなりません。 >>1

[19] annotation は入れ子にして構いません。 >>1

[27] interlinear annotation
  1. U+FFF9
  2. annotated
  3. +
    1. U+FFFA
    2. annotating text
  4. U+FFFB

[29] annotated と annotating text に改段落を含むことはできません (>>16)。 空文字列でも良いのかは定かではありません。

文脈

[28] annotation character は、 通常は末端利用者に直接入力、編集されません。 一般的には応用がテキストの選択と注釈付けannotatingの利用者インターフェイスを提示し、 挿入と管理を行うものです。 >>1

[14] annotation character の平文における使用は、 送受信者間の事前の合意当事者間の合意がある場合を除き、 内容が誤解されるおそれがあるため、 強く非推奨strongly discouragedです。 >>1

[15] annotation character を除去するだけでは読めない結果が生成されたり、 最悪、意味が逆になってしまうかもしれません。 平文の受信者は、 入力中のすべての文字をそのまま残すか、 interlinear annotation character と annotating text を削除するかのいずれかとするべきです。 平文の出力時に送信者が受信者を知らない場合、 interlinear annotation character と annotating text を削除するべきです。 >>1

処理

[16] 実装は、 anchor 文字の後、 terminator 文字の前に改段落が出現した場合、 開いている annotation を閉じなければなりません。 >>1

[18] 組になっていない anchor 文字や terminator 文字は、 無視するべきです。 >>1

[20] anchor 文字と terminator 文字の組の外側に出現した separator 文字は、 無視するべきです。 >>1

[30] 照合では、 annotation を整列キーとして使うことを想定する特殊な場合を除き、 無視するか、 任意選択により前処理して tie breaker としてのみ使うこととするのが普通です。 annotation base character 群は無視せず、 通常のテキストとして扱うことが重要であります。 >>1

レンダリング

[21] 書式付けformattingに関する情報は、 上位層プロトコルによって提供されます。 配置の詳細は実装定義です。 正確な書式付けのために必要な追加情報は文字ストリーム中に現れず、 外部out-of-bandに示されるかもしれません。 従って annotation marker は別情報源の情報にアクセスできる実装のための placeholder として機能するのです。 >>1

[22] 書式付けその他行組版の特殊機能については JIS X 4051 で議論されています。 >>1 と説明されていますが、 JIS X 4051 のルビのモデルに annotation characters がどう当てはまりどう処理しどう表示するべきなのか、 説明が無さすぎます。

[23] Unicode Standard の利用例図 >>1 にある通り、 ルビとしてレンダリング文字のレンダリングされることが想定されていますが、 利用方法は実装依存となっていて Unicode Standard は完全に丸投げしています。

[24] 意図通りに正しくレンダリングする実装があるのかは不明であり、 主要な実装では皆無です。外部情報が必要とされ、 具体的なことは何も定められていないのですから、 実装できるはずもありません。

[34] 未対応の実装は、 通常の未対応の文字のときのように、 可視的なグリフを表示するべきshouldです。 そうしなければ境目がわからなくなって誤読を招くおそれがあります。 >>33

[31] bidi アルゴリズムは、 interlinear annotation を annotated text に置き換えた上で各々の annotated text が視覚的に連続するよう bidirectional format control character で囲んだ主たるテキストに適用するべきであり、 更にそれぞれの annotating text に別個に適用するべきであります。 >>1

実装

[38] 5-0-5. Solstitium(txt→縦書きPDF変換ソフト), , http://www.akenotsuki.com/eyeben/fonts/solstitium.html

歴史

[45] , に Junichiro Kida が 8th Unicode conference で日本文化におけるルビについて講演しました >>47 #page=3。 これが大いに話題になりました。

[46] ここから分岐 ruby=""

[44] >>43 この時点では最終版より複雑なものが書けた。提案者 Asmus Freytag は Unicode 役員。

[52] 頃まで Microsoft 社員。

[54] >>53 会議踊ってんなーw

[51] >>50 にはこの他にもいくつか関連文書が掲載されているが、本文は非公開。

メモ

[36] この機能はプレインテキストでの使用は強く非推奨とされています。 特定のアプリケーションで、あるいは内部処理で利用することが想定されているようです。 しかしながら、 この機能で記述できるルビは、現実に利用されるもののごく一部でしかなく、 貧弱です。 アプリケーション依存の情報を追加して利用することが想定されているようですが、 アプリケーション依存の仕組みによるのであれば、 アプリケーションのネイティブの仕組みの方が扱いやすいでしょうから、 敢えてこの機能を使う理由がありません。 実際に HTML はこの機能を使わず、 HTML の要素の仕組みに載せた ruby 要素を使っています。 つまるところ、 この機能が便利に使える場面はありません。

[37] もうちょっとうまいことモデル化して定義してあれば、 bidi 制御用の文字のようにプレインテキストでもそれ以外でもルビ状構造をうまく扱える世界が実現していたかもしれないのに、 残念なことです。

[39] 21世紀初頭にこれが出てきたときこんなの誰が実装するんだ阿呆か?みたいな空気だったそうですが(実際誰も実装しないで死んでったわけですが)、 bidi は自動で出来ないところは制御文字みたいなやつ使っててみんな実装してるのだから、 ルビも意外とこの方法で良かったかも知れんですよね。知らんけど。

bidi もそれはプレインテキスト用で HTML では要素使えよってことになってますけど、 ルビも制御文字みたいなのと HTML要素の2段構えで全然良かった。

[41] 日本で日本語使って生活してればルビが日本語に不可欠な存在だってのは誰でもわかることで、 20世紀の情報機器があまり対応してなかったりした (そして21世紀に入って何十年か経った今もいささか厳しい) のはルビがない日本語の処理にも苦労してたからで、 要らなかった、オプションだったからでは決してなくて。

プレインテキストにルビ要らんやろってのはテキストは線形っていう欧米中心主義なわけでしょう。 それは bidi で破綻したんだし、日本語の縦書きでも破綻してるんだから、 何の意味もないやせ我慢でしかない。 コピペで別アプリにルビ付きで移したいし、 漢字変換の辞書にルビ付きで登録したいし、 SNS にルビ付きで投稿したいよね。

[40] ルビを文字コードで表すのがうまくいってれば、次は縦中横とか横中縦とかも bidi みたいに文字コードで記述できるようになってたかもしれんのにねえ。

[42] ARIB STD-B3のルビは対象文字列の前後を制御文字で括る形式でした。 ただし親文字列とルビ文字列は文字コードとは別のパケット構造で区切られていました。

[57] ほとんどすべての振り仮名は漢字に対して仮名2,3文字と決まっているのだし、そうでないものも一般的な日本語文で出現するパターンは限られているのだから、それを GSUB と GPOS でがんばれば今や OpenType フォント1つで「実装」できちゃいそうでは? もちろんこの方法には色々な限界があるのだけれども、それが問題になるところでは HTML の ruby でも Microsoft Word でも使えばよくて、今の普通の plain text で振り仮名を全く使えないという問題は8割くらい解決できればそれでいいっていう考え方もあるんじゃないかな。

[58] (縦中横も専用の符号位置がどこかにあれば、同じ方法で「実装」できそうだね。ただし縦書きは各種ソフトウェアの実装状況が横書きよりも宜しくないのがネックになるかも。)

[59] 漢文も難題とされてきたけど、 >>57 の手法でいいのであれば、 interlinear annotation と例の使い道のわからない漢文ブロックの文字を活かして plain text でもかなりのことができちゃうんじゃないかなあ。