縦組みにおける章・節・項番号、図表番号、箇条書き番号の付け方について珍しい例

縦組みで、章・節・項番号、図表番号、箇条書き番号などに、アラビア数字とラテンアルファベット(英数字)を使う時、章・節・項番号の区切り文字に何を使うかは悩ましい。

中点・半角中点を使うのが無難だが、全角(em)ダッシュ・半角(en)ダッシュを使う時も多い。章・節・項などの番号が漢字なら良いのだが、アラビア数字を使うと、アラビア数字の形と区切り文字の位置・形の関係でなんとなくバランスが悪く感じる。

番号付箇条書きで番号の後ろに区切り文字を付けるときはさらに悩ましい、と日ごろ思っていた。ところが、昨日次のような使い方を見つけた。

次の写真は『新版 大学生のためのレポート・論文術』(小笠原 喜康、講談社現代新書、2009年11月20日発行)の目次である。

201309171
図1 目次

縦組みの本で章・節・項番号をこのような区切り方をしている本は珍しい。

本書を読むと、章・節・項の区切り方について次のような説明がある。

20130917a
図2 章・節・項の番号の表記法(本文p.164)

本書の内容は「以下、すべてA4・横書きを前提に進める」(p.17)としており、横書きの論文の書き方に関するものである。上の図は横書き論文における章・節・項番号の付け方の説明を縦組みで行なっているわけだ。

そして、本書は横書きで書いた原稿を、忠実に縦組みにしているようだ。つまり、次の図の右のようにWordで書いた原稿を縦組みするために、アラビア数字とピリオドを全角形に変換してそのまま組版したのだろう。

201309172
図3 半角系から全角形への変換

著者は(横書きでは)「アルファベットや数字は、すべて半角にする」(p.26)としている。図2の説明は、もともと横書きで半角形で書かれた説明だろう。しかし、本書は、本文縦組みで説明するために、文字を全角形として表しているのである。「アルファベットや数字は、すべて半角とする」という規則と矛盾しているとも言える。

全角ピリオドを区切り文字に使うのは、原稿に忠実ではある。しかし、一方で、縦組みと横組みでは一部の文字の字形を変えるという組版の規則もある。本書でも縦書きアラビア数字中の小数点は中点であらわしている。

このほか、本書では、番号付き箇条書きの箇条番号(ラベル)をアラビア数字やラテンアルファベットの小文字を使っている箇所があるが、ラベルを同じように全角形にして、全角ピリオドを付加している。ラベルを漢字にすると多少見栄えが良いが、ラベルに全角形のアラビア数字やアルファベットを使って全角ピリオドを付けるとあまり体裁が良いとは感じない。これは慣れの問題かもしれないが。

本書の内容は横書きの論文に関するものであり、内容的にアルファベットやアラビア数字が多い。さらに記号類が頻発する。原稿も恐らく横書きで書かれている。書籍にするときに、かなり無理して縦組みにしているようだ。そのために書記方法が不統一になっている箇所も多々見受けられる。こういう体裁のあまり良くない本が学生さんの間で一般化するとあまり嬉しくない。

本書に限らず、学生向けの論文の書き方の本は多数ある。その多くは、内容からは横書きがふさわしいのに縦書きになっている。『理科系の作文技術』という有名な本は横書きになっているし、横書きでは売れないということもないだろう。無理に縦組みにするのはそろそろやめたらどうかと思うのだが。

昨日のセミナー、盛況でした。多数のご参加をいただきありがとうございました。

昨日は曙橋でエクスイズム主催の「売れる本の書き方を教えます ~電子書籍 “プロの書き方読ませ方” 教えます~」セミナーに参加しました。

20130611

2011年~2012年の前半あたりまでは、電子書籍をどのように作るかがテーマでした。2012年後半に楽天KoboやアマゾンKindle Storeが開店して実際のビジネスが始まった今、セミナーに参加にされる方の関心も電子書籍をどう書くかとか、どのように売るかに変わってきているようです。

今日のセミナーにご参加された方の中でKindle Storeを実際に利用したことがある人が6割位を占めていましたし、電子書籍はブームから、電子書籍を自分で実際に作ってみよう、自社で取り組んでみようという段階になってきているようです。

