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人とも縦書きなんか未来はないし、意味がないのでやめるほうが良いといわれてしまいました。日本語の縦書きは風前の灯かな?しかし、組版ソフトのベンダとしてはどうしても避けて通れないんですよ。

「ぎりぎり合格への論文マニュアル」にみる英数字と記号の方向

「ぎりぎり合格への論文マニュアル」(山内 志朗、平凡社新書)は英数字の使い方は一般的ですが、記号の使い方に特徴があります。特に「記号の使用法」という節を設けて、論文の中での記号の使い方を比較的詳しく説明しています。

1.ラテンアルファベット
ラテンアルファベットの使い方は一般的です。

(1)全角形・正立
・JIS、DTP、などの頭字語、MS-DOSのようなハイフンを含む固有名詞は全角形・正立です。
・(a)、(b)のような箇条書きでは全角形・正立
・A4、B5のような慣用区は全角形・正立

(2)横倒し
・英語、ラテン語、フランス語などの単語
・ページ番号(p.)、行数(l.)などの略記用記号
・欧文参考文献(著者、題名、発行所など)

2.数字
・本書は伝統的組版に属し[1]。和文中では数字は漢数字が原則です。フォントのサイズについても、九ポイント、十二ポイントなど漢数字です。先日の「新版論文の教室」も伝統的組版ですがフォントサイズはアラビア数字の正立形です。従って、本書は伝統的組版でも右翼に属すると言えます。
・それでも、[1]など番号箇条書き、「だんご3兄弟」(p.24)のような固有名詞とA4、B5のような慣用句ではアラビア数字が正立で使われています。
・引用文献、参考文献などの文脈ではアラビア数字を横倒しで使っています。

3.記号類
記号の種類と方向については「JIS X4051で規定する縦組み時の字形と現実の書籍で使われている文字の向きの比較考証」[2]に使ったPDFデータを改訂してアップしました:記号類の方向調査表(9/23)

本書では記号がいろいろ珍しい使い方がなされています。

1) 「:」、「;」、「,」が正立ででてきます。これらは記号の字形の紹介の意図と思います。
2) 一方、本文の中では「:」は横倒しで使われています。「:」については「本来欧文用の記号で横組み日本語に転用されるようになったもの」(p.94)という説明があります。縦組みの本書でも使っているのは、少々、矛盾するような印象を受けます。
3) 句読点の列挙で 「.」「,」「、」「。」が左右中央に表示されています。これは良識なんでしょうが、読点の位置が中央に揃っていません。
4) 番号箇条の番号に漢字を使って、区切り記号に「.」を使っています(p74)。「.」が右側になっています。これは正しいと思いますが、位置の調整はどうしたのでしょうか?
5) 波ダッシュに正立と横倒しの両方の例が紹介されています(p.108)。
6) ハイフンは「基本的に横書き向きだが、最近は縦書き日本語でも二つの概念の密接な連関を示す場合に用いられる。この辺の使用法ははっきりしない。」(p.110)とありますが、本書では、Ⅲ‐ⅵにハイフンを使っているように見えます。

こうしてみますと、コロン、セミコロン、カンマ、ピリオド、引用符などを含めて、欧文から由来した記号は、まず日本語の横書きに導入され、さらに縦書きに持ち込まれることになるという道筋をたどるため、使い方がとても難しくなることがわかります。こうした文字の用法が確立するまでにまだかなりの年月がかかるのではないでしょうか。

4.書籍の情報
書名:「ぎりぎり合格への論文マニュアル」
著者:山内 志朗
発行所:平凡社新書
発行年:2001年9月初版発行
ISBN:978-4-582-85103-8


