10月22日「縦組み時の文字の向き―その理論とマークアップ方法」の発表予定資料をプレビュー

来週、月曜日(10月22日)開催予定のFormatterClubにおける発表「縦組み時の文字の向き―その理論とマークアップ方法」の資料を用意しました。資料はまだ変更の可能性がありますが、ご参加いただく方々に事前に検討していただき、ご批判を賜るためにここに、プレビュー版として公開します。

FormatterClub定例会の詳細

○プレゼン資料:パワーポイントで作ったPDF (22日1:40更新。22日13:30再更新。23日22:45細かい誤り訂正。説明文追加。)

○実際の書籍におけるグリフの方向調査結果:グリフの方向調査結果(PDF) (23日1:33公開)

この調査は、縦組み書籍24冊(延べ約5000頁)における記号類の向きを調べたものです。記号については網羅しています。しかし、記号以外はあまり網羅的ではありません。また、和文区間における向きであることに注意してください。(欧文区間=横倒し区間は除外しています。)

○AH Formatter V6.1アルファ版による組版例(PDF)

AH Formatter V6.1では縦組みの文字方向について実装する予定です。これについては、現在、UTR#50とCSS3 Writing Modeで仕様の検討が進んでいますが、以下で紹介する例は、UTR#50とCSS3 Writing Modeでできることとは一致していませんのでご注意ください。

以下の例はあくまで文字方向の指定を議論する目的で公開するものです。文字方向の扱いは今後変更の可能性があります。また、文字の揃え方、空きの取り方などはまだ開発の途上のため評価対象外としてください。問題点のご指摘は歓迎です。できるだけ、今後、製品版までに改善致します。

1. 縦組みにSVO(upright)とMVO(mixed-right)の指定による文字方向切り替えの例

(1) 文字方向指定なし

文字方向の設定をしない(デフォルト)と欧数字が寝てしまうことになります。⇒UTR#50はこの方向に向かっています。これは良くないと思いませんか?

(2) SVO(upright)

文書全体の文字方向をSVO(upright)に指定し、数字2桁を自動縦中横[1]とします。⇒これは概ね新聞組版と同じです。

(3) SVO(upright)+MVO

文書全体の文字方向をSVO(upright)、数字2桁を自動縦中横とし、箇条項目5全体にMVO(mixed-right)を指定します。⇒キリル文字はMVOでは横倒しになります。

箇条項目3には、欧数字[2]の正立と横倒しが混在するため、項目全体にMVOを指定できません。そこで次のように指定します。

(4) SVO(upright)+MVO+sideways

文書全体の文字方向をSVO(upright)、数字2桁を自動縦中横とし、箇条項目5全体にMVO(mixed-right)を指定、箇条項目3の英語範囲にsideways(横倒し)を指定します。⇒概ね、現代の書籍の組版に近くなります。

(5) MVO+SVO

文書全体をMVOとして、箇条項目5全体を日本語フォントで正立としました。これはMicrosoft Wordなどでキリル文字に日本語フォントを指定した状態に近くなります。Windowベースのアプリケーションでは通常キリル文字の方向はフォント依存です。この文字方向は、現在の欧米発ソフトウエアのデファクトのアプローチです。UTR#50でMVOがデフォルトに決まると、いままでのやり方とも少し変わることになります。

2. 縦中横

(1) 縦中横事例データ

実際の書籍(15冊)の中で使われている縦中横のパターン、および数文字の長さの欧数字のレイアウトパターンを収集しました。赤字が縦中横、青字は横倒し、黒は1文字ずつ正立です。

(2) SVO+縦中横+MVO設定

文書全体をSVO、縦中横は強制的に縦中横を設定し、ピンクのセルにMVOを指定します。概ね文字の方向は実際の書籍に近くなります。あとは細かい区間で方向を強制的に変更することになります。

(3) 自動縦中横設定例
a. SVO+自動縦中横

文書全体をSVOと数値2桁を自動縦中横とします。

b. SVO+自動縦中横+MVO設定

文書全体をSVOと数値2桁を自動縦中横とします。ピンクのセルにMVOを指定します。(2)との相違は縦中横を強制指定か自動処理かです。自動縦中横でかなり処理できますが、やはりすべては無理でしょう。

c. MVO+自動縦中横

