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

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

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

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

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で制作、無償配布している出版物

「日本語組版における行配置の課題」(第1版)を配布開始

4月19日より「日本語組版における行配置の課題 ― 行送り方向の組版処理の問題点 ― 」(小林 敏著、アンテナハウス株式会社CAS電子出版、ISBN978-4-900552-07-4)の第1版を公開しました。本書は、表紙から奥付けまでCAS-UBで編集・制作されており、CAS-UBのPDFレイアウト機能をご確認いただくことができます。但し、本文中に文字サイズ、字詰めについて言及している箇所が多いためEPUBの見本としては適切ではありません。

次のページから無償でダウンロードしていただくことができます。
http://www.cas-ub.com/project/index.html(無償配布の出版物の項)

本書は日本語組版における行方向の配置についての解説と課題を挙げています。

日本語の文字は、文字進行方向にはべたで並べていくだけで適切な読みやすさになるようにデザインされています。一方で行の進行方向には適切な空きが必要です。この空きを行間と言いますが、適切な行間の設定は版面の大きさ、一行の文字数や文字の大きさによって変わります。

本書ではこの行間の空きの取り方について整理して解説しています。

行間を見出し、図版や表、注、脚注などまで考慮して設定するのは専門のオペレータにとっても難しい問題ですが、これをプログラムで自動化するのはさらに難しくなります。

しかし、WebやEPUBのようなリフローする内容を画面に読みやすく表示するには行間設定をプログラムで自動的に最適化することが必須です。このように考えますと本書の内容こそが今後の自動組版に課せられた課題といえます。

本書はCAS電子出版シリーズ第3弾として制作したものですが、本書は「W3C技術ノート 日本語処理の要件」の補足的な資料としてもご利用いただくことができます。

日本語組版に関心をもつ方の参考にしていただければ幸いです。

自動組版の強化とデジタルファーストへの道程

「日本語組版処理の要件」が4月10日にプリントされた書籍として発行されました。この書籍の本文は、4月3日に公開されたWeb版(日本語版)と同等であり、Webコンテンツをほぼそのまま書籍化したデジタルファースト出版の事例になります。

デジタルファーストによる商業書籍出版においては、自動組版の技術が重要なポイントになると考えていますので、その観点で以下に少し説明をします。

ワークフローの概要はまえがきなどに述べられている通りで、本書のプリント版の本文すべてをAH Formatter V6による自動組版で制作しています。AH Formatterで日本語の書籍を制作して商業出版を行なった例は過去にも多々あります。しかし、大きなコンテンツの書籍をデジタルファーストで出版するのにAH Formatterを使用した事例としては初めてになります。

本書は図版の数が膨大であるという点で、DTPで制作するとしても相当作業量がかかるはずですが、これを著者グループが自動組版で行なったことで出版社の負担は非常に小さくなっているはずです。また、自動組版を使うことでWeb版の内容をフィックスしてから極めて短時間にプリント版を出すことができているという点、デジタルファーストからプリント版を制作するワークフローに自動組版を組み込むことの有効性を示すことができたと思います。

プリント版とWeb版では図版の精度が違っていたり、索引などWeb版にはない内容をプリント版では付け加えていますので、まったく同じコンテンツということでもないのですが、このあたりの詳細は、4月23日にJAGATで開催される「電子書籍と日本語組版『W3C技術ノート 日本語組版処理の要件』出版記念」セミナーでもプレゼンが予定されています。

テキストと図版が混在する文書で図版がページに入りきらない場合、図版の前で改ページしてしまうと、そのページのテキストの後ろ側に大きな空きスペースができます。Microsoft Wordなどで文書を編集する際も同じことが起きますので、経験している人は多いと思います。DTPでも同じですが、こうした空きをなくすために、対話型WYSIWYG編集ソフトをつかって著者やオペレータが画面を見ながら図版とテキストの位置を調整するのが普通です。このため図版の多い書籍の組版はテキスト主体の内容の組版と比べると大変です。

AH Formatter V6では、この図版位置調整の操作をプログラムで自動的に行なう機能を備えています。これによって、今回「日本語組版処理の要件」のプリント版制作では調整の手作業は大幅に減っています。

AH Formatter V6の自動図版位置調整機能は、米国内国歳入庁の案件(下記ケーススタディ参照)のために間に合うように実装したものですが、「日本語組版処理の要件」でも有効性を発揮しました。