[1] 伝統的組版については「英数字正立論」(http://www.cas-ub.com/project/index.html#Free)を参照してください。
[2] JIS X4051で規定する縦組み時の字形と現実の書籍で使われている文字の向きの比較考証

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

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

「新版論文の教室」には書籍の縦組みレイアウトパターンと文字の方向パターンの典型例がある

「新版論文の教室」(戸田山 和久)は本書は現在の書籍の縦組みの複雑さを典型的に表していて、縦組みにおける英数字と記号などの向きの取り扱いを考える上では格好の材料です。なぜならば、日本語縦組み書籍のページレイアウトと縦組みにおけるラテンアルファベット、アラビア数字、記号の文字方向についてそれぞれの典型パターンを見ることができるからです。

I. 本書のレイアウト概要

1. 本書のページレイアウト・パターン
(1) 本文は縦組みです。
(2) ところどころに1ページまたは見開ページ全体を横組みしたページがあります。
(3) 縦組みのページの中に部分横書きの図が配置されているページがあります。

2. 英数字と記号の使い方パターンまとめ
最初に本書の英数字・記号の使い方には次の特長があります。
①本文は縦組みで数字は漢数字を原則としています。つまり伝統的組版に属します[1]。
②順序数としてのアラビア数字は頻出し、和字扱いのラテンアルファベット、記号類も豊富に使われています。
③アラビア数字だけの縦中横のみでなく、ラテンアルファベットと記号を組み合わせた縦中横、カタカナと記号を組み合わせた縦中横も使われています。
④論文の書き方に関するテキストということで文献の参照の記述方法とか、参考文献リストの書き方説明があります。
⑤テキストブックなので間違った例があります。つまり本来使うべきでない使い方の例もあります。

(1) ラテンアルファベットの使い方・パターン
・正立は1文字の記号、頭字語、および項目番号(順序をあらわす記号)として
・横倒しは英語の単語・フレーズ、参考文献引用箇所表示と参考文献一覧の著者名・欧文書名・雑誌名・欧文参考文献のタイトル・出版社名・ページ(p)
・記号と組み合わせての縦中横

(2) アラビア数字の使い方・パターン
・本書は伝統的組版に属します。つまり本文の文中の数字は漢数字が原則です。しかし、アラビア数字も一杯でてきます。アラビア数字の利用パターンのほとんどは章番号、節番号、項目番号、図番号、ページ番号などの順序数、ならびにそれらへの参照テキストです。これらは1から開始して2桁になることがあり、1桁では正立、2桁は縦中横です。ページ番号参照は3桁まで縦中横です。
・数値は原則漢数字でアラビア数字正立はあまり出てきません。但し、例外はフォントサイズを表すポイント数がアラビア数字の数値です。慣用でアラビア数字と判断しているのでしょう。漢数字基本で書いても、漢数字で表すのに不適切な数値があるということです。
・A4などの慣用句は1文字づつ正立です。
・本文中の年号は漢数字ですが、参考文献の発行年とページ数はアラビア数字で横倒し、また引用ページ番号の表記は横倒しです。但し、和書・雑誌の表題はアラビア数字正立もでてきます。「表題」のように原題を変更できないときは、原則と異なる表記も必要となります。

(3) 記号類の使い方・パターン
記号類についても正立・横倒し・縦中横(ラテンアルファベットと組み合わせで正立する)が出現します。

Ⅱ 本書における英数字・記号の使い方(詳細)

1.著者による全角・半角・数字の表記

この本の著者は、全角・半角・数字の表記について次のように書いています[2]。

○全角・半角・数字の表記の項(pp.256-7)
(1) 横書きの文章の場合、数字や年号はすべて半角の算用数字というのが基本だ。全角数字を使って「1995年」と書くのはやめる。
例外として、熟語や固有名詞の一部になっている場合は漢数字を使う。悩ましいのは「1つ」「2つ」「第1に」とするか「一つ」「二つ」「第一に」とするかだが、これはどちらもある。統一が取れているのが大事。算用数字で「1つ」と書く場合は、半角ではなく全角を使う。
(2) 外国語も半角がきまりである。

2. ラテンアルファベットの使い方・パターン例
(1) 1文字毎正立
・順序を表す:付録A~E、パターンA~パターンC、成績のA、B、C
・記号:「Aなんじゃ」、「A」、AならばBである、AであればB、Aではない/Aである、Aの話、Bの話、aとbが似ている、物体X
・頭字語:NHK、OKだから、ATOK、DVD、NASA、RPG法、UFO、CD
・人名:R・A・ラファティ
・慣用句:A4

(2) 縦中横
・対立仮説H´ [Hとプライムの組み合わせ]
・(a)も(b)も [()との組み合わせ]

(3) 横倒し
・欧文単語~文:(right)、concept、conception、real、検索結果がaggregation, assemblage, assembly, assortment, bee, body, breedと… 、“Pay it forward”、“it”、“You’re really something”、euphemism、(Sokal’s Hoax)、(profession)、comestibles、food、skelton、abduction、induction、dedcution、(the thing)、(references)、
・Webのサービス名・URL:infoseek、Yahoo、Google、goo、http://www…、Reliable sources、CiNii Books (http://ci.nii.ac.jp/books)、CiNii Articles (http://ci.nii.ac.jp/)
・引用箇所を表記するときの文献名、著者名、ページ番号:(Papinou 1996 p.2)
・英文参考文献の著者名、論文タイトル、書名・雑誌名、出版社名、出現ページ範囲:Simpson, L. (2991). “How to Play the Alto-Saxophone”, Murphy, B. G. ed. Modern Jazz Performance, Horny Dick Press. pp. 156-201

3. アラビア数字
(1) 正立
・章番号:第1章~第9章
・章番号参照:第2章では、第4章の内容には
・節番号:1-1~9-5
・節番号参照:3-6でも触れたが、
・項目番号:その1~その5、【1】~【3】[【】は数字の上下につき、数字のみ正立]、【鉄則1】~【鉄則9】【練習問題1】~【練習問題9】、(2-1)~(2-3)、テクニック1~、条件1~条件2、例1、例2
・項目番号参照:[鉄則1]
・図番号参照:図1~図9 [図自体は横書きであり、図番号・キャプションは横書き。本文内の図番号参照は縦書きである。]
・横書きページ中のテキストを縦書き内から参照:アウトライン・バージョン2
・慣用句:A4
・数値:0点、10・5ポイント[3]

(2) 縦中横
・目次項目のページ番号:2桁、3桁のページ番号が縦中横
・項目番号:(1)~(3)[これはU+2474~でも可]、【鉄則10】~【鉄則36】、【練習問題10】~【練習問題17】
・ページ番号参照:19ページ[2桁ページ番号参照]、108~109ページ[3桁ページ番号参照]
・図番号参照:図11~
・注番号と注の合印:(23)と注の合印(23)、注23
・数値(2桁):12ポイント

(3) 横倒し
・引用文献参照の出版年・ページ番号:(Papinou 1996 p.2)
・参考文献の出版年・ページ番号:ラテンアルファベットの横倒しの例を参照。

4. 記号の使い方・パターン
(1) 正立
・部番号:Ⅰ~Ⅴ
・区切り記号:!?‼
・箇条書き:㋑㋺…、①②…、
・その他:α、★(箇条書きラベル参照)、★(箇条書きラベル)、/、段落の区切りに(/)を入れる、%、†

(2) 縦中横
・括弧がローマ数字と組み合わせて正立:(i)~(ⅲ)
・縦中横で記号の方向は変わらない:カ*(記号の派生)

(3) 横倒し
・「」『』【】()[]
・… ― = ~:;“”.,
・矢印:⇔、→

※次は、横倒し文脈内の例である。
・;[引用文献の文献間区切り]
・英語と一緒:“”、’、.、,

5. 横書きのページ
・pp.108~109:(1)~(3)、Ⅰ~Ⅵ、NASA、→、Groupthink、?
・p.111:バージョン0、Ⅰ~Ⅴ、(1)~(3)が登場する。
・p.117:同
・p.127:[]、()、?、/
・p.136:バージョン1、「」
・p.143:バージョン2
・p.176:aもbも、AならBである

6. 部分横書き
・柱:章番号
・図:図1~図16(ラベル)、根拠1~、∴、()

Ⅲ 書籍の情報
書名:「新版論文の教室」
著者:戸田山 和久
発行所:NHKBooks
発行年:2012年8月第1刷発行
ISBN:978-4-14-091194-5


[1] 伝統的組版については「縦組み時の文字方向について:UTR#50のSVOデフォルト、MVOデフォルト、現代方式、伝統方式、新聞方式の相違を分析する」を参照。
[2] この部分は、漢数字とアラビア数字の使い分けと、全角・半角の使い分けの話が入り混じっています。このうち、全角・半角については横書きでは英数字は半角が原則としています。ただし、アラビア数字1文字のときだけは全角としています。ここでいう半角・全角は、専門的には文字コードではなくてグリフ(字形)と解釈すべきです。但し、InDesignのような印刷専門のソフトでは文字コードとグリフを独立に扱うことができますが、オフィスソフトのような一般向けのツールの多くは文字コードとグリフを独立に扱う機能がないことが多いので、「1つ」は全角文字(コード)を使うと解釈しても問題は生じません。
[3] 縦横変換の難しい例である。横書きで10.5のように2桁の数字と1桁の数字が連続するとき、10を半角、5を全角(10.5)とすると非常に見にくい。横書きでは10.5→縦書きでは10・5と小数点が別の文字になる。

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

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

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を縦中横にしているときも同じで「-」は横書き中とみなすなどの前提を置く。

AmazonのKindle出版ガイドのちょっとした紹介とCAS-UBのKindle形式対応予告

今日は、Amazon Kindle出版ガイドについて少し紹介します。EPUBの仕様に詳しい方はお分かりの通り、Amazon KindleはEPUB3と微妙に違いがあります。
・EPUB3ではなくなったNCXやguideの記述が必要です。
・表紙画像と目次に一部独自部分があります。

現在のCAS-UBが出力するEPUBは、KindleGenでmobi形式に変換できます。しかし、下記のガイドラインを見ますとまだ機能的な対応が不十分です。そこで、ただいま、Amazon Kindleガイドラインに従った形式のEPUBを作成してmobi形式に変換するカスタマイズ機能を開発中です。9月末~10月頭頃から提供開始の予定です。

以下は「Publishing on Kindle: Guidelines for Publishers Version 2012.4」[1]のほんのさわりの紹介です。一部を引用しています。

1.一般的なガイドライン

Kindle Format 8 (KF8) は次世代Kindle本のファイル形式であり、Mobi 7を置き換える。Kindle FireがKF8をサポートする最初の機器である。

2.テキスト

1) リフロー文書の本文(body text)のスタイルはすべてデフォルトにする。
2)改ページはCSSの page-break-before, page-break-afterを使うこと
3) KindleGenはデフォルトですべての段落の最初の行をインデントする。この挙動を避けるには、<p>タグにtext-indentスタイルを設定すること。
4) HTMLエンコードィングを記述すれば、変換に使用するコンピュータがサポートしていれば利用できる。
5) 空白としては、通常の空白、 , ‌のみをサポートする。
6) モノスペースフォントをサポートする。次のタグの内容をモノスペースでレンダリングする:<pre>, <code>, <samp>, <kdb>, <tt>, <font face="courier">, <font face="monospace">

