先日、UTR#50のフォーラムに「The approach of UTR#50 is different from Japanese standards」（UTR#50のアプローチはJIS X4051と異なる）というコメントを投稿した[1]ところ、次のような質問がありました。回答を直接英語で書くのは面倒なので、日本語で書いてGoogle Translationで翻訳してみようと思います[2]。うまくいくと一石二鳥だけど。（で結論としては、まだまだという感じですがとりあえず下訳的につかって修正したものを投稿しました[3]。まあ、私の英語力はそんなに高くないですので、便利といえば便利です。）
質問1. なぜ、我々の世界をJIS X 4051に限定する必要があるか？
質問2．UTR#50またはMVOが役に立たないというのであれば、その理由が分からない。
回答1．世界全体の言語の中で、文字を縦書きする言語は比較的少ない。現時点では、縦書きを採用する言語の中で、世界中で最も多くの人が使っているのは日本語である。過去においては縦書きで最も多く使われる文字は中国の漢字であった。また漢字文化圏の周辺には漢字以外にも縦書きする文字が多数あった――満州文字、モンゴル文字、西夏文字、契丹文字、ハングル、チュノムなど。しかし、中国本土の中国語は漢字の簡体字化に伴い、横書きに移行してしまった。また、周辺部の縦書きする文字の多くは消滅した。この結果、縦書きする文字は減っているのである。
縦書きの中に、横書きしかできない文字をどのように配置するかは非常に難しい問題である。これを正しく規定しているのはJIS X4051のみである。「日本語組版処理の要件」（JLReq）は、和欧混植に関する規定に関して、残念ながらJIS X4051よりも劣っている。
こうしてみると、JIS X4051は縦書きの中に横書き専用文字をどう配置するか――日本語組版でいう和欧混植――を正しく仕様化した世界で唯一の文書であるだろうと思う。縦書きの中に横書き文字を配置する方法に関して、JIS X4051をリスペクトするのは当然である。
逆に質問したい。縦書きの中に横書き専用の文字を配置する仕様を定めた文書が他にあるのか？あるのなら教えていただきたい。
回答2．Unicodeの文字は抽象的なものである。文字の形をグリフというが、印刷ではグリフの具体的な形状（グリフイメージ）をレンダリング（可視化）するのである。文字のコードポイントからグリフイメージへの変換処理方法には、文字によって様々な違いがある。一般的に言えば、コードポイントにグリフイメージを直接対応つける方法は、世界の文字を印刷するための技術としては役に立たない。
UTR#50とMVOは文字のコードポイントにグリフ可視化結果を規定する方法である。上に述べたように、一般論としてもこのアプローチは誤っている。このことを、以下に、具体的に例を示して説明する。
縦書き時のグリフイメージは文字のコードポイントの特性ではない。文字のコードポイントとグリフイメージは独立である。例えばInDesignにはアスキー文字を全角形で表示して、正立させる機能がある。その逆に、全角文字コードをプロポーショナル字形で表すこともできる。つまり、InDesignは文字のコードポイントとグリフイメージを独立のものとして扱っている。[4]
(9/21追記開始）文字のコードポイントに対して対応をつけることのできるグリフはひとつではない。複数のグリフを対応つけることができる。例えば、日本語組版ではラテンアルファベットには全角形とプロポーショナル形があるとしている。全角形とプロポーショナル形というのはグリフの区別であり文字コードの区別ではない。ラテンアルファベットの文字コードはU+0041～005A（大文字）とU+0061～007A（小文字）である（これらをアスキーアルファベットという）。JIS X4051の規定では、横書き時にはアスキーアルファベットにプロポーショナル形を割り当てて使うのが標準である（横書き時にアスキーアルファベットを全角形で表すことは一般には行なわない）。縦書き時には、アスキーアルファベットを全角形で正立したり、プロポーショナル字形で横倒しで並べたりできる。これは文字コードの使い分けではなく、グリフの使い分けである。具体的な実装例でいうと、InDesignは、縦書き時にアスキーアルファベットをプロポーショナル形で横倒し表示したり、全角形で正立させて表示する機能がある。つまり、InDesignは文字のコードポイントに対してグリフを何種類か対応付け、実際の表示においてその中から切り替えることができるのである。（9/21追記終わり）
別の例を示す。XML文書でコンテンツを表すのは文字コードの並びである。コンテンツ自体に方向属性を含むと再利用性が失われる。ひとつのコンテンツを縦書きでも横書きでも使えるようにするためには、縦書きのときのグリフイメージの向きを、コンテンツに対するXMLマークアップとスタイルシートの組み合わせによって指定するべきである。
繰り返すが、UTR#50とMVOは文字のコードポイントに縦書き時の方向を規定するというものである。特に、縦書きで、全角文字コードは正立し、アスキー文字を横倒しすると規定している。UTR#50とMVOを採用すると、コンテンツを縦書き専用、横書き専用に書き分ける必要が生じて大変不便である。
また、日本語の縦組みの書籍では、1ページの中に縦書きと横書きが混在している。また、本文は縦書きで索引は横書きという方式が一般的である。このように縦書きと横書きを同時に使う場合にも、UTR#50とMVOを採用すると不便である。[5]
[1]http://unicode.org/forum/viewtopic.php?f=35&t=346
[2]Google Translationの出力
[3]コメント投稿 2012/9/11
[4]上記のUnicodeフォーラムにて、山本太郎氏から独立ではないという指摘がありました。確かに、独立という表現は正しくないので、9/21にこの部分を削除して表現を改めました。文章の後ろの方もフォーラムの議論を鑑みてもっと補足するほうが良いのですが、これは別途、文章化することにします。
[5]この文章はUnicodeのフォーラムに投稿するために原文として書いたものなのですが、別途に何がどう不便かをもう少し具体的に説明したいと思っています。
残念ながらあまり説得力がないと思います。
・山本さんの質問には “One naive question is:” とありますが、「ネイティブから」というのはどこからきてるでしょうか？
・「JLReqは、和欧混植に関する規定に関して、残念ながらいくつかの誤りを含んでいる。JLReqよりもJIS X4051の方が優れている」と書かれてますが、JLReqの何が誤りか分かりません。縦書きで欧字や数字を横倒しにすることも和字として扱い正立にすることも両方あることは、JIS X4051でもJLReqでも同じです。JIS X4051では「和文と欧文を区別する方法は、処理系定義とする」とあり、また「縦書きの欧字又は数字を和字として扱う場合は」という記述がありました。JLReqで欧字や数字などを明示的に「欧文用文字」と「漢字等」の文字クラスに重複させているのは、両方の扱いがあるということをより明確に示したものだと思います。
・JIS X4051でもJLReqでも、欧字扱い（横倒し）、和字扱い（正立）の両方がある文字の存在を認めています。それらの文字について、デフォルトがどっちか決めようというのがUTR#50です。両方がありうる文字について、和字扱い（正立）をデフォルトにするのがSVOで、欧字扱い（横倒し）をデフォルトにするのがMVOと分けることが、もっとも合理的であるというのが私の考えです。目的によって使いやすいほうを使えばよいだけです。いまのUTR#50 MVOで問題なのは、欧字扱い（横倒し）が優先の部分と和字扱い（正立）が優先の部分とが中途半端に混在していることです。その点、山本さんのMVO修正提案 http://lundestudio.com/UTR50/TaroUTR50SortedList112.pdf は、合理的な基準を設けるものであり優れています。
・MVOを使う場合でも、全角文字コードポイントは使わないで、正立を指定するマークアップ（あるいはその自動処理）によって英数字を正立させることができます。全角文字コードポイントの利用をUnicode仕様が積極的に推奨するようなことはするべきではありませんが、便宜的な文字としてマークアップの代用として認めてよいと思います。（いまのUTR#50 MVOは縦書きで全角文字コードポイントの使用を前提としていることが問題。全角・非全角の区別がない‰（パーミル）記号の向きを標準の%（パーセント、MVOで横倒し）ではなく全角％（正立）に合わせていることなど）
・MVOではマークアップの量が増えるからSVOのほうが良くてMVOは不要であるという論は、説得力がありません。和欧混植が少ないコンテンツを手作業でマークアップするような場合にはSVOのほうが向いているというだけです。また、SVOのほうが、lang=”en” など意味のあるマークアップに対して横倒し指定できるのでよいという論も、言語を特定できないラテン文字のテキストを横倒しにすることだってあるので、いつもlang属性を指定できるわけでありません。Nippon Hoso KyokaiやNHKは英語ではなく日本語のローマ字表記なので、それにlang=”en”を付けるのは間違ってます。横倒しを指定するために英語ではないのにlang=”en”が使われるようになったとしたら、それはかえって非論理的なマークアップを広めてしまうことになります。
この意見をもう一度読み直してみて、最初の意見のタイトル設定に問題があることに気がつきました。
本文で言いたかったのは、UTR#50に文字方向のデフォルトを設けるというのはやめるべきである、ということです。別の言い方をすると、文字の方向を決めるのはコンテキストであり文字単独で方向を定義することはできない。決めることができないものに無理にデフォルトを決めれば不便になるということなのです。そして、MVOとかSVOはスタイルなので、スタイルとして指定する仕組みを作るべき、ということです。
UTR#50のアーキテクチャを批判しているのであって、MVOとSVOを比較する議論をするつもりの文章ではなかったのですが、MVO批判と受け止められたようです。
村上反論は、本文の趣旨からみると全くすれ違っている。村上発言は、この文章の主張に対する議論ではなく、自分自身の勝手な思い込みを書いているだけである。
こちらが立論方法を変更したのに気がついていないのだろうか？
村上反論：
山本MVOは、UTR#50では規定されていないのに、あたかも規定されているかのような前提を置いている。（本文の主張に対する反論になっていない。）
この文章にも、元のPOSTにもUTR#50のSVOは出てこない。それなのにSVO云々を議論している。（これも本文の主張に対する反論になっていない）。
相手の議論の理解力を欠いているといわざるを得ない。
理解力の欠如した人間を説得するのは難しいので、「説得力がない」という発言も無意味。聞く耳をもっていないのだから。
私はごの議論はぜんぜんフォローしていないのですが、亡き樋浦さんが
コードポイントをグリフと同一視してはいけないと言っていたのを思いだし
ました。Unicodeの中にも、そう書かれていると言っていたように記憶して
います。
まったくその通りです。
UTR#50は、コードポイントとグリフとグリフイメージを同一視してしまっています。
何度も言っているのですが、山本MVOであれば、スタイルシートで定義することにはまったく異議はありません。むしろ賛成といっても良いです。
MVOをコードポイントの標準として定義してしまう（つまりコードポイントに縦組み時の向きをハードコードする）といろいろ不便なことがありますよ、といいたいのです。
実際の縦書き文書中の文字の向きはコードポイントでは決まらないのでそのデフォルトの向きをどう定義しても不便なこともあるということは、議論に参加しているみんなの共通認識かと思います。
コードポイントでは決まらないからマークアップか何らかの規則による自動処理によって決めることになるのですが、そのような処理が何もされないときの向きが不定では困る（ブラウザなどで実装できない）ということで、UTR#50で標準化しようということになったと思います。コードポイントに対してデフォルトの向きを決めるということは何もその向きにに固定するということではありません。
問題はデフォルトの向きをどのような基準で決めるのかだと思いますが違うでしょうか？
実際の縦書き文書中の文字の向きはJISX4051やJIS X0213に記載されています。JIS規格を読んでいないのですか？
縦組みは、ほとんど日本語でしか使わないのだから、まずは、JIS規格準拠を考えるのが筋だと思います。
JIS規格を無視して思いつきのリストを作って議論したら、まとまるわけがないでしょう。
JIS X4051の「4.7 和欧文混植処理」で欧文の横倒しが定義されています。備考として「和文と欧文を区別する方法は、処理系定義とする」とあるので、コードポイントにもとづいて区別する処理系を定義しようとするUTR#50 MVOも、JIS規格に反してはいないと言われてしまいそうです。
欧文の横倒しは無視して、縦書きの欧字や数字を和字として扱う場合だけ定義すればよい、という考えもありだと思いますが、それだけがJIS規格準拠の方法だとはいえないと思います。
JIS X4051とJIS X0213といったはずです。
JIS X4051は組版規格です。組版の第一歩は入力である文字コードの並びを、出力であるグリフIDのならびに変換するプロセスとなります。
従って、組版規格は基本的にアウトプットであるグリフの扱いを規定する色彩が強いものです。一方、JIS X0213は入力である文字コードを規定しているものです。
第一に、出力するグリフの向きは、設定パラメータとして与えるべきであり、入力データに内在する属性として与えるべきではありません。
例えば、禁則処理では、禁則は入力文字に内在する属性ではなく、文字コードから切り離した別の属性して与えるほうが禁則文字セットの切り替えもできるなど、自由度の高い組版システムができる。
文字の向きも同じで、文字コードとは独立に与えて切り替え可能とする方が良い。このようなことから、文字のコードポイントの属性として与える方向は最低限の組み合わせのみとする。つまり、標準で規定するのはJIS X0213で規定する縦書き時の文字の字形に限定するのが良い。
第二に、処理系定義を標準というからには、それが有利だということを統計的なデータなどで実証的に示す必要があります。処理系定義自体は自由でしょうが、それは１ベンダのやることです。これを標準と主張するには裏付けが必要であることは常識でしょう。
個人的には、今のMVO提案者の何の実証データも示さず、議論も行なわずという非実証的態度は容認しがたい。
JIS X0213の「付属書4 仮名、特殊文字及びけい線素片」を見ると、「字形例」の説明に次のようにあります。
「当該面区点位置で表現される図形文字の字体で、参考となるその他の字形がある場合の字形を例示したもの。この例示は、一部の面区点位置についてだけ行った。また、縦書き用の字形が異なることがある場合も字形例で示した。この欄は、参考であって規定の一部ではない。」
参考であって規定の一部ではないとあるので、「JIS X0213で規定する縦書き時の文字の字形」など存在しないことになります。
あちゃ。この部分は忘れてました。指摘ありがとう。あとでもう一度チェックしてみます。
文字コード規格は、もともと字体を標準化しているものなので、字形は全部例示だからねえ。実際には例示字形を入れ替えただけで大騒ぎになるのですが。