文書全体をMVOにしてしまうと、自動縦中横はうまくいきません。また、ラテン文字が正立したり、横倒しになったりばらばらになります。文書全体の欧数字を横倒しにしてから、個別に立てていくのは手作業やWYSIWYGでは問題なくても、自動処理には向かないのではないかと思います。

3.実際の書籍テキスト例

『新版論文の教室』には縦組み文字方向のパターンが豊富に出てきます[4]。そこで『新版論文の教室』から一部をピックアップして、本文のデフォルト文字方向を(1) MVO(全角文字使用)、(2) MVO(全角文字を使用不使用)、(3) SVOの3通りに設定したテストデータ[5]を作成しました。PDFは、このテストデータを使ってAH Formatter(V6.0の特別版)で組版した結果です。

テストデータのマークアップ方法、ならびにその結果の知見については、当日ご説明いたします。

[10/21追加]

(1)デフォルト MVO(全角文字使用)(PDF)

ルートにMVO(-ah-text-orientation:mixed-right)を設定します。縦組みで正立する文字を全角文字コード(UnicodeのFullwidth variant)で記述し、横倒しになる文字を基本ラテン文字コードで表します。

(2)デフォルトMVO(全角文字使用せず)(PDF)

ルートにMVO(-ah-text-orientation:mixed-right)を設定します。アルファベットとアラビア数字は基本ラテン文字コードで表します。正立する文字範囲に(-ah-text-orientation:upright)を指定します。

(3)デフォルトSVO(PDF)

ルートにSVO(-ah-text-orientation:upright)を設定します。アルファベットとアラビア数字は基本ラテン文字コードで表します。横倒しする文字範囲に(-ah-text-orientation:sidewaysまたはmixed-right)を指定します。

○注
[1] 自動縦中横は現在、アラビア数字とラテンアルファベットのみ対象でテスト的な実装となります。
[2] ここではラテン(基本・拡張)アルファベット、キリル文字、ギリシャ文字、アラビア数字、ローマ数字。および欧文組版用の括弧・記号類を指します。
[3] XHTMLファイル(ZIP)形式:このXHTMLはAH Formatter V6.1を使わないと正しく組版できません。AH Formatter V6.1プレビュー版については、FormtterClubにてご案内がなされる予定です。
[4] 「新版論文の教室」には書籍の縦組みレイアウトパターンと文字の方向パターンの典型例がある
[5] XHTMLファイル(ZIP)形式:このXHTMLはAH Formatter V6.1を使わないと正しく組版できません。AH Formatter V6.1プレビュー版については、FormtterClubにてご案内がなされる予定です。

UnicodeのUTR#50に関するいくつかの基本的な疑問、これをどう解決するか?

W3CのCSS WGのメーリングリストに、text-orientation:uprightがforced uprightになり強制アップライトになるということが決まったという話が出ています[1]。その理由はUTR#50[2]では、SVOを今後定義しないからということらしいです。

WGの議事録を読みますと、どうやら、UTC(技術委員会)はUTR#50では当面日本語を優先すると決めたようです。で、SVOは日本語用ではないので削除するという論理のように思います。これで良いのでしょうか?

これに関連していくつかの基本的な疑問があります。

1.第一に、現在のUTR#50には、MVO、SVO、HOという3つの表が提案されています。仕様案の文章、編集者のEric、その他の関係者の発言から推測すると、この3つをどうやら言語別に使い分けることになっているようです。

・MVO:日本語を含む東アジア向け
・SVO:英語向け
・HO:MongolianやPhags-Paのような縦書き専用言語向け

Unicodeは文字コードの国際標準です。つまり、全世界で共通のはずなのに、Unicodeで表現したテキストファイルの文字の向きの解釈が言語依存で良いのでしょうか?

でもし仮に、どうしても言語別に表を作らざるを得ないとすると、Unicodeで表したテキストファイルはどの言語向けかを指定しないと解釈できなくなります。しかし、現在のUTR#50ではこの3つの表をどうやって使い分けるかの指定方法はなにも言及されていません。

これはかなり基本的なことだと思いますが、誰も指摘していません。

2.日本語で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テキストファイルがどのデフォルトを使っているかを示すマーカー文字コードを提案する必要があるでしょう。

3.MVOの問題点