3.CSS

KF8でCSSサポートが強化された。

1) width, height, margin, padding, text-indent, line-heightではポイントやピクセルのような固定値を避けること。
2) margin, paddingを使うときはem単位の代わりに%を使うこと。これにより、フォントを大きくすると余白が大きくなることを避ける。
3) line-height は1.2emまたは120%より小さい値を有効とみなさない。
4) ドロップ・キャップのような要素はパーセントまたは相対単位を使って指定すること。サンプルCSSが掲示されている(p.13)。

4.表紙の画像

4.1 販売用の表紙画像

1) Kindle本には販売用のカバーイメージの提供が必須であり、これはWebサイトの詳細ページに使用する。
2) 販促用表紙は長辺 2500Pixel(最低1000ピクセル)。最小側500ピクセルよりも小さい表紙はアップロードできるが表示されない。
3) 小さくてもエラーメッセージは表示されない。
4) JPEGイメージが望ましい。

4.2 内部コンテンツ用の表紙

1) 必須である。大きなイメージを用意せよ。小さなイメージではAmazonの品質管理をクリアできないだろう。
2) OPFに次のように定義せよ。

a. metadata

<meta name="cover" content="my-cover-image" />

b. manifest

<item href="MyCoverImage.jpg" id="my-cover-image" media-type="image/jpeg" />