但し、「日本語組版処理の要件」は横組みで脚注がない一段組みという比較的シンプルなページレイアウトの書籍です。これが縦組みや大量の脚注がある書籍は図版の位置調整はさらに難しくなります。現在、CAS-UBでさらに様々な書籍を制作しながら図版の位置を自動的に調整する方法の改良をつづけています。

また、図版の多い2段組文書としては論文があります。米国内国歳入庁の帳票は多段組みなのですが、比較的シンプルでした。これに対して、複雑な論文への応用という点では、JATS(Journal Article Tag Suite)で記述された論文の自動組版があります。アンテナハウスでは、フルJATSで記述された論文の組版のためのスタイルシートを開発しましたので、これについては、5月24日のJATS解説セミナー(JATSによる日本語学術論文の標準化と自動組版)にて公開し、オープンソースとして配布する予定です。

こうしたことを通じて、さまざまなレイアウト・タイプのプリント版を自動組版で簡単に制作できるようにすることで、デジタルファーストの普及への道を切り拓きたいと考えています。

*「電子書籍と日本語組版『W3C技術ノート 日本語組版処理の要件』出版記念」セミナー
*JATSによる日本語学術論文の標準化と自動組版セミナー
*日本語組版処理の要件(日本語版)W3C 技術ノート 2012年4月3日
*「W3C技術ノート日本語組版処理の要件 美しく読みやすい文字組版の基本ルール」W3C日本語組版タスクフォース 編
*IRS:アメリカ合衆国財務省:内国歳入庁(PDF)
*時代を乗り越える日本語組版
*Page2012終了。いま、電子書籍制作のワークフロー論議をまとめると…
*NLM DTDからJournal Article Tag Suiteへの進展:これまでの経過整理

「日本語組版処理の要件」W3C 技術ノート 2012年4月3日公開

「日本語組版処理の要件」の第2版が正式に公開されました。昨年11月に作業ドラフトとして公開されたものに対するコメント・意見を反映して正式版としたものです。

日本語組版処理の要件(日本語版)
W3C 技術ノート 2012年4月3日

第1版は2009年4月に公開され、欧米の専門家の間で高い評価を得ました。そして、CSS3の仕様に日本語組版の機能を盛り込む上で大きな貢献を果たしました。

第2版は、第1版で盛り込むことができなかった「第4章見出し・注・図版・表・段落の配置処理」を追加したもので、第2版をもって完結となります。

W3CのWebページで公開されているのはHTML版ですが、第2版の公開にあわせて4月10日にプリント版が東京電機大学出版局から発売になります。アマゾンで予約の受付が始まっています。

アマゾンの書籍案内ページ

このプロジェクトは日本語組版をプリントの世界からWebや電子書籍にまで広げていくためには、スタイルシートの仕様に日本語組版の指定機能を盛り込んでいく必要があり、そのためには、W3CのCSS(Cascading Style Sheets)やXSL-FOスタイルシートのワーキング・グループに日本語組版について理解してもらうための英文資料を用意する必要がある、というところから始まったものです。

プロジェクトが始まったのは、2006年の春ですので、ちょうど満6年かけて完成したことになります。長期間にわたり作業を続けてこられたタスクフォース・メンバーに敬意を表したいと思います。

CAS-UBは、この成果をソリューションとして実現することを目標の一つとしています。既に、CAS-UBのPDF生成のV2レイアウト指定で「日本語組版処理の要件」に沿ったページ組版を自動的に行なうような機能を組み込んでいます。しかし、まだ完全とはいい難いので今後もっと磨きをかけていく予定です。

○印刷技術協会において出版記念セミナーも開催予定です。
電子書籍と日本語組版
「W3C技術ノート 日本語組版処理の要件」出版記念

○関連Webページ
日本語組版処理の要件を作ったJapanese Layout Task Forceのホームページ:http://www.w3.org/2007/02/japanese-layout/

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)の疑問はもう少し考えないと・・・

縦書きの数学書における英数字の方向は混沌

縦組みのときに、英数字を正立させるか横倒しにするかということについて、少しづつ調べています。で、英数字が沢山でてきそうな書籍のジャンルのひとつに数学関係があります。数学書の多くは、横組みなのですが、一般向けの数学書には縦組みの本をときどき見かけます。