さて、現状では日本語についてはMVO推進者の力が強くなっています。なお、MVOについても個別の文字方向についての意見が一致しているわけではないので、一律にMVO推進者といえるかどうかは留保します。

現在のMVO([3]の表)では表でMVO=Rになっている文字(基本ラテン文字、拡張ラテン文字、ギリシャ文字、キリル文字など欧米の文字やアラビア数字などの数字)は、縦書きで横倒しがデフォルトとなり、MVO=Uの文字が正立になります。

従って、もし仮に、UTR#50で現在提案されているMVOがデフォルトになったとすると次のことがおきます。

(1) 印刷関連の標準であるJIS X4051では横書きでは一般に欧米の文字はプロポーショナル形[4]で表記することになっています。そこでUnicodeでテキストファイルを横書きで用意するときは、欧米の文字のうち基本ラテン文字とアラビア数字はASCII文字コードで表記するのが基本となります[5]。

(2) この横書きテキストファイルを縦書きにすると、欧米の文字やアラビア数字はすべて横倒しになります。

(3) 欧米の文字の中で、基本ラテン文字とアラビア数字は全角形の文字コードを使って表すことで正立させることができます。しかし、次の問題が残ります。
①このためにはテキストファイルを横書き用と縦書き用の2種類を用意する必要があります。最近の日本語文章にはラテン・アルファベットとアラビア数字が溢れかえっていますので、これはかなりわずらわしい問題です。
②さらに、欧米の文字の中で、英語にはないフランス語やドイツ語専用の文字(拡張ラテン文字)、ギリシャ文字やキリル文字は横倒しのままとなります。円マーク、ポンドマークなども寝たままとなります[6]。

4.FormatterClubのご案内

ということで、縦書きの文字の向きはかなりややこしい問題なのですが、こうした問題をどういう風に理論的に整理するか。そして、どうやって実際に文字の方向を指定すると一番便利になるのでしょうか?

次回のFormatter Clubで時間をとってもらい、このことについて調べた結果を発表したいと思っています。

FormatterClub定例会「文字組版の最先端」

ぜひ、多くの方にご参加いただき、ご意見を伺いたいと思います。

[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通りの意味があります。この2つは本質的な相違なのにも関わらず混同して使われています。例えば、ギリシャ文字(α、β、…)、キリル文字(а、б、…)はJIS X0201にはありませんので、半角文字コードはありません。
[5] 印刷は文字を紙に表す技術です。従って印刷の標準では文字コードを定めているのはなく文字の形を決めていると解釈するほうが適切でしょう。このことは仕様には明記されていませんが、そう解釈しないといろいろとつじつまが合わなくなります。で、文字の形と文字コードの対応関係は1対1ではありませんので、データを用意する方法は他にもあるはずです。
[6] Microsoft Wordで縦書き指定すると、これらの文字の向きはフォント依存です。欧文フォントを指定すると横倒し、和文フォント(IPA明朝、MSゴシック)を指定すると拡張ラテンは横倒し、ギリシャ文字・キリル文字・円マーク・ポンドマークは正立です。
[7] ちなみにこのことを昨日2人に相談しましたら、2人とも縦書きなんか未来はないし、意味がないのでやめるほうが良いといわれてしまいました。日本語の縦書きは風前の灯かな?しかし、組版ソフトのベンダとしてはどうしても避けて通れないんですよ。

JIS X4051で規定する縦組み時の字形と現実の書籍で使われている文字の向きの比較考証

「縦組みにおける記号の扱い―JIS X4051を検討して見えるもの」[1]で組版上特殊な役割をもつ文字が123文字あり、その中で、

1) 横書きと縦書きで字形が異なるもの:87文字
うち、①回転するもの41文字、②回転以外46文字。但し回転以外のうち41文字はこがきのかなとカタカナです。
2) 横書き専用:9文字
3) 縦書き専用:4文字

とされていることを説明しました。ここでは、実際にJIS X4051で指定されている字形と実際の書籍の印刷結果との関係をまとめます。

縦組み書籍20冊の頁(トータル4500頁前後)に出現する記号とその方向を調べてみた結果[2]のPDF:こちらに置きました