3) メタデータ要素に、name=”cover”が必須である。IDPFの標準ではないが、IDPFのバリデータは通る。

4.3 内部カバー

表紙画像を前項で説明した以外の方法で追加してはならない。さもないと、本の中に表紙が2回現れてしまうかもしれない。
例外的に、もし、他のベンダーのソフトと互換性を持たせるために固有の論理カバーの他に、HTMLの表紙画像をつけたいのならば、OPFファイルに次のすべての要素を付加せよ。

1) spine-itemrefのlinear=”no”属性

<itemref idref="my-html-cover" linear="no" />

2) manifest

<item id="my-html-cover" href="cover.xml" media-type="application/xhtml+xml" />

3) guideのreference要素 title="cover"属性は必須である。

<reference type="cover" title="Cover Image" href="cover.xml" />

5. 目次

5.1 方針

1) Kindleでは目次を二つ作ることを勧める。一つはNCX(必須)であり、いまひとつはHTML形式のTOCである。
2) HTML形式のTOCを作ることを強く薦める。但し、固定レイアウトの子供向けの本、固定レイアウトのグラフィックス小説・漫画・コミックは例外。

5.2 論理目次(NCX)は必須

1) 論理目次(NCX)とHTMLのTOCの両方を持たせるべき
2) ユーザーは書籍の最初からページめくりするのにHTML形式の目次を期待する。一方論理目次(NCX)は本をナビゲートするもう一つの方法だ。論理目次はEPUB2.0仕様の一部。
3) NCXをmanifestとspineで指定する方法はEPUB2.0と同じ。

5.3 HTML 目次をリンクしなければならない

1) 目次をもつHTMLページを書籍の先頭に置くこと。HTML目次のエントリーは、ユーザーが指定した場所(章など)にジャンプするためのHTMLリンクであること。
2) KindleのメニューからTOCにジャンプできるようにするためには、OPFファイルはTOCをTOCガイド項目から参照しなければならない。すべてのKindle機器・アプリには、書籍の任意の場所から目次のガイド項目にジャンプするインターフェイスがある。サンプルを見よ。
3) 目次(TOC)を作るのに表(テーブル)を使ってはいけない。TOCの中に<table>
タグがあったとき、TOCの中のリンクをクリックできなくなる。
4) 目次にページ番号を入れないこと。Wordからインポートするのであれば、Wordの’Heading’スタイルと’Table of Contents’機能を使うこと。そうすると、Wordで生成した目次は正しくインポートされてこのガイドラインに従う目次になる。
5) 目次を本の最初に置くこと。最後ではいけない。
6) バンドル版には全体にわたるファイルの先頭に目次を含めること。

6. ガイド項目

1) Kindleは表紙、目次(TOC)、開始位置(”Go to Beginning”)を定義するガイド項目をサポートしている。
2) アマゾンは、OPFファイルに他のガイド項目を含めることを推奨しない。他の項目は、メニューでグレイアウトされてしまい混乱の元になる。