で、次の3冊の縦組み数学書を調べてみました。

1.「いやでも楽しめる算数」(清水 義範著、講談社刊、2001年8月20日)
2.「江戸の数学教科書」(桜井 進、集英社インターナショナル刊、2009年2月28日)
3.「5分で楽しむ数学50話」(エアハルト・ベーレンツ著、岩波書店、2007年12月12日)

この3冊の本の縦組みのテキストの中で、英数字、特に数式がどのように扱われているかを整理すると次のようになります。

1.数式には文章の行の中に書くインライン数式と、数式だけで一つ以上の行領域を占めるブロック数式に分けることができます。

(1)ブロック数式はすべて数式ブロック全体を右に90°回転しています。従って、英数字も数式の記号もまとめて横倒しです。

(2)インライン数式の多くは数式の範囲を右に90°回転して横倒しで表記されます。長い数式ではすべて横倒しです。


(「5分で楽しむ数学50話」のp.12の一部)

上の図のe、xなどの数式中の1文字の定数や変数はすべて本文テキスト中で正立です。

上図左端行のeのx乗など1項の数式(べき乗)は正立表記です。

この中間の例として、上図の[3]の行f'(x)の横倒しと似たような数式を左端の行f(x)のように縦中横の形式で表記している例が見られます。この場合は、文字数にして4文字で正立、5文字で横倒しという区切りですが、むしろ1行の幅に入るなら正立、入らないなら横倒しとしているのかもしれません。

分数も同じようなことがあり、分母と分子が1桁の分数は分母の数値と分子数値を正立させ、分母と分子の桁数が大きくなるとYYY/XXXの形式で横倒しにしています。

他には長めのインライン数式を文字単位で正立させたり、「2n」を縦中横で表記したかと思うと、同一の本のなかで「πr」を横倒しにしてみたり、インライン数式を正立させるか横倒しにするかの判断は振れていることがわかります。特に2文字のインライン数式の方向性は振れています。

2.ラテンアルファベット

本文テキストの中のラテンアルファベットの方向は、通常の小説などと同じで、頭字語、1文字の大文字は正立です。

3.アラビア数字

アラビア数字は、1桁~2桁、場合によっては3桁までは縦中横正立です。それ以上長い桁数のアラビア数字を文字単位で正立させるか、数値として横倒しするかもかならずしも統一されていません。

次の3つの図は、「いやでも楽しめる算数」、「江戸の数学教科書」の中で数字がどのように表記されているか、例を並べてみたものです。ご覧いただくとおわかりのように、1冊の本のなかで、同じような数値が正立、横倒しの2種類の表記ででていたりします。かなり振れがあるといって良いと思います。


「いやでも楽しめる算数」の中の数値の表記例1


「いやでも楽しめる算数」の中の数値の表記例2


「江戸の数学教科書」の中の数値の表記例

3.方向とグリフ

(1)英数字の字形(グリフ)には半角形(アルファベットはプロポーショナル)と全角形がありますが、上の図で分かるように数式の変数や定数の正立するアルファベット文字は横倒しの数式中の文字と同じグリフになります。

(2)数字のグリフは1冊の本の中では1種類です。

4.補足:数字の扱いについて

(この書籍のことではありませんが)Twitterで教えてもらったことによると、@works014さんは「全角文字コードを正立、半角文字コードを縦中横・横倒しで表して、そのあと見え方として字形を統一する」そうです。なお、別の印刷会社の方に聞いた話では「入稿された原稿の数字を最初に全部半角文字コードに統一してから、正立する文字は回転させる」そうです。つまり、縦書きで数字の制作実務上の取り扱い方には二通りある、ということになります。

縦書きにおける文字の方向について、UTR#50改訂版ドラフトの内容紹介

縦書きにおける文字のデフォルト方向を定義するUnicodeの技術レポートUTR#50の新しい草案(Revison 3)が2月10日に公開されています。

Working draft of Proposed Draft Unicode Technical Report #50
UNICODE PROPERTIES FOR VERTICAL TEXT LAYOUT
http://www.unicode.org/reports/tr50/tr50-3.html

まだ作業中のようですが、以下に内容のあらましを紹介します。