上のPDFのJIS X4051の欄では、JIS X4051で縦組み字形をコード表と同じ字形にしている文字に「U」、縦組み字形が右90度回転形になっている文字を「R」、字の形が変わるものを「T」、縦組みでは使わない文字を「N」と入力しています。JIS X4051の附属書に字形が出てこない文字は空白のままです。

【規則1】
JIS X4051定義文字の方向はそのまま、JIS X4051で規定されていない文字は正立(「U」)と仮定します。

【規則1の問題点】
そうしますと実際の書籍で使われている文字(主に記号類)と規則1の方向定義に大きな相違があるのは次の文字です。

①LESS THAN SIGN、EQUALS、GREATER THAN SIGN。特に等号(=)の向き。
等号の向きは大抵「R」(右90度回転)で出てきます。等号は「U」ではなく「R」とすると実際の縦組みでの使われ方に近くなります。

②全角のチルダの向きは規則1では「U」になります。一方、Wave記号(U+301C)の向きはJIS X4051で「T」になっています。「~」は正確には回転形印刷紙面で使われているのは全角チルダではなくて縦書きWave記号(U+301C)であるとすると問題ありません。縦組み書籍で使われている「~」は全角チルダではなくて縦書きWave記号(U+301C)であるとしています(9/17変更)。但し、Windows7のIMEで全角波形を入力するとチルダ(U+007E)に対応する全角文字コード(U+FF5E)が入力されてしまいます。このため全角チルダの向きを「U」、縦書きWeva記号を「T」とすると混乱が大きくなってしまうでしょう。両文字の向きは統一して「T」にしたいところです。

③右向き矢印(U+2192)の向きはJIS X4051では規定されていません。そこで規則1ではデフォルト方向は「U」となります。
しかし、実際には右向矢印は文脈的に文字の進行方向を示すことが多く、縦組みでは右90度回転していると想定するほうが素直です。つまり実際には「R」として使われていると考える方が自然ということになります。矢印は絶対方向を示すために使うことも相対方向を示すために使うことも可能ですが、相対方向を示すために使うとすると縦横自動切換えでは便利です。しかし、相対方向を示すというと混乱する可能性があります。「U」にすべきか「R」にすべきか悩ましいところです。

【まとめ】
UTR#50ではJIS X4051で縦組み字形が規定されている文字だけを縦組みのデフォルト方向として「R」または「T」を与えて、それ以外は全部デフォルト「U」にしてしまっても大むね問題は生じないように思います。このあたりはもう少し現実のデータで検証してみたいと考えています。

【注意事項】
・実際の書籍の文字は印刷された結果すなわちグリフイメージです。本調査ではグリフイメージから文字のコードポイントを推定していることになり、推定者に依存するため、必ずしも適切かどうかは保証できません。
・縦組みでは使わない文字が縦組みで使われているのは、意図的に間違った例としてあげていたり、もともと横書きの内容をあえて縦書きの行中に入れることがあるためです。こうした使い方に備えて強制的に方向を設定できることは必須です。

[1] 「縦組みにおける記号の扱い―JIS X4051を検討して見えるもの」
[2] Japanese Text, that is excluding western text. 対象は和文文脈のみ。長さには関係なく横倒し文脈の中の記号類は除外する。たとえば、数式(Z=14など)が全体として横倒しのときも除外。縦中横も除外する。L′(L Prime)は縦中横なのでこの場合のPrimeはUとはしない。-1を縦中横にしているときも同じで「-」は横書き中とみなすなどの前提を置く。

UTR#50のフォーラムでの質問に答える: UTR#50とMVOは拙劣な規定であり、日本語の縦書きは不便になる

先日、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の記号は実態とだいぶかけ離れているようです。

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

■表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日間だけ無償でご利用いただくことができます。
CAS-UB評価ライセンス

「縦組みにおける英数字正立論」0.4版発行。第1章、第2章を全面改訂しました。

この数ヶ月の調査結果と、Twitterなどでの議論を踏まえて、「縦組みにおける英数字正立論」を改訂して0.4版としました。

修正箇所: 第1章、第2章は全面改訂。第5章は入れ替え(旧第5章の内容は、新第2章に反映していますが文章は全部書き換え)

第1章は序論に近いので、重要性は低いですが、第2章に結論を持ってきました。

2.1 日本語縦組みの3つの方式

日本語の縦組みの典型には、新聞方式、伝統的方式、現代方式の3種類があること。その例と特徴を示しています。