(注意)guide要素はEPUB3では廃止されたが、過去との互換性のためにEPUB3のOPFに含めることができる。但し、EPUB3のリーダはguideを無視することとなっている。EPUB3ではlandmark (<nav epub:type="landmarks">)を使う。

7. スタイル

入れ子になったHTML TOCをあらわす構文の二つの例が紹介されている。

(1) スタイル属性を使う方法

<div>Section 1</div>
<div style="margin-left:1em;">Chapter 1</div>
<div style="margin-left:1em;">Chapter 2</div>
<div style="margin-left:1em;">Chapter 3</div>
<div style="margin-left:2em;">Subchapter 1</div>
<div style="margin-left:2em;">Subchapter 2</div>
<div style="margin-left:1em;">Chapter 4</div>
<div style="margin-left:2em;">Subchapter 1</div>
<div>Section 2</div>

(2) CSSクラスを使う方法

a. CSS
div.chapter { margin-left: 1em}
div.subchapter { margin-left: 2em}

b. XHTML
<div>Section 1</div>
<div class="chapter">Chapter 1</div>
<div class="chapter">Chapter 2</div>
<div class="chapter">Chapter 3</div>
<div class="subchapter">Subchapter 1</div>
<div class="subchapter">Subchapter 2</div>
<div class="chapter">Chapter 4</div>
<div class="subchapter">Subchapter 1</div>
<div>Section 2</div>

8. フォント

1) KF8はeBookの中の埋め込みフォントをサポートしている。
2) OpenType, TrueTypeはOK。Type1(PSフォント)はサポートしていない。
3) 本の中で使っているフォントだけを含めること。
4) Charis フォントを含める必要はない。
5) 本の中のフォント・ファイルは再利用の可能性を減らすために意図的に難読化している。しかし、出版社はフォントの権利の適切なライセンスを確保する責任がある。

[1] Publishing on Kindle: Guidelines for Publishers Version 2012.4

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

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

電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。

9月11日に電書協EPUB3制作ガイドのV1.0が公開された[1]。以下は、個人的に気になった点をリストしておきます。まだ他にも一杯あると思いますのでだんだん追加します。ここに書いたのは単なる個人的感想ですから、ご参考まで。

全体としては不必要な規制が多いという印象を受けます。こうした不必要な規制は標準のEPUB/XMLツールでは検証できないのですが、できあがったEPUBがガイド準拠であることをどうやって保証するのだろうか?まさか目視?それはないよね。

1.フォルダー構造とファイル名
[ガイドの記述](p.20)
・素材を格納するフォルダの名前が指定されています。
・itemフォルダにすべての素材を含める。その下の、image、style、xhtmlの3つのフォルダにそれぞれ画像、CSS、xhtmlの3つのファイルを収めています。
・opfファイル名(standard.opf)、ナビゲーションファイル名(navigation-document.xhtml)が指定されています。

[コメント]
・EPUBの仕様ではファイル名やフォルダー名は特に指定されていません。すべてのリソースはopfファイルの中に記述し、またファイルの読む順序はspineで指定するなどOPFには必要十分な規定があります。それなのにガイドでさらに枠をはめているのは無用です。
・このために電書協専用の出力メニューを用意する必要があります。
・これを守らないとどうなるのでしょうか?
・準拠しているかどうかを検証するツールがないと判定できないと思います。

2.idの重複を避ける
[ガイドの記述](p.67)
・idは、本来、各ページ(XHTMLファイル)ごとにユニークであれば構わないものですが、複数ファイルからなるEPUBデータの構成を鑑みて、ひとつの作品を通じてユニークな値であるものとします。

[コメント]
・ひとつの作品を通じてユニークな値にしなければいけない理由が理解できません。
・作品が多数のファイルから構成される場合、idが作品内でユニークかどうかをどうやって検証するんでしょう。検証ツールがあるのでしょうか?XML標準ではそんなツールはないと思います。

3. 文字コード
[ガイドの記述](p.9)、(p.45)
・p.9では、少なくとも、以下の文字集合をサポートするものとする:JIS X0213:2004
・p.45には、JIS X0213:2004にない文字は外字画像化。

[コメント]
・p.9の記述とp.45の記述は一貫していません。しかし、将来の発展性とか表現の自由度を考えるとむしろ、外字のフォント埋め込み、あるいは、missing glyphを読者に伝える仕組みを用意する という選択もあると思います。
・[2012/9/13追記]これは、結局、フォント埋め込み以外に解決策がないように思います。フォント埋め込みは技術的には簡単なのでRSがサポートしないはずはないですが、むしろ、ライセンス許諾の問題です。

4.ソースの整形
[ガイドの記述](p.22)
・divなどのブロックレベル的な要素では、必ず開始タグと閉じタグの直前直後にそれぞれ改行コードを入れるようにします。但し、p,h1~h6タグについては、開始タグの直後、閉じタグの直前には改行コードを入れないようにします。
・aの場合は、aがブロックレベル的要素かimgを囲むのでないかぎり、改行コードを入れないようにします。

