先日、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のフォーラムに投稿するために原文として書いたものなのですが、別途に何がどう不便かをもう少し具体的に説明したいと思っています。

「英数字正立論―SVO を基本とするコンテンツマークアップの方法」（8/7版）[*1]において縦組みにおける英数字の方向に関する基本的な考え方を示しましたので、その完成に向けて、縦組みにおける記号の向きの取り扱いを考え始めました。

まず、現状を予備的に調査してみました。詳しくは「データ」の箇所をご覧いただきたいのですが、UTR#50（第5案）におけるSVOの値の中で表1の記号は実態とだいぶかけ離れているようです。

今回は書籍の中で出現するか否かだけを調べたのですが、出現頻度も含めた本格的な実態調査が必要なように思います。
（どうしましょうか）。

■表１　SVOの値を見直すべきではないかと思われる記号

・U+003D、U＋FF1D　＝（等号）
・U+FF5E　全角～　但し、Wave dashは問題ない
・U+2026　横3点リーダ　但し、Unicodeには縦の3点リーダが別に登録されています。この使い分けはどうするのでしょうか？
・U+2192　右向き矢印
・他には、不等号、÷記号が怪しいと思います。

■データ
・本ブログで英数字の方向を取り上げてきた書籍を対象として記号類の方向を調べました。
・対象としたのは、縦組みの和文コンテキスト中における記号類の方向です。
・和文と欧文の境界上の記号（引用符が多い）は対象に含めます。

次のタイプの文字列は和文には分類しません。この中の記号は除外します。
a. ラテン文字など欧文の文字で表記した英語や諸外国の単語などの中の記号類　（文字列全体が右90度回転しているので）
b. 横倒し数値列、横倒し数式の中の記号類　（文字列全体が右90度回転しているので）
c. 縦中横の中の記号類　（横組みなので）

例　a．John Wood Campbell, Jr., 1910-17　のような文字列の中の、「，」「.」「-」を除外
　　b．Z=14　のような数式が横倒しのとき「=」を除外
　　c. L’　（Lプライム）が縦中横のとき「´」を除外

[結果]

[*1]「英数字正立論」

□■□■□■□■□■□■ご案内□■□■□■□■□■□■

CASオンラインショップでCAS-UBのユーザー登録することで、誰でも30日間だけ無償でご利用いただくことができます。

春先から、「縦組み時の文字コード正立論」というテーマで何回かブログを書き、また、資料をEPUBにまとめてきました。そろそろ、その結論を出さなければならないだろうと考えて、Unicodeコンソーシアムのフォーラムに質問および意見を投稿しました。この投稿に関しては、Adobeの山本太郎氏から強い反対意見が出る[*1]など、残念ながら多くの賛成を得るにいたっていません。

また、Twitterの議論でも縦組時の文字の方向をどうすべきか、ということに関して多くの方から多数の意見が出ています[*2]。

国際電子出版EXPOの会場でも私の主張に同意される方、あるいは意見を異にする方数名の方と直接意見交換をさせていただきました。

この議論がとても難しい理由は、(1) これまで受けた職業的訓練など発言者の経験、あるいは美観といった主観に基づく判断と、(2) デジタル組版に関わる技術要素が極めて高度になっていることがあります。

(1) と(2)の両方が複雑に組み合わさっているため、問題の理解が難しく、従って、適切な解決策を提案するのが非常に難しくなります。そこで、あらためて(2)について検討することで、複雑に込み入ってしまった問題を解きほぐすことを試みてみたいと思います。

まず、テキストコンテンツ（Unicodeで記述されているものとします）があったとき、それが画面または印刷物（紙）として目に見える過程を図示し、それにどのような技術要素が関係しているかを簡単な絵で表してみます。

最初に、これらの技術要素について順番に簡単な解説を試みます。

１．コンテンツの記述

テキストコンテンツは一般には符号化文字集合で規定された文字コードを使って表現します。符号化文字集合としては、2000年ごろまではシフトJISが主流でした。これまでに蓄積されたコンテンツの量としては、シフトJISが圧倒的に多いと思います。

