続)英数字正立論: アラビア数字と漢数字の使い分け。日本語には正書法はない?

2012年に英数字正立論という考え方を提案してデータをいろいろ検討しました[1]。今年は、時間を作って、もう一度これを見直してまとめてみようと思っています。これは、縦組のときに主にアラビア数字とラテンアルファベットの方向の既定値(何も指定しないときの方向)をどうすべきか、ということですが、関連する問題として、アラビア数字と漢数字の使い分けがあります。

いま、CAS-UBでECMJ流!Eコマースを勝ち抜く原理原則シリーズを編集しているのですが[2]、アラビア数字と漢数字の使い分けの統一は結構やっかいです。

「ひとり」の表記使い分け・新聞方式
そんなことを考えていましたところ、Facebookで「毎日新聞・校閲グループ」の発信[3]の紹介をいただきました[4]。ここで紹介されているのは、「ひとり」のときの「1」と「一」の使い分けです。これは組み合わせとしては次のパターンがあります。

1人
一人
ひとり
1人1人
1人ひとり
一人一人
一人ひとり
ひとりひとり
----------
1人あたり
一人あたり
ひとりあたり

「毎日新聞・校閲グループ」は「他の数字に置き換えにくいものは漢字」と覚えておくといい、とのことです[5]。縦組・横組の区別を何も言及していないので共通と理解して良いのでしょうか(?)ちなみに、『記者ハンドブック第12版』(共同通信社2011年版)の数字の書き方の項(p.569~)は、暗黙に縦組を想定しているようです。成句、慣用句、他の数字に置き換えられない表現に含まれる場合に漢数字として、「一人一人」、「1人当たり」は人数を示すので洋数字という例が出ています。

例えば、1と一についてもうすこし他の例もみますと、次のような表記のパターンが考えられます。

1つ
一つ
ひとつ
1つ1つ
1つひとつ
一つ一つ
一つひとつ
ひとつひとつ

講談社方式
例えば、『日本語の正しい表記と用語の辞典 第三版』(講談社校閲局編 2015年版)では横組と縦組は分かれています。
・横組は算用数字が基本ですが、編集の意図によっては訓読みは漢字で統一しても良い(p.183)。
但し、横組で算用数字を使うときであっても「副詞的に使われるときや熟した表現では、算用数字をさける。」(横組p.178)とあり、例として一つ一つが掲載されています。
・縦組は、漢数字方式(単位語あり)、漢数字方式(単位語なし)、算用数字方式の3方式併記です。

なお、『新明解国語辞典第六版』では正書法として「一人一人」を記載しています。

新聞方式vs講談社方式比較
とりあえず、毎日新聞・共同通信、講談社で一人と1人の使用例を挙げてみました。講談社版は縦組で算用数字(アラビア数字)を使うときの例外として記載されている例です。
notation
新聞社方式は文脈依存性が強いように思います。しかし、講談社方式は算用数字を使うときでも、成語・慣用句は漢数字となっており比較的明確な基準となっています。

ECMJ!でどうするか
結局、「1人」-「一人」は機械的な統一はできないということなのですが、文章表記を統一するような自動処理(コンピュータ処理)が欲しいところです。で、簡単なのは「ひらがな」にしてしまうことです。結局、ECMJ流!Eコマースを勝ち抜く原理原則シリーズでは、ぜんぶひらがなの「ひとり」に統一することにしました。乱暴過ぎ? 

そもそも昔はすべて漢数字だったはず。それが横組の普及でアラビア数字が増えてきて、縦組にもアラビア数字が使われるようになってきたという時代の流れでしょう。そうすると、「一人一人」は漢字というのは盲腸みたいなもので、いずれは、「1人1人」が標準になるのでは? そうすると英数字正立論の出番、といったらこれも革命的過ぎ? 

正書法
もう少し調べたところ、『正書法のない日本語』(今野 真二著、岩波書店、2013年4月24日発行)という本がありました。今野さんの主張は次の通りです。

・「正書法」は、言語単位としての語を対象としている。(今野 2013年、p.1)
今野さんは、正書法というときは、正・語があることを前提条件とし、標準的表記は正書法ではないとする。そして日本語には正書法はない、というのですが、その理由は:
・文字種があり、漢字でもカタカナでもよい。
・書き方に選択肢がある。(アシ、足、脚)
・歴史的な考察。かなと漢字という表記原理が異なる文字を常に選択できる。

但し、『正書法のない日本語』はかなと漢字の表記、それも歴史的ないきさつの紹介を主としています。数字についての論考はありません。そもそも表記方法は時と共に変わるものでしょうから、『正書法のない日本語』と言いながら、歴史的な変遷を持ち出すのは本のタイトルと内容の論点がずれているように感じるのですが。

新明解の編集方針には、「正書法」とは、「漢字かな交じり文中における漢字を主体とする表記の、もっとも標準的な書き表わし方として一般に行われるもの」とあります。まあ、確かに、論理的に厳密な意味での正書法はないのかもしれません。新明解的な標準的な書き方を正書法といってはいけないんでしょうか?

[1] 2012年CAS-UBブログ一覧:2012年1月11日~2012年10月19日まで
[2] ECMJ流!Eコマースを勝ち抜く原理原則シリーズ
[3] 校閲発
[4] 仲俣 暁生さんが毎日新聞・校閲グループさんの写真をシェアしました。
[5] 20世紀の新聞は数字は原則漢数字でしたが、大新聞は2000年代(2000年前後が正しいかもしれません)に数字の表記をアラビア数字方式に変更したので新聞社でも「1」と「一」の使い分けに注意が必要になったのでしょう。例えば、使わぬ外字に歴史ありによる。