[コメント]
・ソースの整形を厳密に規定しても、これを遵守するのは難しいと思います。遵守するメリットもないような。
・インラインタグの内部では改行が空白になってしまうので、不用意に改行を入れてはいけないと書くだけで良いのではないだろうか。
・いづれにせよこれを遵守しようとすると手作業では無理で専用のツールが必要でしょう。
・サンプルをみると、大よそその通りの整形がなされています。エライ!でもそんな必要ないんです。
・[9/12 10:03 追記]他の整形例にはこんなのもあります[3]。XMLオーサリングでエラーになるのは多くの場合タグのネスト関係。結局、タグの階層構造が問題になるので、階層をチェックする整形方法の方が有効だと思います。
・[9/12 11:50 追記]XMLのドキュメントが正しいかどうかをチェックするのはXMLパーサーを使います。EPUBCheckも内部にはXMLパーサー。改行によるテキストレベルの整形は、RSで見たとき空白が挿入される危険性を避ける注意事項以外にはあまり意味がないと思うのですが。
・[9/14 追記]XML文書を整形すると確かにソースのヒューマン・リーダビリティは高まります。しかし、このガイドで記述するような整形基準はみたことがない。そもそもXMLはプログラムで処理するものだし、リーダもプログラムなのでCSSで規定する以外の整形基準はリーダには影響を与えないのです。なのでソースのヒューマン・リーダビリティは、人間がソースをエディタで修正するときしか意味がありません。管理が簡単になることはないと思うのだけどね。

5.クラス属性
[ガイドの記述](p.9)、(p.45)
・CSSのクラスの種類が大量に定義されています。
・[2012/9/13追記]XHTMLに規定されている要素であるsub、supをクラス属性で定義しています。

[コメント]
・要素の種類が少なくてもクラスの種類が山ほどあり、これを全部覚えて、オーサリングを手作業で行なうのは至難のように思います。
・結局、専用のツールが必要になるように思います。
・[2012/9/13追記]Web標準ではだめとされている手法というコメントがあった[4]。しかしなあ、というクラスが多い。クラス属性はEPUBCheckにかからないので、クラス属性をつかうと、XHTML構文に基づきながらも何でもありになってしまうのです。CAS-UBでも一部これを利用しているので、批判すると目くそが鼻くそを笑うという話になってしまいますが。

■感想
・村田真さんによりますと、ガイドラインには「ガイドラインには大きく分けると、考えて自分で決めなさいというガイドライン、この通りにやればできるから考えるなというガイドラインがある」[2]とのことですが、どうもこのガイドラインは「自分で考えずにこの通りやりなさい」というものになります。で、この方針で生産性を上げようとすると、「電書協EPUB3」専用のツール(CAS-UBでは、文書型、専用編集メニュー、出力形式・生成フィルターの追加)が必要になります。ガイドに記述されていることの多くは技術的に見るとやる必要のないことなので、システム開発にコストがかかる割には、それによってできること(効用)が少なすぎるなあ…「電書協」対応ブランドをつけることぐらいしかシステム対応の意味がない…
・需要があれば作りますが、なんというか、どうでも良い瑣末なことばかりだ。あまり開発モチベーションが沸かないなあ。どうしてこんなくだらないことばかり決めるのがまったく理解できない。

[1] 「電書協EPUB 3 制作ガイド ver.1.0」
[2] https://twitter.com/muratamakoto/status/245544497704996864
[3] http://twitpic.com/atnh9a
[4] https://twitter.com/MurakamiShinyu/status/245738412496265217

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

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

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

CAS-SUPPORTのブログ 8月分をEPUBにしました。

CAS-SUPPORTのブログ 8月分をEPUB3にして、サンプルページに追加しました。

CAS-SUPPORTのブログ8月分(epub)

ブログはWordPressで書いています。これをEPUBにする手順は次のとおりです。

1.ブログ記事のエクスポート(XMLファイル化)
1)WordPressの管理者でログイン
2)WordPressのツールメニューのエクスポート機能を選択
3)8月分の記事をエクスポート

2.CAS-UBにインポート
1)CAS-UBで新しい出版物を作成
2)出版物の一覧で「編集」を選択して編集画面に遷移。そこで「ドラフト」を選択。
3)インポートファイルの形式でWordPressのXML形式(WXR形式)を選択
4)1.で作成したXMLファイルを選択してインポートする。
5)ブログ記事が正しくインポートされていることを確認する
6)記事をすべて選んで「主原稿」に移動する
7)記事の編集
(1)WordPressのエクスポートでは画像がリンクになり、画像を取り出すことができないため、画像を手動でダウンロードして、記事の中にアップロードする。
(2)ブログの記事を参照している箇所を、EPUBの記事の参照に変更する

3.内容を確認してEPUBを作成