例えば、青空文庫はJIS X0201（但し、半角カナを除く）とJIS X0208の文字を使って入力し、シフトJIS形式で保存することになっています。JIS X0201（半角）とJIS X0208（全角）ではアラビア数字やラテンアルファベットがダブっていますが、これについては、半角と全角を使い分ける簡単な規則を次のように定めています[*3]。

・縦組みで正立しているラテンアルファベットは全角で、英単語は半角で入力します。
・アラビア数字は1文字のときは全角で、2文字以上は半角で入力します。

青空文庫の全角・半角の使い分けはシフトJISを使うときの基本的な方法と言って良いと思います。

さて、現在の多くのアプリケーションで採用している、符号化文字集合は、Unicodeが主流になっていると言って良いと思います。そして、今後新しく作られて流通するコンテンツはUnicodeベースに移行していくことになると予想できます。

２．シフトJISとUnicodeの違い

シフトJISは、MS-DOSのために開発された文字の保存方式（符号化方式）です。従って、MS-DOSが動作する環境であるPCに密接に関係しています。すなわち、文書を表示するディスプレイは半角と全角のセルをもつキャラクタ・ディスプレイであり、ドットパターンとして作成された文字がROM（リードオンリーメモリ）に保存されています。

JIS X0201の文字は半角幅のセルに表示され、JIS X0208の文字は全角幅のセルに表示されるということで文字コードとその表示幅は完全に1対1対応しています。

これに対して、Unicodeは新しい世代のコンピュータのための文字集合として設計されています。文字を表示する環境は、ビットマップ･ディスプレイであり、文字の字形はアウトライン（ベクトル）としてフォントファイルに収容されています。これにより、文字の幅も半角・全角というような固定幅から開放されて、プロポーショナルな幅をもつ字形のデザインが可能となっています。

こうした環境変化に対応し、Unicodeは文字とグリフ（字の形）を分離するCharacter-Glyphモデルを採用し、Unicodeは抽象化された文字（Character）を定義することになっており、文字の表示形は定義しないとされています。

Unicode標準はグリフイメージを定義しない。標準は、グリフがどのように可視化されるかではなく、文字がどのように解釈されるかを定義する。（中略）Unicode標準は、画面に見える文字の詳細な形、大きさ、方向は定義しない[*4]。

[*1] Fundamental questions
[*2] http://togetter.com/li/251192
[*3] 青空文庫工作員作業マニュアル (2011年11月20日第二版)
[*4] Unicode 仕様書第1章より引用

原稿用紙を使って原稿を書き、縦組で書籍を作った時代には原稿と出来上がり書籍で文字を書き進める向きが異なることがなかった。しかし、現在のようにワープロを使って横書きで原稿を書いたものから縦組で組版する時代には、原稿と書籍で文字の進行方向が根本的に異なってしまう。このため文字の向きの扱いが混沌となりがちである。

「刑務所なう。」はメルマガ「堀江　貴文のブログでは言えない話」を元にして編集した書籍である。横書きメルマガではラテンアルファベットやアラビア数字がふんだんに使われている。これに相応して「刑務所なう。」には縦組の中にラテンアルファベットやアラビア数字が頻繁に現れる。

こうしたことから「刑務所なう。」はプリント版の縦組み書籍における英数字の方向を検討するための格好の材料でなる。以下に、堀江メルマガと「刑務所なう。」で英数字と記号がどのように使われているかを調べ、メルマガと書籍の文字方向の違いを簡単にまとめてみた。

1. ラテンアルファベット
1.1 メルマガ
ラテンアルファベットはほとんどASCII文字（U+0030～0039、U+0061～007A）で表記されている。互換文字（U+FF10～FF19、U+FF41～FF5A）は皆無ではないが、むしろ誤って使われているように見える。