Revision 2からの変更点は次のとおりです。

  1. Revison 2の中のEAC(East Asian Class)が取り除かれました。
  2. 従来のEAO(East Asian Orientation)は名前がEAVO(East Asian Vertical Orientation)に変更されました。
  3. 新しい特性として、DVO(Default Vertical Orientation)が導入されました。

EACは「日本語組版処理の要件」をもとにした空き量の調整ですが、これは、「縦組みにおける英数字成立論」でも疑問を提示しました通り、横組みにも適用されるものですし、そもそも空き量の調整は綺麗な組版のためのものなのでUnicodeのような文字コードレベルで規定するのがふさわしいかどうか疑問があります。取り除いたのは賢明と思います。

Revision 2ではEAOがEACに依存していましたが、この依存性に関する記述はなくなりました。この結果、本文からは全角文字と半角文字に関する記述はなくなりました。

DVOは次のように定義されています:
「文字がほとんど直立する世界における縦書きに使うことを意図している」(5 Properties)

この文章の意味はあまり明確ではありませんが、次の例が挙がっています。

  1. 西欧の縦組みテキストの例(文字を正立させて縦組みしている案内版)
  2. 日本の頭字語(DVD、TV)の例

EAOとDVOをどのように組み合わせるか、あるいは、なんらかの規則を設けるかなどは今後の検討課題となります(Editorial Warningsより)。

縦組みのときの方向特性値は従来どおりで変わりません。次のような定義です。

U:文字コード表に現れるのと同じ方向で直立する
S:文字コード表の方向から右に90度回転する
SB:横倒しにする括弧類
T:直立・横倒しではなくて縦組み時に異なるグリフ(字形)にする必要がある

新しいデータファイルが用意されています。
データファイル

基本ラテンの文字コード別にどのような割り当てになっているかを調べて見ます。