2.2 欧字の和字扱い・和欧混植・縦中横

日本語の縦組みにおける英数字の扱いの特徴は欧字の和字扱い・和欧混植・縦中横の3項目にあること。3項目の説明を示し、新聞方式、伝統的方式、現代方式との関係を示しています。

特に欧字の和字扱いと和欧混植は、英数字に対する相反する取り扱いです。英数字の文字コード側からみてこの取り扱いを決定する方法がないこと、これについて記述した標準仕様が従来存在しなかったことが、UTR#50議論の混迷の原因と思います。

2.3 マークアップの必要性

日本語の縦組みを指定するには、マークアップが必須であること、その理由を示しています。

2.4 SVOをデフォルトとするマークアップの薦め

MVOをデフォルトとするマークアップとSVOをデフォルトとするマークアップの方法について比較検討します。
その結果として、SVOをデフォルトとするマークアップの方が優れていることを示します。

●PDF版とEPUB3版を作成して、こちらから配布中です。

http://www.cas-ub.com/project/index.html#Free

ぜひご高覧、ご意見を賜りたく存じます。よろしくお願いします。

「縦組みにおける英数字正立論」はCAS-UBで作成しています。便利ですよ~

■ご案内

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

縦組み時の文字の方向に関する議論を解きほぐす試み (1)コンテンツの記述

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

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

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

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

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

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

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

1.コンテンツの記述

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

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

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

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

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

2.シフト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章より引用

英数字の方向のこと、いまTwitterで議論がなされていることへの簡単な説明

縦組みにおける英数字の方向についての議論が活発ですが、どうも議論をしている人たちは、本来別のものとして分けて考えるべき問題を一つにごっちゃにして議論しているのではないかと思います。

その結果、シンプルである問題を複雑にしてしまっているのではないでしょうか。

●現状と課題

Unicodeは文字(Character)の抽象的な形状に基づいてコードポイントを与えており、具体的な形状であるグリフやその方向は定義しないとしています[*1]。そこで、縦組み時に文字の向きを指定しないときの方向(デフォルトの方向)はアプリケーションに任されることになります。

Microsoft Officeを初めとする多くのアプリケーションは、UnicodeのBasic Latin(ASCIIコード、MS IMEでは半角英数で入力、以下「半角文字」)は時計回りに90度回転した状態(横倒し)をデフォルトとし、その全角形(FullWidth Variant、MS IMEでは全角英数で入力。以下「全角文字」)は正立としています。一方、青空文庫のリーダでは半角文字を正立させているものもあります[*2]。このように、特に、半角文字の向きは必ずしもすべてのアプリケーションで同じではありません。

UnicodeのUTR#50という仕様[*3](仕様案)で決めようとしているのは、文字のコードポイント毎のデフォルトの方向です。これが決まって普及するとアプリケーション毎に文字の向きがばらばらになる状態が解消されるものと期待されます。

縦組みは新聞、雑誌を初め文芸書やビジネス・経済書などの書籍では頻繁に使われています。これらの出版物の制作にはプロの編集者・制作者・印刷会社が関与しています。しかし、いままで、オフィスソフトで作成する文書はほとんど横組みです。また、Webでは縦書きがほとんど使われていませんでした。つまり、縦組み制作は専門家のものであり、一般人は縦組み出版物を読むことがあっても作成するドキュメントは横組み中心でした。そこで縦組みの出版物での文字の向きに関する取り扱いは一般人には縁遠いものだったと言えます。

現在、CSS3で縦組みが標準化されてブラウザで読めるようになりつつあります。そうすると縦組みブログも数多く登場するでしょう。また、EPUBでも縦組みを使えるようになります。このように一般人が縦組みで表現する機会が増えるものと予想します。専門家は訓練を受けており、DTPソフトなどのツールを使うことができますが、一般人はそうではありません。そこで、縦組み時に文字がどういう向きになるかでかなりの混乱が生まれることになるでしょう。

このような観点に立つとUTR#50の意義は非常に大きなものがあります。

さて、UTR#50の現在の仕様案(ドラフト5版)には縦組みの行における文字のデフォルト方向としてMVO方式とSVO方式が記述されています。他にHOもありますが、これは横書きなので省略します。

●MVOとSVOはどういうものか?

