日本語を縦組みしたときに、文字の方向をどう決定するかということについて、何回もブログで書いてきましたがこれはかなり悩ましい問題です。CAS-UBでも縦組のPDFを生成したり、EPUB3には縦組みレイアウト用CSSを指定できますので、早急に整理しなければならないと思っています。
UnicodeやCSSワーキンググループでは、この検討が精力的に行なわれており、UnicodeのUTR#50が先日（5月17日）ドラフト第5版になりました。
http://www.unicode.org/reports/tr50/tr50-5.html
今回の大きな変更点は、レポートの表題が「Unicode Properties for Horizontal and Vertical Text Layout」に変わったことです。従来は、「Unicode Properties for Vertical Text Layout」でしたが、今回から横書きでの文字の方向に関する記述が追加になりました。
横書きプロパティが追加になりました。
○プロパティ
横書き（Horizontal Orientation、HO）：横書き用
縦積み方向（Stacked Vertical Orientation、SVO）：文字がほとんど正立する世界における縦行用
混在縦組み方向（Mixed Vertical Orientation、MVO）：東アジア、特に日本、中国、韓国の縦行用
UTR#50はUnicodeの文字に対して３つのプロパティにおける文字方向のデフォルト値を規定するものです。
○プロパティ値は次のように規定されます。
U：コード表に表れるのと同じ方向で、正立表示する文字
R：コード表を時計方向に時計方向に90度回転して、横倒しで表示する文字
L：コード表を時計方向に反時計方向に90度回転して、横倒しで表示する文字
T、Tu、Tr：単に正立または横倒しではなくて、縦組みで使うときはコード表とは異なるグリフを必要とする。Tuはフォールバックとしてコード表のグリフを正立で使うことができる。Trはフォールバックとしてコード表のグリフを時計方向に90度回転して使うことができる。
Unicodeの各文字に対するプロパティ値のデータ表が提供されています。
○http://www.unicode.org/reports/tr50/tr50-5.Orientation.html
第5版では、プロパティ値のデータ表に、HOの列が追加になりました。一方、MVOの値は、これまでA案とB案提案されていましたがB案に一本化されました。
■問題点
UTR#50には、かなり大きな問題があります。
その１：SVOとMVOが明確に規定されていないこと。
原文は次のようになっています。
SVO：「… intended to be used for vertical lines in those parts of the world where characters are mostly upright. 」
MVO：「… intended to be used for vertical lines in East Asia, and more specifically in Japan,…」
MVOについてはサンプルの図３があり、和欧混植の組版を意味していることは明らかです。しかし、SVOの定義でいうところの「文字がほとんど正立する世界」とは一体どこのことなのでしょうか？MVOの定義には「東アジア特に日本の縦書きの行」とありますので、するとSVOは日本は属さないと読めてしまいます。
このあたりの定義をもっと明確にする必要があります。たとえば、SVOは和文のみ、MVOは和文と欧文が混ざるときというように。しかし、おそらく少なくとも日本語の書籍についてはSVOという世界はほとんど存在しないので、日本語の書籍ではあまり意味がない概念でしょう。
その２：方向特性値の決め方がまずい。
方向特性値は、「This default determination is based on the most common use of a character, …」とあります。つまり、デフォルトの方向は文字の最も一般的な使用法に基づいている、とのことです。しかし、最も一般的な使用法をどうやって判断しているか理解できません。
たとえば、プロパティ値のデータ表で見ますと、アラビア数字（ASCIIコード範囲）は、MVOで「R（横倒し）」と決めています。
MVOのサンプルである図３（Figure 3. Japanese vertical text）には数字が3箇所に出てきますが、いづれも正立で、横倒しになっていません。アラビア数字をMVO:Rとするのは、このサンプル図に矛盾しています。たった１枚の図で判断するなよ、と言われるかもしれませんが、しかし、日本で実際に販売されている縦組みの雑誌や書籍では、アラビア数字の大半は正立です。これは市販の縦組本を少し調査すればすぐに分るはずです。
たとえば、このブログで先週調査結果を報告した「刑務所なう。」には、アラビア数字が数百箇所はでてきますが、横倒しになっている箇所はほとんど例外的と言って良いほど少なく、アラビア数字の99%以上は正立しています。
○「刑務所なう。」にみる縦組みにおける英数字・記号の向きを参照のこと
方向特性値を「（市販の書籍や雑誌における）最も一般的な使用法」とするならば、例えばアラビア数字（ASCIIコード範囲）は、間違いなくMVOで「U（正立）」にしなければならないでしょう。そうするとUTR#50の「最も一般的な使用法」はどうやって決めているのでしょうか？
もしかすると、InDesignのデフォルトが横倒し？そうすると、DTPオペレータが毎回せっせと数字を立てていることになるのですが。
ここで白状しますと、AH Formatterもアラビア数字（ASCIIコード範囲）は、MVO：Rなのです。困ったな。
つまり、いままでは英数字はASCIIコード範囲は縦書き時横倒し、互換コード範囲は正立という方式がずっとすべてのアプリケーションの実装となっていたのです。で、方向特性値を「（ベンダにとって）最も一般的な使用法」と定義すれば矛盾はなくなるのですが、それで良いのだろうか？いや、それではだめだろう、ということなのです。
こんにちは。
＞もしかすると、InDesignのデフォルトが横倒し？そうすると、DTPオペレータが毎回せっせと数字を立てていることになるのですが。
そうですが、実際は段落スタイルの「自動縦中横設定」で、例えば「2桁までは縦中横にする」ということを設定します（半角入力数字の場合）。
半角入力のアルファベットに関しても、「縦組み中の欧文回転」という機能で自動的に正立させることができます。
もちろん、全角入力数字（やアルファベット）の場合は正立します。
こんにちは。
そうなんですね。
わざわざデフォルト横倒しにしておいて、プログラムで立てるというなんとも非効率な世界ができてしまっているのですね。
だけど、自動組版やブラウザ（自動組版の一種）ではこれでは困るのですよ。
そうでしょうね。
でも、本来、そのあたりはビューワ（ブラウザ）の実装に関わる部分ではないのかと考えたりもしています。
極端に言えば、先の「何桁までを縦中横」にするという部分を読者に決定させるような……。
あくまでもテキストはシンプルに……。
英数字のデフォルトを正立にしても、テキストが変わるわけではないのです。
「縦中横」をクリックしたくなる頻度が、どの位の割合になるかですが、90％位の割合で縦中横にするのであれば、縦中横をデフォルトにしておくほうが便利じゃないですか？
エンドユーザーの中には、文字を立てる機能があることに気がつかない人もいますし。
いえ、（縦組み）和欧混植の欧文中のアラビア数字のことも考えねばなりませんので、やはりデフォルトは横倒しで、
——
前後が和字の1桁や2桁を縦中横とする……
さらに、場合によっては（前後が和字の）3桁以上の連数字は1字ずつ回転……
——
ということになるのではないでしょうか？
これらをビューワ（ブラウザ）が実装し、自動的に処理するもいいでしょうし、読者に選択して貰うのもいいでしょう……ということです。
>いえ、（縦組み）和欧混植の欧文中のアラビア数字のことも考え
>ねばなりませんので、やはりデフォルトは横倒しで、
MVOは次の二つのフレーズが含まれるはずです。
１．和文フレーズ
JLREQでcl-19漢字類に分類される文字（英数字を含む）が正立し、全角形のメトリックスで配置されるフレーズ
２．欧文フレーズ
同cl-27欧文用文字に分類される文字からなるフレーズで、横倒しとなり、英数字はプロポーショナルのメトリックスで配置されるフレーズ
１と２のフレーズでは英数字のデフォルトの方向が異なる、ということを認める必要があると思います。
つまり、MVOを定義しておきながら、「the most common use of a character」というところに本質的な無理があると思います。
UTR#50 ではプロパティ値のデータ表を見ても「MVO で英数字を U にしたいときは全角文字にしてください」と言っているように読めます。この基本方針は変わりがないようです。
そもそもこれを批判しているんですよね？
・縦組/横組の切換えを考慮すると、英数字はプロポーショナル幅の１種類だけにするべきであり、全角文字は使うべきではない。
・全角文字を一切使わないことを前提にすると、プロポーショナル幅の英数字がすべて MVO で R になっているため、縦組で正立させるためのタグだらけになってしまう。
私としは、基本方針そのものの相違を論点にした方がいいように思います。
＃蛇足
「英数字を U にしたいときは全角文字に」は、和文組版の手法を無批判に踏襲している印象を私も感じます。
しかし、批判相手は UTR#50 であって、DTP ではないでしょう。感情にまかせて批判対象を拡大することに益があるとは到底思えません。
>そもそもこれを批判しているんですよね？
そうですね。ここを何とかしないといけないと思います。
いままでの実装の多くが、ASCII文字とその互換文字で方向を切り替えているという仕組みに依存しているということは、横書きと縦書きの切り替えができない、という点で問題です。
特に、DTPを批判したつもりはないですが、誤解を招いたとしますと、私の文章力が足りないと反省します。
数字についてMVO=Uとしたら、「AH Formatter V6.0MR2」の欧字は横倒しで数字だけ正立という変なことになってしまうので、ありえないです。
MVOは欧字など横書き用スクリプトの文字を横倒しにするモードにおけるデフォルトの文字の向きということであり（そのような説明もないことが問題だけど）、欧字の仲間である基本ラテン文字（ASCII範囲）はすべて横倒しで決まっています。
MVOで議論になるのは、ASCII範囲外で、JLREQの文字クラスのcl-19漢字類とcl-27欧字類の両方に含まれるような記号類をどうするかで、私は、MVOは和欧混植のためなのだから、欧文とともに使われることが多い記号類はMVO=Rがよいと考えるのですが、今のドラフト仕様は、MVOを混植用ではなく、東アジアで一般的な縦書き（英数字を正立にするには全角文字コードポイント使用）のためという考えのようで、東アジア従来文字セットに含まれる記号類は正立という方針などから§¶†‡‰‱™©®など欧字や数字（MVOでは横倒し）とともに使われることが多い記号類でも正立だったりします。だけど、従来日本語フォントでの縦書きで正立になっていたギリシャ文字やキリル文字は横倒しなので、若干整合性に欠ける感じがします。
>MVOは欧字など横書き用スクリプトの文字を横倒しにするモードにおけるデフォルトの
>文字の向きということであり（そのような説明もないことが問題だけど）、欧字の仲間で
>ある基本ラテン文字（ASCII範囲）はすべて横倒しで決まっています。
MVOは、和文混交（和文の中に、欧文など横書き用のスクリプトが入るとき）の縦組モードにおける、「横書き用スクリプト」のデフォルトの向きである、という想定が「暗黙に」なされているのですよ。
暗黙にそのような想定があるにも関わらず、文章上「the most common use of a character」と規定しているので矛盾してしまうのです。実際には、most common じゃないのだから。（most commonというような、曖昧な言葉を仕様書に盛り込むのも問題。most commonって一体なに？）
和欧混交の縦組みモードでは、和文フレーズ中の英数字はデフォルト正立であり、欧文フレーズの中の英数字はデフォルト横倒しとすれば解決できるのですが、というかそれ以外にまともに使えるようにする方法はないでしょう。