1.2 書籍
本書籍ではラテンアルファベットの文字列は、①一文字ずつ正立、②縦中横または全角単位字として正立、③横倒しの3通りで現れる。全体としてみるとアルファベットは一文字ずつ正立で現れることが多い。大よそ次の(1)～(3)の規則に従っているようだ。しかし、同じ文字列（Big Dog）が1文字ずつ正立して現れたり（p.383後ろから2行目）、横倒し（BigDog）で現れたり（同最終行）と必ずしも統一がとれていないところがある。

(1) 一文字づつ正立
アルファベット大文字だけの単語や文字列は一文字ずつ正立している。

・大文字１文字：　D棟8F（D、8、Fを1文字づつ正立）、B2駐車場、Tシャツ、担当のS
・大文字２文字の略語：　OB、NG、TV、DJ、、IP通信、UP、PC、PM、AM（pp.56～57）、CD、QA、QBチーズなど2文字でも縦中横にせず各文字を1文字づつ正立する
・大文字のみからなる単語：WEEKS（pp.37～38）、「THE 昭和」、MTG（ミーティング）。堀江語という方が適切かもしれない。
・大文字を連ねる頭字語：Y・T（Y、Tは姓と名の頭文字、’・’は中点）、ICANN、IFRS、FTA、TPP、DVD
・大文字のみからなる書名、番組名、映画題名など（固有名詞）：「JAM THE WORLD」、「J-WAVE」、「JIN」、「TIME LINE」、DENPO、TOKYO FM、EADS社、SNS（社名）、WIRED

(2) 縦中横または全角単位字

単位文字は小文字であっても縦中横にして正立している。

・単位：cm、mm、kg、sec、No.、kcal [p.96 4文字まで?]
・その他：or、Mr. [p.96]、

例外）単位であるが、縦中横になっていないこともある。

・MHｚ（p.43、縦中横にせず1文字ずつ正立）

(3) 全体を横倒し
単語の中に小文字が入ると固有名詞であっても単語または単語句全体を横倒しにしている。

・小文字が入るラテンアルファベットの名詞：Apple、Google、Google PC（PC含めて横倒し）、Eee PC（同）、ziploc、Kinect、NUAds、Amazon、zip、Live、Good、「We are 宇宙兄弟 VOL.03」[p.96]
・メールアドレス、URL：.com、.net

例外）
しかし、小文字が入っているが1文字ずつ正立しているケースもある：「Bay FM」、gTLD、「NExTWORK」

2. アラビア数字
2.1 メルマガ
(1) ASCII文字（U+0030～0039）と互換文字（U＋FF10～FF19）の使い分けについて

メルマガではアラビア数字はASCII文字が主体であるが、ときどき互換文字が使われている。例えば95％（ASCII文字）のような表記が主体だが１０％（互換文字）という表記も出てきたり、日付は5/28（ASCII文字）が主体だが、５／２０（互換文字）表記もある。このように、メルマガではASCII文字と互換文字が混在している。プリントと比べてややルーズな印象を受ける。

(2) 数字の書き方の例
年月日、時刻、単位付きの数値などはほとんどすべてアラビア数字で記述されており、漢数字は少ない。

アラビア数字の例
・単位付き数字：36000メートル
・日付：2012/4/16、5/28（ASCII文字）
・数値の桁区り：3,208円
・小数点：68.3kg

2.2 書籍
書籍（本文）ではアラビア数字はほとんどすべて正立表記である。次のような規則になっている。

(1) 1桁の数値は正立
(2) 2桁の数値は組にして縦中横。たとえば、11：30　は11が縦中横。’：’（コロン）は横倒し全角幅、30が縦中横である。68.3kgは、68を縦中横、’.’は全角幅中点、3を正立である。
(3) 3桁～4桁の数値は一文字ずつつ正立させる。2012年のような年号は一文字ずつ正立、98,830円のような5桁以上の数値は9万8830円のように4桁ずつにして、各すべての数字を正立させている。本書籍の中では5桁以上の数値はほとんど出現しない。
(4) メルマガと書籍の違いともいえるが、日付はメルマガでは2012/4/10というような表記になっていても書籍では2012年4月10日（10のみ縦中横で、他の数字は1文字ずつ正立）のように変更しているようだ。