文字コード, DVOの値, EAVOの値
0020(‘ ‘), S , S (空白)
0021(!), U , S
0022(“) , U , S
0023(#) , U , S
0024($) , U , S
0025(%) , U , S
0026(&) , U , S
0027(‘) , U , S
0028(‘(‘) , S , S (開き括弧)
0029(‘)’) , S , S (閉じ括弧)
002A(*) , U , S
002B(+) , U , S
002C(,) , U , S
002D(-) , S , S
002E(.) , U , S
002F(/) , U , S
0030…0039(0…9) , U, S
003A(:) , U, S
003B(;) , U, S
003C(<) , U, S 003D(=) , U, S 003E(>) , U, S
003F(?) , U, S
0040(@) , U, S
0041…005A(A…Z) , U, S
005B([) , S , S
005C(\) , U , S (バックスラッシュ)
005D(]) , S , S
005E(^) , U , S
005F(_) , S , S
0060(`) , U , S
0061..007A(a…z) , U , S
007B({) , S , S
007C(|) , U , S
007D(}) , S , S
007E(~) , U , S

EAVOでは基本ラテンの(~U+007Eまでの)文字はすべて横倒しとなりますが、DVOでは縦書きにおいて括弧類など一部の文字(表でSになっている文字)のみを横倒し、ラテンアルファベットとアラビア数字はデフォルトで正立となります。DVOを使うと「縦組みにおける英数字正立論」の主張と同じとなります。

ここで規定する方向特性の値は、あくまでデフォルト値です。英数字はマークアップで明示的に指定して横倒しにすることはできます。

「縦組みにおける英数字正立論」では記号類は未検討でしたので、これから記号類を含めてもう少し精密な検討をして改訂したいと考えています。

○「縦組みにおける英数字正立論」:http://www.cas-ub.com/project/index.html 

○UTR#50付属のデータファイルでは、EAVO-A方式とEAVO-B方式の二通りがあります。A方式とはすべての記号類に’U’を割り当てる方式、B方式は矢印、数学記号、罫線記号、括弧に’S’を割り当て、その他の記号を’U’とする方式です。どちらが良いか意見を求めています。

縦組みにおける英数字正立論―まとめ

1月11日以来随時ブログで紹介してきましたUTR#50関係の話を「縦組みにおける英数字正立論」として整理しました。

「縦組みにおける英数字正立論1~18」としてストーリー化しましたが、これをCAS-UBでPDFとEPUBにしたバージョンもあります。

こちらからダウンロードしていただくことができます。

http://www.cas-ub.com/project/verticalwriting.epub

http://www.cas-ub.com/project/verticalwriting.pdf

「英数字正立論」を思いついたのはUTR#50(ドラフト)を読んで「これではだめだ。」と感じたからなのです。では、なぜ、そう感じたかと言いますとCAS-UBを開発する過程で、全角文字と半角文字を使い分けて縦組みのときの正立・横倒しを区別するという現状のやり方にいろいろと壁を感じていて解決策を模索していたことが背景にあります。UTR#50(ドラフト)は、解決どころかさらに壁を厚くしてしまうものと見えてしまったのです。

「英数字正立」をデフォルトにすべきという話を、W3CのCSSメーリング・リストに投稿したところ、ある日本人エディターから「日本でそんなことをいう人は他にはいない」と宣告されました。

CAS-UBは、コンテンツを出版形式とは完全に切り離したかたちで制作して、PDFもEPUBも自在に生成します。さらには、横組み・縦組みも自在に切り替えできます。おそらく、このようなことのできる出版コンテンツ制作サービスは世界に唯一と思います。

従って、CAS-UBの開発過程で生まれたアイデアが、「日本でそんなことをいう人は他にいない」と批評されるのは自然です。言ってみれば、独創性についてのお墨付きのようなものです:-)

「英数字正立」で問題点が解決できるかどうかは、もう少し検討を要するとは思いますが、どうやら、縦組みでは英数字を横に寝かせるのをデフォルトとするよりも、正立をデフォルトにするほうが、問題をスムースに解決できそうに感じています。

縦組みにおける英数字正立論18―参考文献

1.Unicodeで縦組みの文字の向きの標準を決める新しい仕様案 UTR#50 (http://unicode.org/reports/tr50/)
2.パブリックコメント:http://unicode.org/forum/viewforum.php?f=35
3.日本語での議論は「EPUB仕様についての情報・意見交換」でもhttp://groups.google.com/group/epub-spec-discussions
4.Twitter ハッシュタグは #UTR50
5.参考ブログ記事
5-1 CSSの縦組みとUnicodeの縦組みの文字の向き(UTR#50)の話題(CSS組版ブログ)http://blog.antenna.co.jp/CSSPage/2012/02/cssunicodeutr50.html
6.「PDFインフラストラクチャ解説」http://www.cas-ub.com/project/index.html

縦組みにおける英数字正立論17―英数字正立論の課題

英数字正立論はまだラフなアイデアのレベルです。これを精緻なものにするには検討すべきことがあります。

さしあたっては次のような批判が考えられます。

プレーン・テキストへの適用

【批判】プレーン・テキストのレベルではマークアップが使えない。すべて正立してしまうと困ることがあるだろう。

【対応】全角文字を使うというのは、XHTMLでは文字単位のマークアップにほぼ同じです。全角文字を廃止してしまうと、プレーン・テキストの段階では横倒しする文字と正立する文字を区別する方法がなくなり、結果として英語の文章などを横倒しさせることもできなくなります。従って、プレーン・テキストの中で横倒ししたい範囲を示したいときは、Unicodeに制御用コードを導入するなどの方式をとること必要があるでしょう。これと類似の方法はラテン文字とアラビア文字が混在したときの方向を制御するために、Unicodeでは古くから採用されており、特に新しい方法ではありません(Unicode Bidirectional Algorithm(UAX#9))。

正立させるに向かない文字列

【批判】アラビア数字で表した小数点がある数値、桁区切りのある数値はどうするか。

【対応】確かに、これを文字単位で正立させてしまうとおかしな表示になります。従って、このような数字は、text-orientationを指定して横倒しにするのが良いと思います。一方で、逆に縦組み用に全角文字で表した小数点のある数値や桁区切りのある数値を横組みにするとおかしな表示になります。つまり全角文字をつかっても縦横切り替えの問題は解消できません。このように数値については縦組みと横組みの互換をとるために何らかの新しい記法変換を考案する必要があります。

互換性

【批判】過去のデータ資産をどうするつもりか?

【対応】確かに、英数字正立論の最大の問題は過去との互換性となります。指摘の通り、過去のデータをどうするかということは大きな問題です。英数字の半角文字と全角文字の使い分けをやめて正規化文字に統一するのは相当な決断が必要になりますので、さらに慎重な検討が必要です。しかし、Webや電子書籍における縦組みはまだ始まったばかりなので、新しい方式を導入するのはいまの時点しかないことも確かです。