数字の表記方法は現在変化している最中と思います。正書法を確立しないと生産性を高く出来ないので困ります。あと半角全角も問題。全角という概念は廃止する方が良いと思いますし、Unicodeの基本概念には半角全角の区別はないはずなのに、なぜか、UTR#50で半角・全角の使い分けが確立しつつあります。UTR#50は仕様ではなくてレポ-トに過ぎないのですが。

『正書法のない日本語』 (そうだったんだ!日本語シリーズ)(今野 真二著、岩波書店、2013年4月24日発行)

『わかりやすい日本語の表記』(福島功夫著、創拓社、1989年5月18日発行)
『文部省学術用語集 言語学編』(日本学術振興協会、1997年)

注の配置:縦組の本の傍注 

縦組の本では、本文への注を傍注とする場合、左ページ(奇数ページ)の左側に付けるのが良いと思います[1]

ときに、下の図のように右ページ(偶数ページ)の左側に傍注を付けている本を見かけます。

IMG_20161126_070918
(『プーチンの国家戦略 岐路に立つ「強国ロシア」』(小泉 悠、東京堂出版、2016年10月)より。本書には数カ所このような傍注配置があります。)

上のような配置はあまり良い配置とはいえないと思います。

その理由としては次のことがあります。特に縦組は、見開きページの右ページから左ページへのテキストの連続性を横組よりも強く配慮する必要性があると思います。

(1)本文の間に傍注が配置されることとなり、右ページから左ページに読み進めるときの文章のつながりを分断してしまいます。
(2)視覚的には注と本文を混同する可能性は少ないと思いますが、読み上げなどでは途中に入ってしまう可能性があります。

[1] 日本語組版処理の要件(日本語版)4.2.6 縦組の傍注処理

Unicodeの漢字統合と絵文字(草稿)

1.Unicodeとは (草稿)
の続きです。

漢字の統合

漢字の共通コードを作る試みはISO/IEC 10646にもあったが、Unicodeは漢字統合の提案をISO/IEC 10646に持ち込み、中国・日本・韓国の共同作業部会(CJK-JRG)において作業が行われた。この作業の成果として1992年に最初のCJK漢字統合(Unified Repertoire and Ordering (URO))ができあがった。UROは中国・日本・韓国の地域別標準文字コード表を出典とするが、元になる文字コード表で別のコードになっていれば統合しないという出典分離規則がある。URO漢字はUnicode V1.0.1で20,902文字が規定され、その後、48文字が追加されている。また、出典文字コードとの双方向対応や出典外の主要文字として互換漢字が302文字導入された。その後、互換漢字は170文字追加されている。UROと互換漢字は(472文字)のみがBMPに収容されている。

URO以外のCJK統合漢字は第2面に追加されており、1993年10月にCJK-JRGはIRG(Ideographic Rapporteur Group)に変更され、さらに多くの出典から漢字を追加する作業が行われた。IRGが追加したCJK統合漢字ブロックとしては漢字拡張A 6,582文字(Unicode 3.0で追加)、漢字拡張 B 42,711文字(同3.1で追加)、漢字拡張 C 4,149文字(同5.0で追加)、漢字拡張 D 222文字(同6.0で追加)、漢字拡張 E 5,765文字(同8.0で追加)、互換漢字補助542文字がある。漢字拡張B以降は第2面に追加されている。