数値が横倒し表記になっている箇所は極めてまれであり、例外と言っても問題ないくらいである。横倒し箇所を具体的に示す：
・3.14159Bill$（p.101、数値と単位全体を横倒し）、
・「We are 宇宙兄弟 Vol.4」　（p.501、書名の英数字部分が横倒し）
・H₂O（p.508、水の化学式全体を横倒し）、O₃（同、オゾンの化学式全体を横倒し）

○書籍の情報
書名：「刑務所なう。ホリエモンの獄中日記195日」
発行日：2012年4月5日第二刷
著者：堀江　貴文
発行所：文藝春秋社
ISBN: 978-4-16-374980-8

○本ブログ記事を「縦組みにおける英数字正立論」0.35版に反映しました。
こちらからダウンロードしていただくことができます。
CAS-UBで制作、無償配布している出版物

縦書き時の文字の方向特性を決めようとするUTR#50に関して新しい提案が3月5日に公開されました。現在公開されているUTR#50（Revision 3）は、Eric Mullerさん（アドビ）によるものですが、このカウンター提案は、LaurentiuさんとDwayneさん（両者ともMS）の共同によるものです。

「Updated Proposal to Revise UTR#50 Unicode Properties for Vertical Text Layout」

Unicode コンソーシアムのUTC #130会議で発表されたものを元にして、(1) Unicode全文字についての方向クラス（Orientation_Class）特性値の組を含めたのと、(2) UTR#50のRevision 3への参照を含むように更新されたものです。

UTR#50のrevision 3（2012年2月10日版、以下、UTR#50-20120210）についての説明はこちらを参照してください：縦書きにおける文字の方向について、UTR#50改訂版ドラフトの内容紹介

１．本提案の概要

(1) UTR#50-20120210は日本語を中心に考えているが、縦書きは日本語だけではないので、一般的な言語の縦組みレイアウトを実装するための文字特性とガイドを定義しなければならない。次のようなシナリオにおける縦書きレイアウトのグリフの方向を決めることができるような文字のデフォルトのクラス化を提供したい。

• モンゴル、’Phags-paのような縦書きの文字、漢字・ハングルなどの縦書き記法のデフォルト・レイアウト
• アラビア・デバナガリのような横書き文字のグリフを回転して表示して接続特性を維持する縦書きのデフォルト・レイアウト
• ラテン文字のような横書き文字をサイン看板などのように垂直に積み重ねる方式のレイアウト

(2) Orientation_Class（以下、方向クラス）という列挙型のUnicode文字特性とアルゴリズムを提案する。これにより次の二つの縦書きレイアウトモードにおいて、任意のテキストのグリフの方向を決定することができる。

• デフォルトモードでは縦書き時における文字の普通の方向を表す。デフォルトでは漢字は正立であり、ラテン文字は右に回転して横倒しになる。CSS3のtext-orientation特性値”upright-right”にあたる。
• スタックモードでは、普通は横倒しになる文字が垂直の方向になり、垂直方向に積み重なる。例えば、スタックモードでは漢字は垂直のままであり、ラテン文字は垂直に戻る。CSS3のtext-orientation特性値”upright”にあたる。

方向クラス値はすべてのUnicode文字の上記の二つのモードにおける挙動を記述するもので、一以上の方向属性（次の表）の組み合わせにより定義される。

表１．方向属性
属性　名前　説明
S　Stackable　縦書きでグリフを正立して表示可能な文字
R　Rotatable　縦書きでグリフを横倒しして表示可能な文字
T　Transformable　OpenTypeのGSUB ’vert’による置き換えのようにフォントの特性をつかってグリフの字形変換がなされる文字
I　Inherited　結合文字のように先行するグリフから方向を継承する文字
A　Arrow　矢印や類似の文字
B　Break　改行特性値を持つ文字