CAS-UBはほかのツールよりも生産性が高いと思いますが、それでも、1.~3.までの処理に1時間強かかりました。なんとか、もっと短時間でできるようにしたいものです。

■ご案内

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

縦組みにおける記号の扱い―JIS X4051を検討して見えるもの

「英数字正立論」[1]は現在0.5版ですが、現時点で欠けているのが記号類の扱いです。

これまでで、英数字についての考え方は大体整理できましたので、現在は記号類に取り組んでいます。最初に、記号類についての基本的な考え方を整理しなければなりません。そのため日本語組版に関するJIS規格であるJIS X4051を見てみましょう。

1. 組版上特殊な役割をもつ記号

JIS X 4051では文字をクラス[2]に分けており、記号類の多くは一般の和字(文字クラス表では(1)~(12)以外の和字)または欧字に含まれています。しかし、記号類は文章を区切ったり、あるいは単位として扱うため特殊な役割を負っており、特別文字クラスに分類されているものが多数あります。特別な文字クラスの大半は記号類です。

各クラスに分類されている文字(記号以外には小書きのカタカナなどを含む)は横書きのときの文字種を基準にして、縦書きで異なるものを付属書1の別表2~13に記載しています。別表の文字について縦書きと横書きでの相違・類似は表の通りで次のように整理できます。

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

文字クラス 付属書1 文字数 横書きと縦書きで字形を変える 横書き専用 縦書き専用 縦横同形
小計 回転する 回転以外
(1) 始め括弧類 表2 16 15 14 1 1 0 0
(2) 終わり括弧類 表3 18 16 14 2 2 0 0
(3) 行頭禁則文字 表4 47 41 0 41 0 1 5
(4) ハイフン類 表5 4 3 2 1 1 0 0
(5) 区切り約物 表6 6 0 0 0 0 0 6
(6) 中点類 表7 3 2 2 0 1 0 0
(7) 句点類 表8 2 1 0 1 1 0 0
(8) 分離禁止文字 表9 6 3 3 0 0 3 0
(9) 前置省略記号 表10 6 0 0 0 0 0 6
(10) 後置省略記号 表11 9 0 0 0 3 0 6
(20) 割注始め括弧類 表12 3 3 3 0 0 0 0
(21) 割注終わり括弧類 表13 3 3 3 0 0 0 0
合計 123 87 41 46 9 4 23

2. 一般の文字

一般の和字と欧文用欧字の中にも記号類が多数ありますが、JIS X4051には横書きと縦書きの字形の相違の記載がありません。これについてはJIS X0213 の付属書4に記載がありますが、縦書きと横書きで字形が異なる例として掲載されているのは、全角ミリ(U+3349:㍉)などの16文字のみです[3]。これは一般の和字に分類されます。

欧文用文字には、コンマ、ピリオド、コロン、セミコロンなど欧文組版で使う記号類も分類されています。またアラビア数字も欧文用文字の中に含まれます。こうしてみますと、欧文用空白(20)と欧文用文字(21)だけを使って欧文組版が実現できますので、JIS X4051では欧文の世界を、別世界と考えていることになります。

3.まとめ

(1) JIS X4051では和文と欧文を分類しており、和文の中で特別な役目をもつ記号類などをクラスにまとめています。 特別な役目をもつ記号で縦書きと横書きで字形が異なるものは87文字です。

(2) 欧文用の記号類だけでなくアラビア数字も欧文用文字に分類しています。欧文用文字に分類されている文字種はそれだけで欧文組版ができます。欧文には縦組みという概念はないので縦組みと横組みで方向や形が変わるのは、和字の記号だけと考えるのが良いようです。

[1] 「英数字正立論」
[2] JIS x4051のクラスに属する文字は既定値であり、システムで追加できる。
[3] Unicodeにはこの種の文字がもっと沢山規定されていますが、JIS X0213では数が少ない。

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

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

縦組みは複雑さを増し、移行期的混乱状態。その原因は英数字の書字方向にある。

「横書き登場」(屋名池 誠著、岩波新書、2003年初版発行)[1]を読むと、幕末・明治時代から西欧の文明を取り入れる過程で横書きの普及が始まって、現在に至っていることがはっきり分かる。最初は、和字を右から左に書く右横書きと、左から右に書き進める左横書きが行なわれ、戦前までは併用されていたが、戦後に急速に左横書きに一本化された。

英語を中心とする欧米の文字は左横書きしか向かないラテンアルファベットで綴られているため欧文を和文中に取り込むためには左横書きが便利である。これに対して右横書きは和文中に欧文を取り込む上ではあまりメリットはない。戦後になって日本が米国の勢力圏になってあっという間に左横書きに統一されたのは自然とも言える。「横書き登場」では最初の左横書きの出版物は1871年(明治4年)に登場したとしている(p.61)ので、左横書きという書字方向が確立するのに70年~80年という期間がかかったことになる。