MVO方式での文字のデフォルト方向の決定方針は複雑であり、個々の文字については様々な意見が出ておりまとまっていません。いま、本ブログで注目している英数字(ラテンアルファベットとアラビア数字)についてだけを見ますと、MVO方式では半角文字を横倒しとし全角文字を正立とします。一方、SVO方式では半角英数、全角英数とも正立です。

・MVOでは、Basic LatinのU+002E … U+005Aは、縦組み時に横倒し、その全角形(全角文字)は正立
・SVOでは、Basic LatinのU+002E … U+005Aと、その全角形は両方とも正立

MVO方式とSVO方式の適用範囲に関する記述は曖昧なのでよく理解できません。Forumで質問したところ、UTR#50のエディタであるEric Muller氏からは、SVOは英語に適用するものであって日本語はMVOを適用すると回答がありました[*4]。しかし、CSSのワーキンググループのfantasaiは別の考えを示しています。このあたりの関係はよくわからないのですが、SVOはCSSのワーキンググループの考えをEric Muller氏が受け入れたものということなので[*5]、fantasaiの考えが及ぶものと見ることもできます。

●MVOとSVOの適用例

ということでUTR#50のSVOが日本語に適用されるものなのかどうかは今の仕様案からは読み取ることができません。今後変わる可能性もあると期待して、とりあえずMVOとSVOを日本語文字列にも適用できるとします。するとMVOとSVOによる英数字のデフォルト方向は次の図のようになります。

図では、MVOとSVOで同じ内容の行がそれぞれ2行ずつペアになっていますが、そのペアの右は英数字と記号を半角文字で入力、左は全角文字で入力したものです。

日本語の縦組みの行に英数字が単独で現れた場合、全角文字・半角文字に如何に関わらず正立させるSVOの方が自然ということが大多数の人が認めると思います。しかし、Twitterの議論では、どうも、SVO方式の支持者は少なく、MVO方式の支持者の方が多いように思います。

●文字単位と文字列の表記の違い

たとえば、強硬なMVO支持者である山本太郎氏は、つぎのような理由で半角文字横倒しを主張しています[*6]。

1.縦組みの日本語文字の中に英文が入る場合、英文は横倒しにするのが一般である。
2. 新聞などの限られた分野では英文やアラビア数字列を正立させているが、新聞では段の文字数が少ないなどの制約がある。また、新聞以外の出版物で英数字が正立するのは頭字語や縦中横などのトリック的な表示に限られる。
3.フォントに縦組み用メトリックス情報がないなど技術的制限があるし、日本語の中で英数字を正立させる慣例が確立されていない。このような理由で縦組みで英数字を正立させると組版結果が醜いものとなる。特に、全角文字ではないラテンアルファベットは横倒しにすべきである。
4. 英数字正立をデフォルトとすると、少なくない人々が、正当な書法では縦書きでは漢数字を使うべきであることを忘れて、アラビア数字を縦書きで使い始めるだろう。そして伝統的な方法を学ぶ機会もなくなる。
5. 縦中横のような方法で英数字を正立させるのは訓練された組版担当者に行なわせるべきであり、このようなトリックをデフォルトにするべきではない。
6. 一部の人は、西欧生まれのラテン文字やアラビア数字の向きを正立をデフォルトとせよ、と主張する。しかし、そういう主張は開発者、ユーザ、組版を誤った方向に導くものであり、信じがたい。

実際には、UTR#50は、1文字単位で、特にマークアップがなければどういう方向を向かせるか(デフォルトの方向)を決めるものです。縦組みの和文中で英語の単語や文章が現れたとき(つまり、組版での和欧混植)どうするかは、英語の単語や文章を縦組みの行の中にどう配置するかという問題なのであり、これはUTR#50で決めることではありません。

山本太郎氏の意見を典型として、Twitterの議論の多くは、このあたりを拡大解釈して、あたかもUTR#50は、和欧混植の組版や混植文字列の表示をどうすべきかという観点から、各文字のデフォルトの向きを議論しているようです。実際には文字は単独で現れるだけではなくて、文字列の中で現れることが多いので、1文字単位の方向を文字列内での方向と同じ向きにしたいという、そういう風な議論になりがちなのはわかります。