電子書籍とKDPによる販売の仕組みのおかげで、簡単にだれでも本をだすことができるようになりました。ブログ感覚で本がだせるようになったわけです。メインゲストの舛本 哲郎さんのテーマは「2013年、売れる電子書籍 書き方、読ませ方を考えよう!」ですが、まさに、いまの流れに沿っているものと思います。

舛本さんのお話から、CAS-UBにはもう少しいろいろと工夫しなければいけないと反省する点もあり有意義でした。

一方で、私のほうは、KindleとPODによる本の制作を中心にさせていただきました。CAS-UBは制作サービスに特化していて、書き方、売り方というお話にもっていきにくい面もありますが、今後はもう一工夫が必要です。

『PDFインフラストラクチャ解説』を0.32版に改訂。PDF/Aの解説を改訂し、PDF/Aの作り方の節を追加しました。

6月2日『PDFインフラストラクチャ解説』を0.32版に改訂しました。

平成25年4月1日より、学位規則(昭和28年文部省令第9号)が新しくなり、国会図書館で収集する博士論文の電子データの形式がPDF/A推奨となります。

◎国会図書館
国内博士論文の収集について3. 博士論文の電子データの形式を参照

これにあわせて『PDFインフラストラクチャ解説』でもPDF/Aの仕様解説を詳しくするとともに、PDFの作り方の解説の項を追加しました。

■『PDFインフラストラクチャ解説』はCAS-UBで編集し、EPUB3版とPDF版を作成して、無料で配布しています。

資料はこちらからダウンロードしていただくことができます。2016年1月本書を正式発売しましたので、無償配布を終了いたしました。詳細は、下の【広告】をご参照ください。

◎CAS電子出版の紹介
無償配布している出版物

■第0.32版の改訂内容

0.32版では、次の改訂を行ないました。

(1) 0.31版「第24章PDFの国際標準」の章を「第2章PDFの国際標準」に移動する。

(2) 「2.5 PDF/UA(ISO 14289)」(PDFのアクセシビリティ)の節を追加。

(3) PDF/X関連の節を、「第17章 印刷ワークフローにおけるPDF」の章17.2~17.7に移動。

(4) PDF/A関連の節を、「第22章 PDFの長期保存」の22.1~22.4に移動。

(5) 「22.2 PDF/A-1」 に関する説明を改訂してより詳しくした。

(6) 「22.5 PDF/Aの作り方」の節を追加

『PDFインフラストラクチャ解説』を0.30版に改訂。「PDF長期署名(PAdES)」の節を追加しました。

『PDFインフラストラクチャ解説』を0.30版に改訂しました。

こちらから無償配布しています:CAS-UB出版物紹介の「PDFインフラストラクチャー解説(仮)」