例えば、ラテン文字の方向クラス値はRS（Rotatable とStackable）であり、デフォルトモードでは回転し、スタックモードでは正立する。アラビア文字はRである。

表２．方向クラス値
クラス値　説明　例　
S　Stackableのみ　任意の縦書きレイアウトでグリフが正立する分離記述の文字　象形文字、仮名、ハングルなど
RS Rotatable & Stackable の両方　デフォルトモードでは回転し、スタックモードでは正立する。　分離記述文字の大部分、句読点の一部、デバナガリ文字
R　Rotatable のみ　結合記述文字のように隣のグリフとの結合を維持するために回転するもの、ベースラインに従う一部の括弧類
TS 字形変換とStackable　グリフは正立のままでフォントの特性により字形変換を蒙る分離記述の文字　カタカナ組み文字、こがきのかな
TR 字形変換とRotatable　フォントの特性による字形変換を受けた上でグリフは横倒しになる文字　CJKの括弧、全角幅の括弧
IS　Inherited とStackable　結合時は基底文字の方向を継承、分離時は正立する結合文字　かなの濁音・半濁音
IRS　InheritedでRotatableまたはStackable　結合時は基底文字の方向を継承、分離時はデフォルトモードで回転、スタックモードで正立する結合文字　一般の付加記号（かなの濁音・半濁音を除く）
IR　Inheritedで分離時Rotatable　結合時は基底文字の方向を継承、分離時は回転する結合文字　アラビア、シリア、モンゴルなどの付加記号
A　Arrows　矢印はAに分類し、上位のプロトコルでASまたはARSになる
AS　Stackableのみの矢印　デフォルトモード、スタックモードともに正立する　一般の矢印
ARS　RotatableとStackableの矢印　デフォルトモードで回転、スタックモードで正立する矢印　半角幅の矢印
BR　改行　
　
・方向クラス値は優先度の高い方から低い方への順に並んでいる。例えば、TRではTはRより優先し、TができないときRでも良い。

・方向クラス値は拡張可能である。

・方向属性Rは、UTR#50-20120210のEAVOのS（横倒し）とほぼ同じ。方向属性Sは、UTR#50-20120210のU（正立）とほぼ同じである。UTR#50-20120210のSとUは排他的であるが、方向属性RとSは組み合わせできる。

・多くの分離記述の非CJK文字はRSのようにデフォルトでR、スタック時Sの特性が与えられる。

(4)縦組みにおける双方向テキストについて（省略）

(5)アルゴリズム（概略）
1)Aの文字をAS, ARSに決定する
2)BRが先行しないなら先行モードを続ける
3)縦書きのモードがデフォルトモードのときとスタックモードでそれぞれの文字の方向と変形を行なう。

２．Unicodeの各文字についての方向クラス値

提案のPDFに含まれていますが、これをテキストにしたものがこちらにあります。

http://nadita.com/murakami/utr50-ms-table.txt

３．私見：この提案仕様について、ざっと読んでの疑問

１）デフォルトモードとスタックモードの切り替えのタイミングは？日本語の場合、ひとつの文書中で両方使われるので文書全体ではありえない。そうすると、どういうタイミングで切り替えるのか？段落の中でデフォルトモードとスタックモードを切り替えることになると、これを簡単に実現する仕組みが欲しい。（それともCSSのtext-orientationで切り替えるだけなのか？それなら、Unicodeの仕様にする必要はないだろう）。

２）アラビア文字には分離形と結合形があり、文字ではなくて、単語の中の位置でグリフの形を変える。つまりダイナミックに形が変わるが、この文章では文字のグリフ固定を想定しているように見えてしまう。日本語の漢字やかなの筆文字は結合する、つまり、分離形・結合形はフォント依存になるのではないのだろうか？英語だって手書きだと結合するんだけどな～～

上の１）、２）の疑問はもう少し考えないと・・・