しかし、現実には1文字単位の方向と文字列内(和欧混植など)での方向は必ずしも一致しません

縦組みの行に英数字が1文字だけ現れた場合は正立が自然と述べました。では、2文字以上連続したときの方向は一体どうなるべきでしょうか?

実際の出版物を調べてみますと、アラビア数字は、1文字なら正立、2文字なら縦中横、3文字~4文字なら一文字ずつ正立、などと表記することが多くなります。つまり2文字のときは特殊な配置になりますが、多くの場合正立します。しかし、縦組み参考文献表で参照ページ番号をpp.10-11のように示す場合や、数式の中に現れるアラビア数字は全体を時計回りに90度回転して配置しますので、横倒しにする方が良いでしょう。

一方、ラテンアルファベットについてみますと、たとえば、Nippon Hōsō Kyōkaiは縦組み中では文字列全体を時計周りに90度回転して表示する(文字毎では横倒ししているように見えます)のが綺麗に見えるでしょう。しかし、NHKと表記したときは3文字をそれぞれ正立して表すのが普通です。同じN、H、Kという文字が文脈によって正立にも横倒しにもなりえるのです。

文字の方向は言葉の中で文字がどのように使われているかの役割やその書記方法に基本的に依存します。さらに著者や編集者なりの考えがあった場合、その考えに沿った指定ができることが重要です。

●文字単独と組版問題を分離する

このように英数字が2文字、3文字…と連続するときにどう配置するかは、文字のコードポイントに付随させる属性というよりも、むしろ文字列を行の中にどのように配置するかという組版の問題です。そして、文脈依存で変わりうるものです。したがって、ケースバイケースで外部から指定できることが重要となります。つまり「CSSなり他のアプリケーションで決定するべき問題」ということです。

●全角文字と半角文字で方向の使い分けの問題

MVOでは半角文字を横倒し、全角文字を正立とします。つまり、縦組み時のデフォルトの方向を文字コードで使い分けるという考えです。これは専門的・技術的な問題なので詳しくは別途検討したいと考えますが、ここで結論だけ述べるとこれは不可です。

理由は次のようなことです。①現在までの文字コードとフォントの技術進歩に相反するものである。②文字コードレベルでの使い分けは原テキストの書き直しを必要とするのでコンテンツが縦組み専用となる。③半角文字(文字コードレベル)であっても全角形で表示することができるし、その逆も可能なため、外観だけでは、半角文字なのか全角文字なのかの区別ができない。このため半角文字と全角文字の使い分けを厳密に行なうにはツールの支援が必要となる、など。

[*1] UTR#50(Unicodeの縦書きの文字の向き)の話題
[*2] Unicode仕様書第1章を参照のこと
[*3] http://twitpic.com/a180ys
[*4] Unicode Properties for Horizontal and Vertical Text Layout
[*5] Fundamental questions
[*6] https://twitter.com/kojiishi/status/217421396391899136
[*7] About the MVO, http://blogs.adobe.com/CCJKType/files/2012/07/TaroUTR50SortedList112.pdf

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

「刑務所なう。」にみる縦組みにおける英数字・記号の向き

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

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

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

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) 一文字づつ正立
アルファベット大文字だけの単語や文字列は一文字ずつ正立している。

・大文字1文字: D棟8F(D、8、Fを1文字づつ正立)、B2駐車場、Tシャツ、担当のS
・大文字2文字の略語: 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]、

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

・MHz(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文字)のような表記が主体だが10%(互換文字)という表記も出てきたり、日付は5/28(ASCII文字)が主体だが、5/20(互換文字)表記もある。このように、メルマガでは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、書名の英数字部分が横倒し)
・H2O(p.508、水の化学式全体を横倒し)、O3(同、オゾンの化学式全体を横倒し)

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

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

UTR#50: 文字の方向特性に関するカウンター提案の概要紹介

縦書き時の文字の方向特性を決めようとする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.本提案の概要

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

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

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

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

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

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

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

表2.方向クラス値
クラス値 説明 例 
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)縦書きのモードがデフォルトモードのときとスタックモードでそれぞれの文字の方向と変形を行なう。

2.Unicodeの各文字についての方向クラス値

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

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

3.私見:この提案仕様について、ざっと読んでの疑問

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

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

上の1)、2)の疑問はもう少し考えないと・・・