Unicode 5.1.0からコードポイントと出典を対応つけるデータベース(UAX#38)が付属仕様として提供されている。

絵文字

2009年のUnicode 5.2で、ARIB(Association of Radio Industries and Businesses)が定義する114の絵文字がBMPに追加された。さらにUnicode 6.0で608の絵文字が第1面の記号エリア(U+1D000…U+1E7FF)に追加され、主要な日本の携帯端末用の絵文字が揃った。その後、Unicode7.0までに多数の絵文字が追加され、世界中のメディアの注目を集めた。もともと様々な記号類(天気記号など)はUnicodeでいくつかのブロックに定義されているので、絵文字の登録自体は不自然ではない。しかし、絵文字に関連して人種差別にならないように肌の色調を変えるための符号(U+1F3FB…U+1F3FF)が導入された。また、マルチカラー、アニメーションなどの可視化方法、デザインなどの複雑な問題がある。こうした利用方法に関してはガイドライン(UTR#51)が作成されている。

外字(草稿)

最終版:外 字

外字は、使用頻度の少ない文字の配置場所、あるいは、その字形の表し方をいう。漢字のような図形に意味を持たせる文字では外字は常に大きな問題である。しかし、活版の時代、文字コードのサイズが小さい時代、現在のように大規模文字コードが使われる時代で外字の問題は変質している。

活版印刷の時代には漢字は活字として用意され、文撰職人が原稿を見ながら文撰用の棚に並んだなかから活字を拾った。この作業を効率化するため、印刷会社では漢字を使用頻度の多い順から、大出張、第一出張、第二出張など、外字として分類し、棚に並べるにあたりその配置を工夫していた。大出張は使用頻度の多い文字なので、中央のかなの上部で拾いやすい位置に配置し、外字は使用頻度が少ない文字なので活字を拾うのに背を伸ばしたり、かがんだりしなければならない位置に置かれた。文撰用の棚が沢山ある場合は、さらに使用頻度の少ない外字は工場の一角に別の棚を設けることもあった。

1970年代末にJIS漢字コード表が制定されたが、初期のJIS漢字コード(JIS C 6226:1978)では、第一水準漢字、第二水準漢字、非漢字を併せて6802文字が規定された。しかし、①、②などの丸付数字や、㈱、㈲を初めとして利用頻度の多い文字で規定されないものがあった。情報機器のメーカはJIS漢字コード表に規定されていない文字を独自に選定し外字として独自の文字コードを割りあてた。JIS漢字コード表は、第一バイト21~7E(94区)、第二バイト21~7E(94点)の矩形領域に文字種を割り当てるものであったが、一部の区、点は文字が割り当てられていなかった。そこで外字コードの割り当て方法としては、①JISコード表の区点範囲で文字が割り当てられていない空き領域に独自に追加文字を割り当てる方法、②JISコード表の表外の領域に追加文字を割り当てる方法(IBM拡張文字は7F区以降に割り当て)があった。

1970年代末にはワープロ専用機が登場したが、ワープロ専用機の多くはメーカーがあらかじめ空き領域に割り当てた外字(システム外字)に加えて、ユーザーが文字の字形をデザインするツールを用意し、ユーザーがデザインした外字(ユーザー外字)も使用可能とした。パソコンのMS-DOS、初期のWindowsやMacintoshも独自にシステム外字を定義した。このようにシステムで定義する外字は機種依存文字とも呼ばれ、システム間で非互換の文字が多かったため、JISコード外の文字を正しく情報交換するのが困難であった。

JIS C6226は、その後JIS X0208になり、さらにJIS X0208を包含し、1万文字を超える文字を規定するJIS X0213が制定された。そしてWindowsやMacOSでJIS X0213の文字がすべて使えるようになり、またUnicodeの普及など文字集合が大規模化することで、システム外字が必要という事態は少なくなった。しかし、現在は、新しい外字問題が生じている。

漢字の一番大きな分類は字種である。字種とは文字の意味(字義)や文字の読み(音)、正字・俗字のように歴史的経緯から見て同じ文字であるみなされる文字である。一方、一番細かい分類は目に見える文字の形である字形(デジタルフォントではグリフという)である。一つの文字に対してデザイン差までを考慮すれば字形は無数になる。これに対して、JISコード表は漢字の字体を符号化する。字体とは字形を抽象化した字の骨格であるとされている。JISコード番号には抽象的な字体が割り当てられており、そのコード番号の文字は字形(グリフ)を通じてしか可視化できない。印刷されたJISコード表に記載されているのは字形であるが、これは例示とされている。

現在、外字が使われるのは次の2つのケースがあるだろう。使用する文字コードの枠組みを、例えば、JIS X0213:2004と決めたとき、①JIS X0213:2004で規定する字体の範囲外の字体を使いたいとき、②JIS X0213:2004で規定する字体であるが、グリフが使用するフォントにない場合もしくは使いたいグリフをフォントに依存することなく指定したいときである。①は1970年代から継続する伝統的な外字問題である。

例えば、EPUB3の制作ガイドである電書協ガイドでは、「JIS X 0213:2004 の文字集合にない文字は外字画像化」するとされている。外字画像方式では外字には文字コードを使用しないで、外字を画像で表し、その画像を文字と同じ大きさで行中にインライン配置する。しかし、外字画像を利用すると、文字コードがないので検索ができなくなったり、音声読み上げができないなとの不都合が生じてしまう。

基準とする文字コードの枠組みで表せない文字は画像などで表すことになるのはやむをえない。外字画像を使わないようにするには基準とする文字コードをより大規模な文字集合にするしかない。

一方、②に属する問題は解決方法がある。市販のEPUB電子書籍にはJIS X 0213:2004 の文字集合で規定されている文字で、JIS X0213:2004に対応するフォントで使えるグリフが外字画像化されているケースもあることが、facebookなどのSNSなどで報告されている。これは制作時の環境のフォントではグリフがないところで、文字の形を優先したいという趣旨かもしれない。もし、このような問題が予想される時はフォント埋め込みが一つの解決策となる。使用したいフォントが埋め込みできない場合は当該の文字だけのフォントを制作してEPUBにフォントを埋め込むことを推奨したい。

本の形を考える―段落と段落のスタイルを考える(草稿)

段落のスタイルについて検討します。

1. 目的

段落のスタイルでは、段落全体をどのような大きさで、どのような種類の文字(フォントファミリー)で、どのように配置するかなどを指定します。段落の配置において考慮することは、段落と段落の間をどの程度空けるか、段落の先頭をどのように処理するか、段落の行の左右字上げ・字下げ、揃え(中央・左右)、段落の先頭や末尾の行が次の頁に1行あるいは1文字だけはみ出したときにどうするかなどです。

XSL-FOやCSSのようなスタイルシートの仕様では、様々な段落スタイル指定機能があります。しかし、XSL-FOやCSSは、このスタイル指定機能をどのように使いこなすべきかということは決めていません。使いこなしはあくまで指定する側に委ねられています。

CAS-UBのような本を作るためのツールでは、適切な段落スタイルを簡単に指定できるようにするのが大切です。段落スタイルは本の種類や文章の内容によって変わります。そこで何種類かのスタイルを用途に応じて簡単に選択し、切り替えできると便利です。現在のところ段落スタイルの切り替え機能は不十分ですが、今後、これを強化していく予定です。

2. 段落とは

最初に段落とはなにかを簡単にまとめます。段落に相当する英語はパラグラフ(Paragraph)ですが、この文章では段落とパラグラフを同じ意味に使います[1]

文章の区切りを大きく分けると、①章のような大きな区切り、②節のような中程度の区切り、③段落のような小さ目の区切りに分かれます。野口[2]は文章を長さで分類するとパラグラフ、短文、長文、本の4種類になると言っています(p.87)。段落は文章を構成する基本単位であり、本のテキストは段落の集合です。段落よりも小さな単位に文・センテンス(sentence)があります。段落は意味をもつ最小単位であり、文は文法的な最小単位です。

野口[2]は段落は150字程度が良いといいます(pp.89-90)。木下[3]は、原則として一つの文だけからなるパラグラフは書くべきではないとして、パラグラフの長さには制限がないが敢えていえば200字~300字といいます(pp. 72-73)。1行40字のときは行数にして数行~7,8行程度になります。一般の書籍を見ますともっと長い段落も頻繁にでてきます。一つの段落で1,000字を超えることもあります(吉川[4] pp.68-70) 。

英語の文章のパラグラフの長さについて規定は見たことがありませんが、実際の書籍を見ますとかなり長いパラグラフが普通に出てきます。パラグラフの長い英語の本を日本語に翻訳するとき、もし英語のパラグラフをそのまま日本語の段落にすると1段落がかなり長くなるはずです。実際に、日本語の翻訳本を調べてみますと段落が長くなっている傾向があるようです。

段落の長さと段落のスタイルには関係あるかもしれません。

3. 段落の区切りの可視化

段落が文章の意味的な塊であるならば、その区切りが明確になる段落スタイルを採用すると文章の意味が判りやすくなります。段落のスタイルは、段落間の空きと段落の先頭処理によって規定できます。次に段落の区切りを判りやすくするためのスタイルを検討します。

3.1 改行で段落を区切ること
段落の区切りでは行を改めるのが一般的です。では行を改めれば段落の区切りかというとそうではなく、改行していても段落の区切りでないことがあります。次のような例があります。

(1) 用紙に印刷する場合、段落内で文字を配置していくとき、基本版面(テキスト印刷領域)の幅の終わりで改行します。このような自然改行は段落の終わりではありません。自然改行と段落の終わりが一致した場合、改行だけでは段落の区切りが分りません。
(2) 行を配置していくとき、段落の途中で基本版面の一番下の行の終わりに至ったとき、改行と改頁が同時に行われます。
(3) 段落の中にブロック数式などを置いたときは、ブロック数式の後で改行しますが、次の行は段落の続きになります。
20150405a
図1 野口悠紀雄『金融緩和で日本は破綻する』ダイヤモンド社 2013年発行 p.35

3.2 段落間の空き

改行のみでは段落を可視化するには不十分です。このため段落を可視化するには、①段落間の空きを段落内の行間よりも広くするか、②段落と段落の間の行間と段落内の行間を同じとし、3.3の段落の先頭処理と組み合わせた段落スタイルを使います。

英語の本では段落間の空きを広く取ることで段落の区切りを明確にするスタイルもよく見かけます。

20150405b
図2 Eliot Kimber “DITA for Practitioners” XML Press 2012

段落間の空きを通常の行間より広くするとき、その空き量をどの程度にするかは段落スタイルの選択となります。

Webページや電子メールのように画面に表示する文章は段落間を空けるスタイルが一般的です。しかし、印刷物の通常段落ではあまり推奨されていません[5]。印刷物ではページの区切りがあるため(3.1の(2)のようなケース)で段落の区切りか、段落内のページの区切りかを視覚的に区別しにくくなるからとのことです。

3.3 段落の先頭処理
日本語の文章では段落の終わりで改行した上で、次の段落の先頭を1文字下げるのが一般的です。

英語の文章では先頭の段落は字下げせず、次の段落以降を字下げすることが多いようです。
20150405c
図3 “The Chicago Manual of Style, 15th edition”

但し、日本語同様にすべての段落を字下げしている書籍もあります。字下げのことをインデント(indent)、段落の字下げを paragraph indentionまたはparagraph indentationといいますが、Paragraph Indentionのことは『Chicago Manual』15版には出てきません。Googleで検索してみますと、14版では記述があり、15版で削除されたとあります[6]

英語の文章の場合、ドロップキャップ(Drop Cap)という、先頭文字を大きく・飾り文字とすることで段落の区切りを明確にする方法があります。
20150405d
図4 Smithsonian Books “Nationnal Air and Space Museum, Third Edition” 2009

ドロップキャップはすべての段落の先頭ではなく、最初の段落の先頭文字に対する処理です。日本語でもそのような本を見かけますが、あまり読みやすいとは言えません。ドロップキャップは装飾の一種でしょう。

3.3 課題

(1) 本の中には2.段落で定義したような段落だけではなく、引用文、箇条書き、注釈のようないろいろな種類の文章がでてきます。このようなときスタイルの定義をどうすると良いか?
(2) 3.3により、特に英語の文章の場合、最初の段落とはどのような段落かを定義することが大事になります。

[1] 段落―Paragraphの長さは日本語と英語でかなり違うことがあるようです。もしかするとParagraphは野口・木下のいうことと違う場合があるのかもしれません。しかし、ここでは文章の書き方を検討するわけではありませんので、段落とParagraphの意味関係には深く立ち入りません。
[2] 野口悠紀雄『「超」文章法』中公新書 2010年
[3] 木下是雄『理科系の作文技術』中公新書 2011年
[4] 吉川浩満『理不尽な進化』朝日出版社 2014年
[5] The Chicago Manual of Style Online. “Manuscript Preparation” Web http://www.chicagomanualofstyle.org/qanda/data/faq/topics/ManuscriptPreparation/faq0065.html 2015年4月5日
[6] ask.metafilter.com. “No indentation of initial paragraphs?” May 18, 2005. Web. http://ask.metafilter.com/18872/No-indentation-of-initial-paragraphs 2015年4月5日

多言語EPUBの作成において考慮すべき技術要件

先日に引き続き、EPUB3で多言語混在の文書を作るために、考慮にいれるべきことを整理してみます[1]

第一:言語の指定

EPUBファイルでは、日本語、英語、中国語というような言語の中でパッケージのデフォルトとなる言語を指定します。これはパッケージのメタデータに言語を指定するdc:languageという要素があり、そこに指定します[2]。このほか、メタデータの要素によっては言語を指定できるようになっています。

本文中で複数の言語を混在させるときには、コンテンツの各ファイル、またはその一部の要素やテキストの範囲に対して言語を指定します。

EPUB3のコンテンツの表現(XHTML5)では、任意の要素にlangまたはxml:langで言語を指定できます。xml:langはHTML形式とXHTML形式に移行しやすくするためのものなので、必ずlangが同時に指定されていなければなりません[3]。XHTMLをサポートしていないXML処理系で使うことを想定するのでなければ、XHTMLとして使うときでもlang属性のみを指定すれば良いことになります。

さらに、言語だけではなくてスクリプトを指定しなければならない場合があります。例えば、日本語文章で良く使われる外来語は、カタカナで表すこともラテン文字で表すこともできます。もっと、極端な例を挙げますと、ウイグル語のように、政治的な理由で、アラビア文字、キリル文字、ラテン文字、アラビア文字による表記強制を変遷している言語もあります。このように言語が同じでもスクリプトが変わることがあるわけです。但し、Unicodeでは文字コードからスクリプトを推定できることが多く、明示的に指定しなくてもあまり問題にはなりません。

第二:ページを読み進める順序

多言語文書では、ページを読み進める方向、ページの中で文字を書き進める方向を指定したいことがあります。日本語では同じ文書を、横書きでも縦書きでも表記できます。

EPUBでは、ページを読み進める順序は、spineの中のpage-progression-direction属性で全体のデフォルト値を指定します[4]。横書き、縦書きといった、文字を読み進める方向は、ファイルごとにwitiring-modeで指定できます。ページ単位で読む進める方向を変更できます。つまり縦組みの書籍(右開き)を指定しておき、一部のページを横組に指定できます。

日本語の縦書き書籍では、本文は縦組み、参考文献や索引は横書きというような例が頻繁に発生します。一冊の書籍に異なる読み進め方向を指定することはファイル単位ではできますが、現在のEPUBの仕様では、縦組みの書籍の中で後付け(たとえば、参考文献と索引)を複数のファイルで表現し、その後付け全体を左開きにするような指定はできません。

同じような理由で、英語(左開き)とアラビア語(右開き)を一つのパッケージにすることは現在のEPUB3仕様ではできません。

第三:文章中の多言語テキストの表示(表記)

第三は、文章の中で多言語の記述が存在していたときに、それをうまく表示できるかどうか、ということが問題になります。EPUBではコンテンツをUnicodeの文字列で表します。その文字列をEPUBリーダーが正しく表示できるかどうかということです。日本語や中国語のように、原則として正方形の文字を並べるだけの表記をするときは、Unicodeのコードポイントから文字の形を表示すれば良いので処理は簡単です。但し、縦書きでは句読点など一部の文字の形を入れ替える必要があります。

しかし、アラビア文字、インドの文字、東南アジアの文字は、Unicodeのコードポイントから文字の形にするだけでは足りません。アラビア文字、インドの文字は複雑なリガチャ処理が必要です。また、東南アジアの文字は文字コードの並びから音節を組み立てる処理が必要です。このような言語はEPUBリーダーがスクリプトを処理する機能を備えていないと正しく表示できません。

Unicodeの漢字は、日本語、中国語(簡体字)、中国語(繁体字)、韓国語で同じ字体の漢字を一つのUnicodeのコードポイントに割り当てているため、Unicodeのコードポイントだけでは言語を決めることができません。漢字の中には、日本語、中国語(簡体字)、中国語(繁体字)で同じ字体であっても、字形が微妙に異なるものがあります[5]

現在のEPUBリーダーの多くは、多言語を表示できるフォントを内蔵しています。しかし、日本語のフォントで中国語の漢字を表示したりすると、現地のユーザーが違和感を感じる結果になります。そこで、特にCJKが混在するときは言語またはそれに代わるタグ・属性の指定が必須となります。

実用的な多言語のEPUBを作成するには、このようなことを考慮してEPUB3を作るにはどうすると良いか、また、そうして作ったEPUBファイルをEPUBリーダーがうまく表示できるかを調べてみなければなりません。

[1] この記事は、10/25:CAS-UB:多言語機能に魂を入れるため、ドキュメントの多言語化と、EPUBの多言語化を考える、10/29:Noto Sans CJK, Source Han SansフォントとAH FormatterによるPDF生成の続きです。
[2] The DCMES language Element
[3] 3.2.5.3 The lang and xml:lang attributes
xml:lang属性はXMLの仕様で定義された汎用属性。lang属性はHTML/XHTML仕様で導入されている属性です。
[4] 3.4.12 The spine Element
[5] 字体とは字の形の抽象的な概念。字形は具体的な字の形。字形はグリフとも言う。

CAS-UBのCSSテーマ、テーマの調整およびテーマのカスタマイズについて

『CSSスタイルシートのカスタマイズガイドV2』を改訂して、CAS-UB サポート&ガイドより公開しました。次のリンクからも直接ダウンロードしていただくことができます。

EPUB版
PDF版

CAS-UBによる電子書籍の制作では、原則としてコンテンツとレイアウトを分離しています。編集時はできるだけコンテンツのみを扱い、編集が終わったらEPUBやPDFを生成する際にレイアウトを設定します。EPUBは生成ではレイアウトをCSSで指定しますが、CSSの指定は次のような仕組みです。

(1)テーマを選定する
(2)必要に応じて、CAS-UBのメニューを使って、テーマを調整する
(3)必要に応じて、ユーザー自身がCSSを用意してテーマをカスタマイズする

以下、(1)~(3)を簡単に説明します。

(1) テーマの選定

CAS-UB V2.2では、18種類(V2テーマ9種類、旧テーマ9種類)のテーマをシステムで用意しており、EPUB生成の「一般」設定メニューの「CSSのテーマ」の項目に利用できるテーマの一覧が表示されます(次の図)。そこでお好きなテーマを選択して、設定を保存すると次のEPUB生成から有効になります。

CSSthema2
図1 テーマの一覧表示と選択

(2) テーマの調整

テーマの「調整」はV2.2で新規に追加した機能です。現在、次の5項目の調整ができます。

・段落先頭行の字下げ
・段落間の空き
・表の罫線
・段落の揃え
・見出しの文字サイズ

ここでは、段落先頭行の字下げについてのみ簡単に説明します。その他の機能を含めて、詳しくは、「CAS-UB User Guide」(10-2 CSSテーマV2と設定変更)をご参照ください。

①日本語テキストの段落表示には3通りのパターンが使われる
a. 書籍などの印刷においては、一般に段落の先頭を1文字字下げします。そして、段落と段落の行間は段落内の行間と同じにします。
b. 一方で、電子メールのようなデジタル・テキストを画面で表示するときは、段落の先頭を字下げせずに、段落と段落の間に空き行を置くのが一般的です。
c. Webページなどでは段落の先頭を1文字字下げし、かつ、段落の行間を空ける(a.とc.の両方折衷)方式も良く見かけます。

②デジタル・テキストの執筆方法
ワープロなどで、原稿を執筆するとき、そのパターンもあまり統一されていません。人によっては段落の先頭に「全角空白文字」を入力して字下げします。また、電子メールと同じように字下げしないで書く人もいます。ワープロでは、インデント機能により段落先頭を表示上1文字字下げすることができますので、テキストに「全角空白文字」を入力しなくても表示上で字下げができます。

③CAS-UBの考え方
CAS-UBでは、後者のデジタル・テキスト執筆方法を標準として採用しています。つまり、テキスト段落先頭には「全角空白文字」が入力されておらず、二つのテキストの間に空き行があったときに段落が分かれていると、想定します。(実際に、行頭に「全角空白文字」が入力されていても削除はしません。)

④CAS-UBのCSSテーマの考え方
V2.2で追加したCSSテーマ(V2テーマ)は、CSSによるインデント設定で段落先頭の字下げを行なうようになっています。また、段落間には空きを設定していません。

このため原稿のテキストの段落先頭に「全角空白文字」を入力している場合は、見かけ上行頭に2文字の字下げができてしまいます。これを避けるためには、次のようにテーマを「調整」します。この調整(設定変更)を行なうことで、CSSテーマの段落先頭1字下げ設定が無効となります。

① スタイルシート画面の「CSSの調整」をクリックします。
css-config
図2 CSSの調整メニュー

②CSSテーマの設定変更メニューが表示されます。
css-config-menu
図3 テーマの設定変更

③字下げを「なし」に変更して、「保存」ボタンを押します。

(3)CSSテーマのカスタマイズ

XHTMLやCSSの基本的な知識をお持ちのユーザーは、自分自身で、CSSスタイルシートを作成して、これをEPUBに反映することもできます。CAS-UBでは、XHTMLの要素や属性をかなり自由に入力できますが、『CSSスタイルシートのカスタマイズガイドV2』にまとめて説明しています。

★特定のユーザー専用テーマを開発またはテーマを専用にカスタマイズして、そのユーザー専用メニューの作成もできます。詳細は、営業担当(cas-info@antenna.co.jp)までお問合せください。

12月18日JEPAセミナー「電子書籍実務者は見た!」。泥臭い話の中から見える今後の方向

昨日のJEPAセミナー「電子書籍実務者は見た!」[1]は、電子書籍2.0を目指すために、現状を把握するという趣旨で捕らえると、大変に示唆に富む話が多くありました。やはり、現場をよく見て、問題点を把握し、その問題に応じて解決策を考えるということが重要です。ブログで、問題点や解決策までは踏み込むことは無理なのですが、とりあえず、セミナーの内容で感じたことをかいつまんでメモしておきます。

1.電子化

林氏の話。紙の出版のプロセスの中でデジタル化されている部分とデジタル化されていない部分が混在しています。その上に電子書籍のプロセスを載せると紙にくっつけた電子のプロセスになります。そうするとコストが2重にかかる部分が多く、却って生産性が落ちる部分があります。特に、校正の問題が大きいようです。

2.プリントファーストな組織

梅屋氏(SBクリエイティブ)は、年間480タイトル(月40タイトル)を電子版でリリースしているとのことです。SBクリエイティブの全体の組織の中での位置づけは、紙の本を電子化する担当です。底本とDTPデータが入力で、出力は、配信を受け持っているわけです。そうしますと、梅屋氏の立場では、入力と出力の間を効率化するかということが役割になっています。

3.クオリティの維持

梅屋氏は「単なる流し込みではクオリティが下がる。底本を参考にしつつ、できないことは省略して底本を再現したい。」と述べます。つまり紙と電子ではかなりクオリティの要求水準が異なるということです。

このほか、テキスト・リフローでは文字を追っていかないとクオリティが維持できず、複数の端末で確認することが大きな負担のようです。特に、テキスト・リフローのEPUBリーダーの表現力が不足しているとのことです。

4.ツールの使い方で解決する?

田嶋氏の話は、InDesignのDTPデータから電書を作るときに発生しやすい問題のことでした。

いろいろな具体例がありましたが、『InDesignでは印刷した誌面では見分けがつかないが、データの作り方には様々なバリエーションがあり、EPUBを作ろうとすると最後は眼で見て判断するしかない。InDesignはなんでも許す形で発展してきているので、いまから簡単に方向転換はできないだろう。』という趣旨の発言がありました。

そこで、これはInDesignで作業を始めるときに電子化をにらんで、予め注意しておくべきこととなるでしょう。印刷会社の中で閉じている場合は良いが、出来上がってしまったもの、誰が作ったのかわからないものを、広い範囲から受け入れる場合は難しいということになります。

5.EPUBのチェック

大江氏の話は、緊デジでリフロー型の電子書籍の受け入れチェックの話でした。

メタ情報の不整合があることが多いということが印象に残りました。

あとは、文字の範囲のチェックを行なって結果を可視化するのは面白いです。

単純作業に属するチェックを人間の手で行なうのはなく、チェックをワンストップで行なう機能をシステムに組み込むのは意味があります。

6.産業出版との相違点

安井氏の報告は、比較的小規模な産業出版での話しです。大規模な産業出版では、手作業では効率が悪すぎるということでDITAのような仕組みを使う方向で進んでいます。

産業出版と書籍出版との相違点は、産業出版は組織として推進し、権利が組織に帰属するのにたいして、書籍出版では個人の著者・編集者が主役となることでしょう。

ところで、安井氏のプレゼンで冒頭に、CAS-UBブログで紹介した画像[2]が投影されたのはちょっとびっくりしました。ブログの趣旨とは少々異なっていますが、これに関してFacebookでのコメント[3]がありましたので紹介します。

本セミナーは、プロ向けソリューションを提供するベンダーの立場としても大変参考になりました。最後に講師の皆様にお礼を申し上げます。

続編:紙と電子書籍の同時発売の実現への課題(メモ)

[1] http://www.epubcafe.jp/egls/epubseminar34
[2] 縦組みにおける章・節・項番号、図表番号、箇条書き番号の付け方について珍しい例
[3] 山本さんの感想ポスト (閲読者限定)
[3] 鎌田 幸雄さんの感想ポスト (閲読者限定)

デジタル出版物の制作方法 特にコンテンツの入力・編集の方法について

デジタル出版物(EPUB、PDF)をワンソースマルチユースで制作するワークフローについて考えて見ます。

先日Facebookで(https://www.facebook.com/kotaro.soryu/posts/580833075321422)で大変参考になる議論がありました。次に、Facebookの意見を参考にしながらもう少し考えてみました。

「ワンソースマルチユースの進化が遅い」(高木さん)というコメントがありました。確かに、そのとおりと思います。ワークフローを実際に動かすには関係者の学習が必要であり、また、システム化するとシステム構築のコストがかかるため、なかなか簡単には切り替えることができません。WYSIWYGがかなり急速に普及したのと比べると、ワンソースマルチユースの進化が遅いのは、システムコストの側面と、利用者の慣れ・学習の側面があるように思います。

「学習コストは別としてTeXはやっぱりシステム自体は完成されている」(山本さん)というコメントがありましたが、確かにTeXは、スタイルセットがいろいろ用意されているなど完成度の高い仕組みができています。

ワンソースマルチユースのワークフローでは、コンテンツとレイアウトの関係を再定義する必要があります。そこで上流から下流を、①ソースコンテンツの制作、②中間コンテンツの編集、③配布コンテンツの生成に分けてみると良いのではないかと考えています。

①ソースコンテンツとは、伝えたい言語内容を表現する文字(テキスト)、画像、数式、場合によっては動画などの表現したい内容の素材です。
②中間コンテンツとは、ソースコンテンツを配布形式にする過程で、ソースコンテンツを統合して作業する対象です。InDesignを使う場合は、InDesignのファイル形式であり、HTMLでオーサリングするのであればHTML形式が中間コンテンツとなります。XML形式のこともあります。中間コンテンツは、オーサリングの対象となりますので、オーサリングの仕組みと対で考える必要があります。
③配布コンテンツとは、デジタルコンテンツの配布形式です。現在では、PDF, EPUB, Web, などが主流です。配布コンテンツはPDFのようにレイアウト処理済みの形式と、WebやEPUBのようにレイアウト処理を、可視化時に行なうものがあります。いづれにしてもレイアウト指定が重要なポイントとなります。

ワークフローを考える第一のポイントは、ソースコンテンツから中間コンテンツを作る方法です。第二のポイントは、中間コンテンツから配布コンテンツへの変換の方法です。

TeXは大変に優れたシステムですが欠点もあります。第一に、ソースコンテンツにTeXの命令を埋め込みます。そこで、制作者がTeXの命令の使い方を学習する必要があります。つまり学習コストが大きいのです。第二に、TeXは紙への印刷やPDFの生成ではシステムとして完成しています。しかし、Webコンテンツに変換しようとすると、留意しないといけない側面もあります。つまり、TeXの命令は、ドキュメント処理用の命令、文字の表現、数式の記述の命令、システムやユーザーのマクロ命令など、役割の異なる命令が不可分に混在しています。また、TeXが開発されたのは、8ビットCPUの時代です。このためTeXは、現在ならUnicodeで表すことのできる文字をコマンドを使って表すなど少々時代遅れです。また、数式の中にテキストの記述が混在しています。MathMLでは、数式の中にテキストの配置を記述することができないため、数式をMathMLのようなマークアップに変換するのは極めて困難です。TeXドキュメントの中にユーザーの作ったマクロ命令が入っていたら汎用のコンバータではWeb形式に変換できないでしょう。

最近、人気をあつめているマークダウンは、ソースコンテンツに簡単なテキスト記法でマークをつけて、それをマークダウン処理ソフトで、中間コンテンツであるHTMLに変換する方法です。マークダウンの長所は、テキストのソースを簡単に記述できることですが、欠点はコンテンツの形式が極シンプルなものなら良いのですが、少し複雑なものは非常に難しくなります。マークダウンを採用して、今年、人気をあつめたサービスに「でんでんコンバータ」[1]があります。この記法の説明を読むと、HTMLで頻繁に使うクラス属性やID属性をつけるのが難しいことがわかります。「でんでんコンバータ」は簡単なEPUBを作るには良いですが、PDFは作れません。

CAS-UBは、Wiki記法を拡張したCAS記法を使ってソースコンテンツにマークアップします。CAS記法では、クラス属性やID属性などを簡単に付けることができるようにしています。CAS記法の方がマークダウンよりは考え方としては進化しています。CAS-UBでは、生成処理でEPUBとPDFを両方とも作れます。

CAS記法にしても、マークダウンにしても、独自の記法を覚えなければなりません。この記法によるマークアップは、プログラム作成と比較するととても簡単ですし、HTMLを直接記述するのと比べてもかなり楽です。従って、IT系では受け入れられやすいようです。しかし、どうも、一般の著者・編集者・制作者には敷居が高いようです。

結論として、一般の著者・編集・制作者にとってもっとも敷居の低い方法は、WordなどのWYSIWYGのワープロで原稿を用意して、そこから自動的に中間コンテンツに変換する方法のようです。しかし、Wordはもともと紙に印刷する想定でレイアウトを指定します。そして、一般のユーザーはレイアウトを優先して編集することに慣れています。ところが、レイアウト優先の文書は中間コンテンツにうまく変換できません[2]。うまく変換するには、Wordのスタイルを使って構造を統制した文書を作らねばなりません。CAS-UBによるワンソースマルチユースを普及させるために、今後は、Wordによるスタイル編集の普及・啓蒙活動に取り組みたいと考えています。

現在、配布コンテンツの形式が紙のみからEPUBやWebまで多様化していることから、ワンソースマルチユースの重要度が高まっています。ワンソースマルチユースでは中間コンテンツからマルチ配布形式を生成するため、中間コンテンツはレイアウトを分離しておき、生成時にレイアウト指定処理を行なうのが良いと考えます。このメリットを生かすにはレイアウト指定をパターン化・テーマ化し、そのテーマを増やすことが課題です。

[1] 電書ちゃんのでんでんコンバーター – でんでんコンバーター
[2] 『マニュアルEPUB化ハンドブック2014年版  EPUBマニュアル研究会報告書』(第3章参照)

『DITA CCMS調査レポート2013』BOD(Book on Demand)版ができました。

先週『DITA CCMS調査レポート2013』を発売しました。本レポートはCAS-UBで制作し、EPUB(Kindle mobi)形式の電子書籍版とBook on Demandによる製本版を作成しています。

cover01
図1 表紙

このところ、EPUB3の登場で、電子書籍が盛り上がっていますが、製本版とEPUB版の両方を比較してみますと、やはり紙版も捨てがたい魅力があります。

紙版の判型はB5ですが、B5に10ポイントの文字で印刷しますとゆったりとして読みやすく感じます。

contents01
図2 本文(第2章の先頭)

表は本文よりも文字サイズを小さくするほうが良いかもしれません。

contents02
図3 本文(表)

EPUB版にも索引はありますが、索引は少し小さめな文字で2段組にすると引きやすくなります(EPUBリーダーで2段組を表示できるものはまだないだろうと思います)。CAS-UBでは、階層化した索引:図4ではCCMSなど、2重(親子関係を逆転)の索引:図4ではBOM―製品データ、製品データ―BOMなど、も作ることができます。

index01
図4 索引

『DITA CMS調査報告2013』の詳細ご案内