【追記:2016/1/21】
2016年1月に本書発売となり、無償配布を終了させていただきました。(『PDFインフラストラクチャ解説』POD版とKDP版が揃い踏みとなりました
【追記:ここまで】

1.内容の追加

第21章PDFの長期保存:21.1 PDF長期署名の節を有限会社ラング・エッジの宮地社長に執筆していただきました。

2.参考資料の形式を変更

(1) 参考資料の一覧形式を変更しました。「MLA Handbook」第7版[1]をベースとする独自方式で整理しています。

(2) また、本文から参考資料へのリンクも変更しました。従来、本文中から参考資料(Web)へ直接リンクしていましたが、これを廃止して、本文から参考資料へリンクしています。参考資料からWebへ必要に応じてリンクを設定しています。

3.PDF生成のレイアウトを変更しました(途中)。

・基本版面を変更するとともに、見出しのレイアウトを変更しました。
・CAS-UBのPDF生成詳細設定の見出しのデフォルト・レイアウトを変更。PDFはデフォルト・レイアウトで生成しています。[2]

[1] “MLA Handbook for Writers of Research Papers. Seventh Edition.” New York: Modern Language Association. 2009
[2] 『PDFインフラストラクチャ解説』はCAS-UBできちんとした本(PDF、EPUB)を作るための実証材料としても利用しています。3月にBODで本を作りました(『PDFインフラストラクチャ解説』をプリントオンデマンドで本にしてみました)が、この本の組版レイアウトを専門家に評価していただき、その評価を反映して、基本版面やPDF生成の詳細設定のデフォルトを変更しています。これはまだ途中段階です。

書籍の未来そして「CAS-UB」の狙い

3月1日の第22回JEPA EPUBセミナーでの講演要旨[1],[2]
アンテナハウス株式会社 代表取締役 小林 徳滋

■はじめに

 電子書籍元年といわれた2010年以降、EPUBに注目が集まるようになってきました。当社も、この分野で何かサービスが提供できないかと思い、「CAS-UB」というEPUB変換サービスを開始しました。

 以下、書籍の未来について、またCAS-UBの開発の狙いについて、お話したいと思います。

■書籍点数の予測

 プロの書いた紙の書籍の年間発行点数は、戦後、2万点からピークには7万7千点まで増えてきました。現在、7万4千点くらいですので、踊り場を迎えているのかもしれません。
 書店に行くと、新書や文庫本がたくさんあって、点数は多いのですが、売上はだんだん減ってきています。

 一方、電子書籍は、今年度は一気に6万点の制作が行なわれています。2012年と2013年の発行点数は「キンデジ」効果があるでしょう。これは、「コンテンツ緊急電子化事業」のことで、書籍の電子化作業に国が補助金を出す事業です。こうした補助金があるために電子書籍はいま一気に点数が増えています。
 これが2013年の3月末で終ります。
 2014年以降、いったん点数は減って、そこからまた増えていくのではないかと思います。

 電子書籍の場合、今後、個人出版が増えていくのではないかと予想しています。いわゆるプロでない人たちが、本を書くようになるのではないかと思います。

 現在、個人の立場で電子書籍を出版している人は、まだ1000人弱の状況です[3]。しかし、これからはブログを書くように、本を書く人が増えてくるのではないでしょうか。年間10万人くらいの人が著者となって、100万タイトルを出版する…というようなことも起こりうると思います。

 プロとアマが競争する時代がやってくるかもしれません。

■電子書籍の作成手順

 こうした将来に対して、現在の書籍の作成手順はどうなっているのか、今後どうあるべきかについてお話したいと思います。

 現在、ほぼ手順が決まっています。すでにできている本を電子化するときだけでなく、いま作りつつある本についても、ほとんどが同じ手順です。

 最初にパソコンで版下を作ることになります。これは紙の本のデータを作ることでもあります。現在、版下をつくるのはDTPソフトを使うのが普通です。この版下データを元に電子書籍を作っていきます。

 まず、DTPソフトで版下データからEPUB用データを取り出します。それをEPUBの制作ツールを使って編集し直します。こうやってEPUBのデータを作るという方法が普通です。

 紙の本の場合は、著者が素材を用意して、編集者・制作者がそれを元に版下となるデータを作っていくことになります。

 しかし、このDTPで作った版下データをEPUB化するのは、かなり面倒な手順が必要です。そんなに簡単ではありません。

 現在のように、紙と電子書籍を分離させて作る二重制作が成り立つのは、電子化を進めるために、国からの補助金10億円を核とする20億円規模の「キンデジ」事業があるためです。

 今後、紙と電子書籍の二重制作は難しくなるはずです。毎年、国の補助金をお願いするわけにも行かないですから、二重制作はなくしていくしかないと思います。

 いずれ電子書籍タイトル数が、紙の書籍のタイトル数を上回るときがくるはずです。

 そのとき、現在のように紙の書籍を想定して、まずDTPで版下データを作って、それを電子化する手順では対応できなくなります。

 電子書籍先行という枠組みへの変更が求められるようになると思います。

■電子書籍も紙の書籍も自由自在に

 今後のことを考えると、電子書籍だけに対応するとか、紙だけに対応するというのでは不十分ではないかと思います。

 紙も電子も両方に対応できる、必要に応じて使い分けできるような制作方法が必要になると思います。

 CAS-UBは、そのためのサービスです。
 これは新しい仕組みですので、これから作られる新規出版物の制作を対象としています。

 このツールを、プロの編集者・制作者が関与する書籍向けに提供していこうと考えています。

 先ほど個人の著者が10万人になるのではないかと申しましたが、これら個人の方々は無料のツールを使って本にするだろうと思います。

 サービスを提供して対価をいただくには、プロが関与する書籍、あるいは専門的な内容の書籍が作成できるようにしないといけないと考えています。

 索引、参考文献、図表一覧、参照などを自由に作って、それを多用する書籍や、本文に数式や図表を含む書籍にも対応できるようにしたいと思っています。

 現在まだ、これらに対応したEPUBリーダーはできていません。しかし、もっと高度化したリーダーがでてくるはずです。

 こうした専門的な内容に対応できるサービスを提供していきたいと思っています。

■CAS-UBの主な3つの機能

 それでは、CAS-UBが目指しているのはどういうものか、この辺をお話します。

 著者が原稿を書いたり、写真、イラストを用意すること、これらはクリエイティブな仕事ですから、コンピュータで自動化するのは、たぶんできないでしょう。

 しかし、それをCAS-UBに取り込んでいただけたら、EPUBとかKindleとかPDFにするのは、コンピュータを使って自動でやってしまいますよ…ということなのです。

 CAS-UBの主な機能は3つあります。
(1) コンテンツを編集する機能
(2) データ交換の機能
(3) マルチ形式の出版物を作成する機能

 これらの機能がスムーズに使えるようになるためには、いくつか問題があります。
 まずコンテンツ編集をする場合に、一番のネックとなるのが、タグの問題です。

 コンテンツは、最終的にHTMLで表現されます。HTMLの場合、文章に付箋のようにタグをつけて、その中に属性と属性値を指定することになります。<h1 color="red">というような記号をつけていく必要があります。

 コンピュータを使って仕事をしている当社の社員などは、こうしたタグをつけることは全然苦にならないですし、大好きなのですが、そうでない人は、たいてい尻込みしてしまいます。このタグを入力するということがネックになります。

 これをどうしたらいいか、いろいろ検討してみました。この点、簡易マークアップ記法を採用したらいいのではないかと考えました。

 簡易マークアップ記法というのは、テキストにできるだけ少ないキータッチ入力でタグをつけられるようにするものです。こうした手法は、最近あちこちで見られます。このやり方はかなり普及すると思います。

 CAS-UBの場合、CAS記法というものですが、テキストに少しマークアップの記号を入力して、コンテンツを作るという手法をとっています。

 それから、構成編集メニューを用意しております。

 書籍には、表紙があり、はしがき、目次、章、あとがき、参考文献、索引というような構造があります。こうした構成を作るのが構成編集メニューです。

 構成の中で自動的に作れる項目があります。次のようなものです。
 ・目次
 ・図表目次
 ・索引
 ・注釈一覧

 これに加えて、章番号・図表番号も、自動生成できるようになっています。

 著者が作成した素材を取り込むのがデータ交換です。いまWordなどで書いた原稿を取り込むことができます。これについても、新たな開発が必要になってきました。

 Word文書を変換するときに、オートシェイプは変換しなくてもいいと思っていたのですが、ご要望がありました。オートシェイプも自動変換できるように作業を進めています。

 当社は変換一筋にやってきましたので、これはできるようにしないといけません。
 できなかったのではなくて、必要ないと思っていただけですので、変換できるようにいたします。

 それからCAS-UBには、マルチ形式の出版物を作成する機能があります。

 1つのソースから、EPUB、Kindle、PDF、Webページ、HTMLといった複数の形式の文書を作成することができます。

 これは、CAS-UBの最大の売りだと思っています。

■レイアウト

 最後にCAS-UBのレイアウトについて、お話します。

 EPUBのレイアウトについては、レディメイドのCSSスタイルシートを用意しております。
 現在、横組み7種類、縦組み2種類の中から、選択することが可能です。
 まだ縦組の数が少ないのですが、これを増やしていきたいと思っています。

 それから、ユーザーによるカスタマイズができないのですか…という質問をよくいただきますが、もちろん可能です。

 style.cssというファイルを用意していただいて、スタイルシートのところでアップロードしていただくと、最優先でカスタマイズされたレイアウトが有効になります。

 サポートのページをご覧ください。
 http://www.cas-ub.com/howto/support.html[4]

 それから書籍版下用のPDFを生成することもできます。
 縦組み・横組みに対応しております。

 高品質な組版ができるように、レイアウトの機能をさらに向上させていこうと考えています。
 自動組版エンジンのFormatterを、順次バージョンアップしていきたいと思います。

 レイアウトについては、本とPDFとEPUBの比較検討をしています。
 自分でも本を作ってみて、それを見ながら、本とPDFとEPUBを較べています。[5]

 同じ箇所をPDFとEPUBで較べて見ると、PDFの方が文字列がきれいに並んでいますので、見やすい感じがします。
 しかしタブレットで実際に読む場合、EPUBの方が文字が大きくて、読みやすいのではないかと思います。

 一方、索引を見ると、PDFの方は2段組になっているのですが、EPUBはリンクのみで、現状だとややさみしい感じがします。

 紙とPDFとEPUBと、これら三者に同じレイアウトを求める人が多数派であるかもしれません。しかし、それぞれ違うレイアウトの方が良いのではないかと思っています。

 同じPDFデータでも、電子画面上で見るのと紙で見るのとでは違った印象を受けます。
 画面のサイズによっても違ってきますし、それに伴って、余白や行間の取り方、見出しの大きさ等、それぞれに最適なものがあるように思います。

 様々な調節をすることによって、見た印象がかなり違ってきます。

 レイアウトについては、もう少し研究の余地がありそうです。
 より高品質の組版を実現したいと思っています。

 ありがとうございました。

[1]本記事は右の講演記録を元にして作成したものです。JEPA EPUBセミナーのページ
[2]パワーポイントスライド:http://www.cas-ub.com/info/handout/CAS-UB-20130301.pdf
[3]アマゾンKDPのみ。
[4]「CSS レイアウトのカスタマイズガイド」
[5] 『PDFインフラストラクチャ解説』をプリントオンデマンドで本にしてみました。http://blog.cas-ub.com/?p=4242

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にてご案内がなされる予定です。

FormatterClub開催迫るー縦組みにおける文字の方向について

10月22日のFormatter Club定例会の開催があと10日後に迫りました。FormatterClubはAH Formatterに関心をもつ方々を対象とするコアな登録制クラブなのですが、今回は無理にお願いして、一般参加とし、「縦組み時の文字の向き―その理論とマークアップ方法」というちょっと異色のテーマで報告させてもらうことになりました。

UTR#50の件については、この春から土日の大半を使って取り組んできましたが、AH Formatterの次期バージョン(V6.1)に縦組みの文字正立モードを設けてもらって、また自動縦中横機能なども利用可能な形にしたいと考えています。これによって、横組みテキストと縦組みテキストの共通化へむけて前進することができると考えています。

多くの方の、ご参加をお待ちいたします。

○FormatterClub定例会の内容

13:30~ 開会ご挨拶
13:35~ 「インドのおさつで使われているすべての文字の組版を目指す」
「MathMLによる高品質数式処理」
アンテナハウス 村上真雄
14:20~ 質疑応答
14:30~ 「縦組み時の文字の向き―その理論とマークアップ方法」 アンテナハウス 小林徳滋
15:15~ 質疑応答、休憩
15:50~ 「電子文書レイアウトの未来!AHReaderのプレビュー」 アンテナハウス 村上真雄
16:20~ 質疑応答
16:30 閉会

FormatterClubのお申し込み(コクチーズのページ)

縦組み書籍における縦中横の使い方(調査報告)

これまで縦組み書籍の英数字、記号類の方向について調べて本ブログで紹介してきました。前月末から、少し焦点を移して、主に縦中横の使い方を中心に調べています。

縦中横とは、縦組みの行幅に2文字ないし数文字を横組みで収める方式です。最も多いのはアラビア数字2桁の組み合わせです。伝統的な書籍では数字はほとんど漢数字でしたが、最近の縦組みの書籍では、数値や年号に原則として漢数字を使う場合でも、各種の番号にはアラビア数字を使うことが多いので、縦中横の頻度が非常に多くなっています。

いままでに調べた書籍は13冊で総ページ数は3000ページ強になります。中間報告として、いままでにわかったことを簡単に整理してみます。13冊の中で、数字を原則として漢数字としている書籍が9冊、原則アラビア数字が4冊です。すべての書籍が縦中横を使用しており、縦中横が出現しない本はありませんでした。

1.2桁のアラビア数字はほとんどすべて縦中横になります。但し次の例外があります。

(1)数値の小数部は1文字ずつ正立します。たとえば、1ドル=76.25円を縦組みにするとき、「76」は縦中横ですが、「25」は1文字ずつ正立です。数値の少数部が2桁の例は2冊ありましたが、いずれも、1文字ずつ正立させています。この場合、縦中横の整数部は数値の位取り表記といえます。縦中横は数値の位取り表記と解釈できるのでしょうか?なお縦組みでは、「.」は「・」になります。

(2)日付で3.11を縦組みにするとき、「11」を縦中横にしているケースが(1冊)ありました。ところが、2.26事件の26を1文字ずつ正立しているケースも(1冊)あります。おそらく11を「ジュウイチ」と読むときは縦中横、2.26を「ニイテンニイロク」と読むとき1文字ずつ正立と予想しますが、この両方とも各1冊なので、もう少しケースを増やさないとはっきりしたことは言えないでしょう。

2.本文中では、一般には3桁のアラビア数字は1文字ずつ正立です。3桁のアラビア数字を縦中横としている書籍は1冊のみです。なお、目次のページ番号は3桁のアラビア数字も常に縦中横です。

3.数字を原則漢数字としている書籍でも、アラビア数字は珍しくありません。次のような使い方があります。
・章番号、節番号とその参照
・箇条書き項目番号、文中の項目番号、およびその番号参照
・図番号、表番号の参照
・商品名、製品名などの固有名詞(艦艇名、飛行機型名など)
・フォントサイズなど(フォントサイズは漢数字の書籍も多く不統一です)
・ほかの書籍、新聞などのテキスト引用
・慣用句(A4など)
以上のケースで2桁のアラビア数字が使われる場合もすべて縦中横です。

4.括弧類や記号とアラビア数字の組み合わせ
(1)()付のアラビア数字は()を数字の上下に配置するケースが主流です。但し、()を含めて縦中横にしているケースがあります。これはU+2474(⑴)~を使っているのではないかと思います。
(2)記号とアラビア数字の2文字以上の組み合わせを縦中横にした例は少ないですが、「1′を○囲み」(合成文字)、「’04年から」(3文字)が見つかりました。

5.ラテンアルファベットは2文字が連続しても縦中横にするケースは少ないようです。
(1)大文字2文字が連続するとき、1文字ずつ正立が原則です。大文字2文字を組み合わせた縦中横は、今のところ下記の「VS」のみです。
(2)ラテンアルファベット小文字同士の組み合わせは頻度が少ないですが、次のような例があります。
・(bb) ―()は文字の上下、箇条書きの項目番号として使用。
・VS、v.s.、vs、vs. ― 「vs」は異色です。4冊の書籍で4パターンあり、うち2つは「.」と組み合わせですが、すべて縦中横になっています。
・or、if ― orの縦中横がありました。「歴史にifはない」が2つの書籍に出てきましたが、1冊は横倒し、1冊は縦中横です。
・kg、cmなどの単位-これはおそらくUnicodeに1文字で登録されている単位記号でしょう。

6.ラテンアルファベットと記号を組み合わせた縦中横はまれですが、次のようなケースがあります。
・~A(~チルダの全角形とAを組み合わせ) ― ~を否定に使用する例として
・A′(Aプライム)― このパターンは、2冊見かけました。
・i* ― 式中の項目として使用
・(a)、(b) ― これはUnicodeのU+249c~に1文字で登録されているものでしょう。そうでない場合は、()を文字の上下につけるようです。
・“a”を3文字で縦中横にしている例がありました。
・顔文字を縦中横にしている例がありました。この場合、()を含めて5文字以上になります。

7.ラテンアルファベットとアラビア数字の組み合わせは次のようになります。
(1) 一般にはラテンアルファベット1文字とアラビア数字1文字とが連続する場合1文字ずつ正立です。
・A4(用紙サイズ)、8F(フロア)、G8(主要8カ国)などは1文字ずつ正立します。
(2) G10(主要10カ国)、AKB48、BS11(放送)は、アルファベットは1文字ずつ正立ですが、数字は縦中横です。
(3) ラテンアルファベットとアラビア数字を組み合わせて縦中横にするケースは、極めてまれです。
・13冊の中でM2(通貨供給量)のみが見つかりました。

○詳細については、『FormatterClub定例会「文字組版の最先端」』で報告する予定です。

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

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

CAS-SUPPORTのブログ 9月分をEPUBにまとめました

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

ブログをまとめるには、本当は見出しの付け直し、リンクの設定、レイアウトなどをもう少しきちんと整理しなおすべきと思いますが、やり始めるときりがありません。

ということで、整理の方があまりできていませんが、とりあえず、1パッケージにしたことに意味があると考えて公開しました。

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

CAS-UBで作成したPDFとEPUBのサンプルファイル
CAS-SUPPORTのブログ9月分

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