現在の出版物は、(1)横書きのみで構成する横組みと(2)縦書きを主体とし補助的に横書きを併用する縦組みの二つの組版方式が使われている。

横組みと比べると縦組みでは文字や行を進める方向が複雑に入り組んでいることが多い。この複雑さの主な原因はラテンアルファベットとアラビア数字(以下、総称して英数字)である。どのような複雑さがあるかを整理すると次のようになる。

■縦組み書籍の中の横組み頁

書籍などの出版物は、縦組みに分類されるものであっても、すべての頁が縦書きだけで組まれているものはほとんど存在しない。表1にあげるような横組み頁も併用されている。

表1 縦組み出版物の中での横組み頁
・参考文献
・索引
・表紙、章扉、奥付け

表紙や扉の横組みはデザイン上の配慮によるものが多いだろうが、参考文献や索引は英数字を多用することが横組みにする理由だろう。

■縦組み頁の中の横書き箇所

縦組み頁の中の一部に横書きのブロックが入ることも多い。表2のようなケースがある。

表2 縦組み頁の中の横書き箇所
・表は表自体の行とセルの組み方が横書きのものが主流であり、そのときセル内の数字や文章は横書きになる。
・図表の番号、キャプション、図表の説明文。
・目次のページ番号(縦中横)
・各頁のノンブル、頁上・下の柱

表2のような横書きが使われる箇所で使われる数字の種類はアラビア数字である。

■本文の中の英数字の扱い

さらに、縦書きの本文テキストの行中(インライン)での英数字の取り扱いの方法には次の3通りの方法がある。

①英数字を和字として扱う。このときは全角字形を使い、正立させる。
②英数字を欧字として扱う。このときはプロポーショナル字形を使い、文字列全体を横倒しする。このとき和字は日本語組版規則にしたがうが、欧字は欧文組版規則に従う。和欧混植方式となる。
③アラビア数字やラテンアルファベットの組を縦中横で配置する。縦中横には表3のようなケースがある。

表3 縦中横の適用箇所
・月、日、年齢などの2桁の数字を縦中横で配置するとき
・本文中から2桁または3桁の章番号、頁番号を参照するとき
・注番号、箇条書き番号などを(1)のように縦中横で扱うとき
・本文中の2桁の数値(アラビア数字)などを縦中横として扱うとき

■縦組みの類型

現在の日本語縦組み出版物における、本文テキスト中での英数字の取り扱い類型は大よそ3つである。

①新聞方式:朝日、読売、日経等の大新聞は、21世紀になってから、2桁の数字については縦中横表記とするが、それ以外のほぼすべての英数字を和字として扱う方式に移行した。

②伝統的方式:数量を表すアラビア数字は漢数字表記とする。固有名詞や慣用句はアラビア数字のままである。また図表番号や章番号などの参照は、参照先がアラビア数字の場合はアラビア数字のことが多い。従って、伝統的方式であってもアラビア数字は随所に使われる。外来語をはじめ外国人などの人名など欧文の単語はできるだけカタカナで表記する。カタカナ表記の括弧内に原文のラテンラテンアルファベット表記を添える。この時ラテンラテンアルファベットは和欧混植の対象となる。

②現代的方式:アラビア数字は新聞と同じように和字として全角形で正立する。頭字語のラテンラテンアルファベット大文字は和字扱いする。商品名などではラテンラテンアルファベット大文字と小文字が入り混じるが、そのとき文字列全体を和字扱いとしたり、または大文字だけなら和字扱いで正立・小文字が入ると文字列全体を横倒しする。どのような種類の文字列を正立させるかあるいは横倒しするかの基準は曖昧で書籍毎に異なるし、書籍の中でも完全に統一されていないときがある。

■縦組みの未来

商品名(iPhone、iPadなど)、サービス名(twitter、facebookなど)、人気グループ名、会社名などの固有名詞にラテンアルファベットが多用されるようになっている。これらはカタカナ表記できないので、出版物にも必然的にラテンアルファベットが増える。縦組みにおいてラテンアルファベットを和字扱いするか欧字扱いするかは、新聞のようにすべて和字扱いする方式から全部を欧字扱いすることまで幅広く明確な基準がない。

アラビア数字は、漢数字に変更する方式から、すべて和字扱いで正立する方式まである。

このように、本文テキスト中のラテンラテンアルファベットとアラビア数字の扱い方はさまざまであり、混乱状態にあると言っても過言ではない。

全体としては伝統的方式から現代的方式への移行過程にあるだろう。そうすると縦組みは移行期的混乱の中にあると言って良い。この混沌状態の結果として新たな縦組み方式が定着するのか、それとも縦組みの複雑さに見切りをつけて、横組みに1本化されるのか?

こうした混沌に加えて、縦組みは横組みに比べて製作コストが高い方式となっていることにも注意が必要である。これについては別途検討する。

[1]「横書き登場」と縦書きと横書きのゆくえ

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

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