W3CのCSS WGのメーリングリストに、text-orientation:uprightがforced uprightになり強制アップライトになるということが決まったという話が出ています[1]。その理由はUTR#50[2]では、SVOを今後定義しないからということらしいです。
WGの議事録を読みますと、どうやら、UTC（技術委員会）はUTR#50では当面日本語を優先すると決めたようです。で、SVOは日本語用ではないので削除するという論理のように思います。これで良いのでしょうか？
これに関連していくつかの基本的な疑問があります。
１．第一に、現在のUTR#50には、MVO、SVO、HOという３つの表が提案されています。仕様案の文章、編集者のEric、その他の関係者の発言から推測すると、この３つをどうやら言語別に使い分けることになっているようです。
・MVO：日本語を含む東アジア向け
・SVO：英語向け
・HO：MongolianやPhags-Paのような縦書き専用言語向け
Unicodeは文字コードの国際標準です。つまり、全世界で共通のはずなのに、Unicodeで表現したテキストファイルの文字の向きの解釈が言語依存で良いのでしょうか？
でもし仮に、どうしても言語別に表を作らざるを得ないとすると、Unicodeで表したテキストファイルはどの言語向けかを指定しないと解釈できなくなります。しかし、現在のUTR#50ではこの３つの表をどうやって使い分けるかの指定方法はなにも言及されていません。
これはかなり基本的なことだと思いますが、誰も指摘していません。
２．日本語でMVOとSVOを両方使うという案
一部に、日本語でMVOとSVOを両方使えるようにして、これを切り替えたらどうかという意見を述べる人もいます。これは、UTR#50の仕様の元の狙いとは別の使い方を意図しているものです。
しかし、そうなると、Unicodeで表した日本語テキストファイルが、①MVOを前提にしているのか、②SVOを前提にしているのかを知る方法が必要になります。
上の意見を表明する人が想定しているのは、CSS Writing-modeのtext-orientationの機能を使って指定するということです。しかし、そうなるとUnicodeテキストファイルの文字の向きがCSSのWriting-modeの機能なしでは解釈できなくなります。
文字コードはあらゆるテキストをコンピュータで取り扱うための基盤です。従って、本来、Unicodeテキストファイルは、独立した存在として、それだけでコンピュータ間の情報交換ができる必要があります。しかし、CSSのWriting-modeに依存してしまったら、これはもはや文字コード標準とは言えないでしょう。
Unicodeにおいて、CSSのtext-orientationの機能のためのデータセットを定義するのはおかしな話です。
これを譲って、UTF#50で文字方向デフォルト・セットを定義するとしたら、Unicodeテキストファイルがどのデフォルトを使っているかを示すマーカー文字コードを提案する必要があるでしょう。
３．MVOの問題点
さて、現状では日本語についてはMVO推進者の力が強くなっています。なお、MVOについても個別の文字方向についての意見が一致しているわけではないので、一律にMVO推進者といえるかどうかは留保します。
現在のMVO（[3]の表）では表でMVO=Rになっている文字（基本ラテン文字、拡張ラテン文字、ギリシャ文字、キリル文字など欧米の文字やアラビア数字などの数字）は、縦書きで横倒しがデフォルトとなり、MVO=Uの文字が正立になります。
従って、もし仮に、UTR#50で現在提案されているMVOがデフォルトになったとすると次のことがおきます。
(1) 印刷関連の標準であるJIS X4051では横書きでは一般に欧米の文字はプロポーショナル形[4]で表記することになっています。そこでUnicodeでテキストファイルを横書きで用意するときは、欧米の文字のうち基本ラテン文字とアラビア数字はASCII文字コードで表記するのが基本となります[5]。
(2) この横書きテキストファイルを縦書きにすると、欧米の文字やアラビア数字はすべて横倒しになります。
(3) 欧米の文字の中で、基本ラテン文字とアラビア数字は全角形の文字コードを使って表すことで正立させることができます。しかし、次の問題が残ります。
①このためにはテキストファイルを横書き用と縦書き用の2種類を用意する必要があります。最近の日本語文章にはラテン・アルファベットとアラビア数字が溢れかえっていますので、これはかなりわずらわしい問題です。
②さらに、欧米の文字の中で、英語にはないフランス語やドイツ語専用の文字（拡張ラテン文字）、ギリシャ文字やキリル文字は横倒しのままとなります。円マーク、ポンドマークなども寝たままとなります[6]。
４．FormatterClubのご案内
ということで、縦書きの文字の向きはかなりややこしい問題なのですが、こうした問題をどういう風に理論的に整理するか。そして、どうやって実際に文字の方向を指定すると一番便利になるのでしょうか？
次回のFormatter Clubで時間をとってもらい、このことについて調べた結果を発表したいと思っています。
ぜひ、多くの方にご参加いただき、ご意見を伺いたいと思います。
[1] Minutes and Resolutions 2012-08-15 Wed PM II: Writing Modes, …
[2] UTR #50: Unicode Properties for Horizontal and Vertical Text Layout
[3] http://unicode.org/reports/tr50/tr50-5.Orientation.html
[4]プロポーショナル形と混同しやすいのが半角文字です。半角文字は印刷の専門用語では全角文字の半分の幅という文字の形を意味します。しかし、Windowsの半角英数は、ASCII（X0201の一部）文字コード、いわゆる1バイト文字＝半角文字コードで定義する文字を意味します。このように半角文字には、①文字のコード（半角文字コード）を表す、②文字の形を現すという2通りの意味があります。この２つは本質的な相違なのにも関わらず混同して使われています。例えば、ギリシャ文字（α、β、…）、キリル文字（а、б、…）はJIS X0201にはありませんので、半角文字コードはありません。
[5] 印刷は文字を紙に表す技術です。従って印刷の標準では文字コードを定めているのはなく文字の形を決めていると解釈するほうが適切でしょう。このことは仕様には明記されていませんが、そう解釈しないといろいろとつじつまが合わなくなります。で、文字の形と文字コードの対応関係は１対１ではありませんので、データを用意する方法は他にもあるはずです。
[6] Microsoft Wordで縦書き指定すると、これらの文字の向きはフォント依存です。欧文フォントを指定すると横倒し、和文フォント（IPA明朝、MSゴシック）を指定すると拡張ラテンは横倒し、ギリシャ文字・キリル文字・円マーク・ポンドマークは正立です。
[7] ちなみにこのことを昨日2人に相談しましたら、2人とも縦書きなんか未来はないし、意味がないのでやめるほうが良いといわれてしまいました。日本語の縦書きは風前の灯かな？しかし、組版ソフトのベンダとしてはどうしても避けて通れないんですよ。