interlinear annotation

interlinear annotation character

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

代替

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

仕様書

意味

[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 textannotated 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 の規定はあやふやで用語も揺れまくっていて、 行間を読む他ない惨状です。 HTMLruby を知っていれば、だいたい何をやりたかったのかは推測できます。

構文

[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] annotatedannotating text改段落を含むことはできません (>>16)。 空文字列でも良いのかは定かではありません。

文脈

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

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

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

メモ

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

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

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

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

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

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

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

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