本記事は、アーカイブに保存されている過去の記事です。最新の情報は、公益社団法人日本印刷技術協会(JAGAT)サイトをご確認ください。
1.InDesignデータからEPUBを制作する際に直面する「非互換性」について
2012年夏の楽天kobo事業開始を第一歩とし、年末のkindle日本市場参入によって完全に電子書籍市場は新しいステージを迎えた感がある。しかし、まだまだコンテンツは英語圏に比べれば多いとは言えず、紙の本の発売からかなりの時間を経た後にようやく電子書籍の発売にいたる例なども多く見られる。
もちろん、これには出版社サイドの販売戦略的な判断もあるのかもしれないが、一方で印刷データから電子書籍データへの変換に伴う技術的障壁が依然として大きな壁になっている状況も否定できない。
この問題の大きな原因のひとつは、「紙書籍」と「電子書籍」のメディア特性の違いから来る「非互換性」だ。ここでは、InDesignで制作された紙印刷用データをもとにEPUB電子書籍データを制作する過程を通じて、この問題に迫ってみたい。
1.1 象徴的な「外字」の問題
図1入る
InDesign内で使用できる字形数と電子書籍で使用できる字形数
この非互換性を象徴する大きな問題として、「外字」に関する問題が挙げられる。一般に広く知られてはいないが、現在印刷物で使用できる文字の数は、電子書籍で使用できる文字の数よりかなり多い。InDesignなどの印刷用組版ソフトの中で使用可能な文字集合規格である「Adobe-Japan 1-6」で利用出来る字形(グリフ)の数は約23,000あるのに対して、日本語対応の電子書籍デバイス内で使用できる字形(グリフ)の数は、Unicode対応のEPUB3ですら約15,000字形(デバイスが搭載するフォントに依存して端数は上下する)、シフトJISが基本のドットブックやXMDFといった形式では約7,000字形にとどまる(ドットブックでは独自フォントに依存した外字体系があったため、利用出来るグリフの数は実際にはもう少し多かった。また、XMDFは最新規格のXMDF3.0ではUnicodeに対応している)。
このため、この「InDesignデータでは文字として表示できるが、電子書籍では表示不可能な字形」は、もし印刷物をできるだけ忠実に電子書籍化することが大前提になるのであれば、全て外字画像にしなければならない。ここで言う「外字画像化」とは、PNG形式などのビットマップ画像をテキスト中にインラインで挿入することを指すのだが、外字画像そのものを制作する手間とそれに比例するコストもさることながら、InDesign文書内に含まれる膨大な文字のうち、どの文字を外字にしなければならないかを特定するのが相当の難事である。なにしろInDesignには現在、こうした字形を適切に検索し、ピックアップする機能がまともに備わっていないのだ。このあたりは結局、海外製ソフトの限界とも言えるだろう。
そうなると最終的には全文を目で追って底本と引き合わせ、外字化が必要な文字を判別することになる。これは決して小さな話ではない。
さらには、外字は何もこの「Adobe-Japan 1-6」の依存字形だけではない。各種汎用外字フォントに依存する字形や、あるいは各出版社、印刷会社が必要に応じて作った独自製作外字に至るまで、全てを外字画像化する必要がある。そしてこういった手作業での外字制作の手間は、結局のところ最終的な製作コストに響いてくるのは言うまでもない。
図2入る
合字が複数の文字に分割されて出力される例
「全てを外字画像化しない」としても、実は問題は残る。InDesignはAdobe-Japan 1-6の独自字形をUnicodeの親文字に紐づけて管理し、EPUB書き出し、XML書き出しの際には親文字のみを出力する。
この特性によって、例えば典型的なパターンとして、InDesign内で「任意の合字」の機能を用いて表現されていた「〄」マークが、テキスト化した際にアルファベット3文字の「JIS」に変化してしまうといったような「事故」が警告なしに起こる。これも結局、現状では最終的に目視で確認し、修正するしかない。こういった校正に伴うコストもまた、制作コストを簡単には引き下げられない要因となる。
1.2 「版面」と「ページ」
もうひとつ、「紙と電子の違い」を象徴する大きな要素として、「ページの概念の有無」を挙げておこう。リフロー型の電子書籍は、データとしては例えば章であれば章全体でひと繫がりの状態で構造化テキストを製作し、その構造化テキストをビューア側が解釈して適宜「ページ」を生成する。ユーザがビューアの操作で文字サイズを大きくすればページ数は増えるし、小さくすれば減る。すなわちそこにはもはや固定された「版面」の概念はない。また、紙書籍で版面を構成するために使われていた要素の多くが、電子書籍では使用できなかったり、あるいは使用することが不適切であったりする。
いくつか例を挙げてみよう。例えば紙書籍では当たり前のように使われている「画像の回り込み」は、緊デジでのEPUB3制作では「非推奨」の扱いである。これは電書協EPUB3制作ガイドの扱いに準じたものだが、いくつかのリーディングシステムで表示が乱れることがあるのがその理由として挙げられている。こうなると、紙書籍で回り込みを前提に配置された画像は、電子書籍では回り込みをしない形で行間などに配置する形を取らざるを得なくなる。これはいずれリーディングシステム側の対応状況に応じて解消されるかも知れないが、確実ではない。
図3入る
「割注」
また、使用することが不適切な例としては、専門書等でしばしば用いられる「割注」がある。本文1文字分のスペースに2文字を横並びで配置する割注は、おそらく完全に固定された紙の版面に依存する表現であり、これをそのまま電子化することは可読性の面で適切ではないだろう。
さらに、紙の書籍であればページの下部にレイアウトされていた「脚注」は、現状同じ画面の中に複数のテキストボックスを配置できないEPUB等では表現不可能だ。これについては段落末に配置する段間注の形を取るか、あるいは章末等に集中配置するか、いずれにせよもとの版面レイアウトを崩し、再構成する必要が出てくる。
EPUB3では将来的には、該当する単語をタップすると注がポップアップ表示される等の対応が想定されているが、こうなるともう完全に「電子書籍ならではの表現」である。
こういった問題が意味するものは何だろうか。これまで紙書籍の制作を担ってきた編集者や、各印刷会社、制作会社の制作者は、「紙書籍制作のプロ」であり、効率良く高品質なコンテンツを制作するノウハウを日夜磨いてきた。そしてそのノウハウの多くは、「版面」をいかに綺麗にレイアウトするかという部分が大きな比重を占めていた。
だが、そうしたノウハウは、電子書籍の制作では役に立たなかったり、あるいは考え方を根本から切り替える必要が出てくる。そうなると、むしろこれまでの考え方に引きずられない分、若くて紙書籍制作の経験の浅い編集者、制作者の方が活躍できる場面が増えてくるかも知れない。実際に緊デジ等で電子書籍を制作するにあたっても、出版社サイドの担当者の戸惑いは大いに感じられた。
結局将来的には、「電子書籍には電子書籍制作のプロ」が求められるということなのかも知れない。これは単純に製作の技術的ノウハウの問題だけではなく、SNS等を利用した電子書籍の効果的なマーケティングの仕掛け方や、そもそもの企画の立て方のコツの違いなども絡んでくるから、かなり根の深い問題である。
また、これは喫緊の問題として、「校正に際してページ数での指示が出しにくい」という点が挙げられる。これは緊デジ等の制作過程でもよく耳にした。編集サイドが要修正箇所を発見したとしても、それを制作サイドに伝えるためには「底本のページ数」に頼るしかなく、正直かなり効率が悪い。このあたりは早急に効率的な制作ワークフローの確立が求められる部分だ。
1.3 「電子から紙」でも問題は同じ
さて、ここまでは「紙書籍用データから電子書籍データへ」の変換における非互換性の問題について見てきたわけだが、おそらく電子書籍データを紙書籍用データに変換する際にも、多かれ少なかれ同様の問題が出てくるのではないかと思う。わかりやすいところで言えば、動画やJavaScript等を用いたインタラクティブな表現がそれに当たるだろう。これらは紙書籍では表現のしようがない。
また、どちらを元にするにせよ、相当に念を入れた校正が必要で、これは上述したように相当以上のコスト負担を伴う。
結局のところこうした「非互換性」の問題を解消するには、上流に共通の親データを用意し、計画的に双方のデータを生成する流れに移行するしかない。
2 使い回すコンテンツはInDesignデータで良いのか
2.1 InDesignデータからのEPUB変換の難しさ
世の中に溢れている印刷物は驚くほど多様である。その多様な印刷物を制作するためのツールとしていわゆるDTP組版アプリケーションがある。現在、その代表格と言えるのが「Adobe InDesign」である。
昨今の電子書籍化のニーズを受けて、このInDesignの印刷用データから電子書籍を制作するソリューションがちらほらと出てきている。このうち、主に複雑なレイアウトの出版物に向くPDFでの電子化はそう大きな問題はないのだが、文章中心の読み物向けの「EPUB3」への変換では、各ソリューションとも完全とは言い難い結果しか得られていない。これはInDesign純正のEPUB書き出し機能も含めての話である。
もちろん比較的簡単なコンテンツであれば、それなりに整った形でEPUB化することは可能だ。ただし、だからそれでよしとできるほど、印刷用のDTPデータは簡単な代物ではない。
InDesignは、ありとあらゆる印刷データを効率的に制作するために、積極的な機能追加・機能改訂を繰り返してきた巨大アプリケーションだ。成果物としての印刷物を見れば同じようにしか見えなくとも、元となるDTPデータの制作方法は実に多岐にわたる。そして、この多様さを許す柔軟な仕様こそが、例えば「EPUB3」などの電子書籍データへの変換を阻む。
InDesign(および、InDesign普及前にDTP制作ソフト市場で主要な地位を占めていたQuarkXpress)は、それ以前の電算写植の時代には一握りの「組版のプロ」だけが立ち入れる世界だった印刷物制作の世界に、GUI(グラフィカル・ユーザー・インターフェース)を武器として、広範な「誰でもできる化」をもたらした。印刷物制作費用の低価格化という意味でこれに大きなメリットがあったのは決して否定できない。
ただし、それに伴い、全般的な印刷物の品質低下や、あまりにも多様すぎる制作方法のバリエーションを招いてしまったことも確かだ。
実際、ほとんどワープロソフトで文章を作る程度の知識しかなくても、InDesignを用いればそれなりのドキュメントは作れてしまう。もちろんそうして制作されたドキュメントが組版のプロから見て満足のいく組版水準に達しているかどうかはまた別の話ではあるが。こうして非プロフェッショナルの手によって制作された大量の(例えば段落スタイルの設定すらされていないような)InDesignのデータは、それをEPUBといったような形に変換するにあたって、制作サイドの多大な負荷を伴う。
ではなぜ、段落スタイルを持たないようなデータのEPUB化は大変なのか。それは、「論理構造を持たない」からだ。見出し部分が見た目で太字になっていたとしても、それが見出しであるかどうかをコンピュータは識別することができない。従って、こういったデータを整理せずにEPUB化した場合、変換プログラムは個々の箇所の文字サイズや、フォント名などの要素をそのままEPUBデータ化することになる。
これは一般的に極めて冗長で、後からの一括修正が難しいデータになる。そうなると、後から修正指示が入った場合には、もとのInDesignに戻ってデータを修正し、再書き出しを行うことになるが、これは結局、「InDesignへの依存から脱却できない」ことを意味する。これを避けるためにInDesignの書き出した冗長なEPUBデータを修正するにはXHTML等の構造化文書についての知識は不可欠で、かつ長時間複雑に絡まり合ったXHTMLテキストと格闘する覚悟が必要になってくる。
こうした状況を鑑みれば、「InDesignのデータがあればすぐにでもEPUB3は作れる」という論説は到底一般化できない。「InDesignのデータをEPUB3化するには、慎重なデータ設計とシステム構築に加え、熟練オペレータの技術が必要になる」と言うのが正しいだろう。
また、プロフェッショナルによって制作されたデータであれば簡単に変換ができるのかと言えば、そう簡単な話でもない。これについては以下を参照されたい。
2.2 DTPでの制作方法のバリエーション例
DTPでの制作方法のバリエーションのわかりやすい一例として、下図のようないわゆる「ぶら下がりインデント」の作成法を上げてみよう。
項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る
項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る項目の本文入る
このようなレイアウトをInDesign内で表現するためには、少なくとも3種類のやり方が考えられる。2つは一般的に正しいとされるやり方、1つは間違いだがよく見られるやり方だ。ひとつずつ見ていってみよう。
1つめ。「段落」パレットの設定で「左/上インデント」と「1行目左/上インデント」に適切な値を入れ、ぶら下がりインデントを実現するパターン。上記のような例で本文が10Qならば、「左/上インデント」に「10Q」、「1行目左/上インデント」に「-10Q」を入力することで、上図のようなぶら下がりインデントとなる。これは適切に設定しておけば電子書籍への自動変換も可能だ。
図1入る
段落設定を利用したぶら下がりインデントの表現
2つめ。各項目の直後に特殊文字「ここまでインデント」文字を挿入し、ぶら下がりインデントを実現しているパターン。これもDTPのワークフローとしては正しい。ただし、電子書籍化では挿入された特殊文字の扱いが少々やっかいだ。少なくとも自動処理はできそうにない。
図2入る
「ここまでインデント」文字を利用したぶら下がりインデントの表現
3つめ。間違いだがよく見られるやり方。行末で改行し、行頭に全角スペース等を挿入して字下げを行っているパターン。タブ文字など全角スペース以外の文字を使った字下げの例もこれに準じる。こうしたやり方をしていると、再校以降の修正指示の際に予期せぬ事故を誘発しやすくなり、また、作業工程の途中で別のオペレータに作業を引き継いでもらうことも難しくなる。
電子書籍化に際しては、改行位置を固定できないEPUB等の電子書籍では、この方式で作られたぶら下がりインデントをそのまま放置すると不自然な位置での改行を多発させてしまい、レイアウトが大幅に崩れてしまう。ドキュメントを目視確認して改行と先頭のスペースを削除し、適切なスタイルを当て直す作業が必須となる。当然自動処理はできない。
図3入る
全角スペース字下げを利用したぶら下がりインデントの表現
2.3 100人のオペレータがいれば100通りの制作方法がある
図4入る個々のDTPデータの製作方法の違いを、電子書籍の製作時に修正
こうした制作方法のバリエーションは、もちろんぶら下がりインデントだけに存在するわけではない。ありとあらゆる表現にそれは存在し、100人のオペレータがいればほとんど100通りの制作方法があると言っても良い。これが何を意味するかと言えば、データの変換に際して毎回異なる例外処理が発生するということだ。すなわち、InDesignデータからの電子書籍化は、結局どこまでもベテランオペレータが目で確認しての手作業から逃れられない。これでは、コストダウンにも限界があるし、これから増えてくることが見込まれる紙印刷物と電子書籍の同時刊行などというニーズに応えるにも限界がある。
さらには、頻繁にアップデートされるInDesignのバージョンの違いといった問題や、使用フォントの制約もある。InDesignのデータだけ残っていても、ドキュメント内で使用されているフォントがシステムにインストールされていなければ、レイアウトの完全な再現は不可能だ。
決して安価とは言えない和文フォントを使用できる環境を長期にわたって維持し、旧バージョンのInDesignデータを制作された時点と同じ形で開ける環境を維持することは、長期的には決して小さくないコスト負担を伴う。InDesignデータの保存は、それを使用できる環境の保持とセットで初めて意味を持つのだ。
2.4 結局InDesignは「紙印刷物のためのツール」
結局のところ、InDesignは「紙印刷物を効率的に制作する」ために発展してきたツールである。これまでの印刷物の制作とはつまるところ、「最終出力物が全て」の世界であったのだから、前段に記したいずれのやり方をとったとしても、最終出力結果が同じであれば大きな問題はなかった。例え制作方法が100通りあったとしても、最終出力物が同じであればそれは「同じもの」だったのだ。
ただし、これが電子書籍への変換となると話が全く異なってくる。複雑多岐な印刷物制作方法のバリエーションは結局、データ内の個々の表現をオペレータが読み解き、手作業で判断して適宜適切なタグを当てることで解消するしかなく、それは必然的にタイムロスとコストアップを生む。
これを解消するために「電子書籍化を見込んだDTPデータ制作を」という意見があることも承知しているが、これにも正直完全には同意しかねる。段落スタイル名・文字スタイル名を社内で統一する、といった程度の施策はある程度有効とは思うが、版元の指示を受けた紙印刷物の最終的な作り込みは「その先」を考えて行えるほど甘くないし、なによりそこで下手に枷を嵌めるべきではない。制作の最終工程においてこれまで無かった制約を増やすことは、潜在的な印刷事故の原因にもなりかねないだろう。
繰り返すが、InDesignの「印刷データ制作ツール」としての高度な機能を、電子化のためにスポイルすることはあきらかに間違いである。また、1社の内部でのルール策定ならまだしも、業界全体を通じてルールを徹底させることはほとんど不可能に近いと言わざるを得ない。
紙印刷物と電子書籍は別物である。これを前提として双方のコンテンツ制作を効率良く行うには、紙印刷物と電子書籍双方の元になるデータを上流に持ち、紙印刷物、電子書籍双方を、出来る限り自動に近い形で変換出力する形を整えるしかないだろう。分岐元の親データの最有力候補は、むろんXMLになるだろう。
3 「紙書籍」と「電子書籍」のコンテンツ作りの考え方の違いについて
今、この文章を読まれている方は、その多くが書籍などの紙のコンテンツ制作に何らかの立場で携わってきた方と思う。ここでは、そうした今まで「紙のコンテンツ作り」をされてきた方に向けて、紙と電子でコンテンツ制作に対しての考え方がどういった点で変わってくるのかに関して、簡単に触れておきたい。
なお、以下の文章は基本的にはいわゆる「リフロー型」の電子書籍に関するものであり、PDFや画像をベースにした「フィックス型」の電子書籍にはあてはまらない点があることをあらかじめご承知いただきたい。
3.1 電子書籍では、制作側が表現を100%コントロールすることができない
図1入る
完成パッケージとしての紙書籍と、読者の手元で初めて完成する電子書籍の違い
紙のコンテンツ作りは、製作過程ではデジタルで行われるが、最終的には印刷されて手に取れる物理的な「モノ」となることで完結する。従って、文字の並び方、フォントの選択はもちろんのこと、印刷する紙の種類から、中綴じ/平綴じといった製本の体裁に至るまで制作側が100%コントロールすることができる。
だが、電子書籍はそうではない。コンテンツは「電子データ」として提供され、最終的には読者の手元で各種デバイスやPC上のリーダーアプリに読み込まれることで、初めて表現が完結する。そこには「製本」の概念はないし、組版、フォント、色表現に至るまで、リーディングシステムの種類やユーザーの設定によってどうとでも変化し得る。
こうした紙コンテンツと電子コンテンツの特性の相違は、以前にも紙のコンテンツをWeb展開する際などに再三再四指摘されてきたものと思うが、電子書籍でも全く同じことが指摘できる。以下、従来紙の上で行われてきた表現が電子書籍ではどう変わり、どういった点に注意が必要になってくるのか、思いつくままに列挙してみる。
3.2 表現の具体例
3.2.1 文字サイズ/行間アキ
電子書籍では基本的に文字サイズは絶対値で指定しようとするべきではない。本文サイズを絶対値で指定してしまうと、ユーザがフォントサイズを変えて読もうとしてもサイズを変えることができず、これは電子書籍の柔軟性に期待して購入したユーザからのクレームの対象になりかねないだろう。もちろん、「できればこのサイズで読んで欲しい」という制作側の希望を否定するつもりはないが、それはデフォルトの文字サイズをどのサイズにするかという範囲に留めるべきと思う。
ただもちろん、例えば見出しの文字サイズを本文の何%の大きさにするか、といった形で相対値でサイズを指定することはできるから、文字サイズによるデザインが全く出来なくなるのではないかといったような心配は無用だ。
行間アキ量指定も同様だが、行間アキに関しては、例えばAmazonのKindle Paperwhiteのように文字サイズとは別にユーザ側が独立指定できるリーディングシステムが存在するため、文字サイズ以上に厳密な制御はできないと考えておくべきだろう。
3.2.2 改行位置/禁則表現
段落末改行についてはもちろんきちんと表現できるが、そうではない個々の行の改行位置は制御できない。禁則表現に関しても、行頭に句読点が来ないといったごく基本的なレベルの禁則ルールはほぼ実現できているものの、例えばInDesignでできるような禁則ルールのカスタマイズは不可能であり、リーディングシステム側の解釈にまかせるしかない。また、現状いわゆる「ぶら下がり」表現を実現したリーディングシステムはほとんど存在しないものと思う。
そもそもデバイスの画面サイズやユーザが指定した文字サイズ次第で改行位置が変化するのがリフロー型電子書籍の最大の特徴なのだから、紙書籍制作の感覚で個々の文字のアキ量を指定し、版面を整えることには全くと言っていいほど意味がない。
3.2.3 文字の変形(長体/平体)
文字の縦方向もしくは横方向の変形、いわゆる長体や平体は電子書籍では表現できない。これに関しては将来的に実現されるかどうかもはなはだ不透明だ。おそらく世界的に見てほとんどニーズがないということだろう。実際、電子書籍には紙書籍のようにページ面積の制約はないのだから、少なくとも本文に関しては長体や平体をかけて文字を押し込む必要はないとも言える。
3.2.4 書字方向
リーディングシステムによっては、書字方向をユーザ側が任意に切り替えられるものも存在する。例えば紀伊国屋書店のストア用ビューア「kinoppy」などがそうだ。あらかじめ縦用/横用のCSSスタイルシートを準備しておき、代替スタイルシートとして指定することでユーザが縦横を任意に切り替えて表示することができる。こういったリーディングシステム向けに縦横切り替えコンテンツを制作する際には、元データに縦組みで読まれることを前提として挿入されている旧かなの繰り返し記号類や、横組みで読まれることを前提とした学術書などのピリオド/カンマの句読点など、書字方向を制約するキャラクターが含まれていないかのチェックが必要となってくる。
図2入る
kinoppyでの書字方向切り替え
3.2.5 フォントバリエーション
紙書籍では制作/印刷会社のコンピュータの中にフォントが入っていれば、最終生成物である紙に出力することが可能だ。今、多くの印刷会社では何百種類というフォントを印刷物の制作において自由に使用することができ、混植や字形組み換えといった操作も自在に行うことができる。だがこれは、最終生成物が紙であるからこそ可能となっている状況だ。
電子書籍では読者の手元のリーディングシステムにインストールされていないフォントは基本的には使えない。通常それは明朝体1種類、ゴシック体1種類程度であり、またリーディングシステム次第でフォントが変わる。例をあげると、楽天koboで本文書体に採用されているのはモリサワのリュウミンであり、紀伊国屋書店のkinoppyでは字游工房の游明朝体が採用されている。つまり、全く同一のEPUB3コンテンツであっても、koboで表示するかkinoppyで表示するかで本文書体が変わってしまう。
これを回避し、制作側の指定したフォントでコンテンツを表示させるためにはコンテンツ内にフォントを埋め込めばいいことになるが、EPUB3にはフォント埋め込みの規格自体は存在するものの、フォントメーカーとの間でフォントライセンス等の折り合いが完全に付いているとは言いがたく、現時点では日本語フォントの埋め込みは実質的に使えない。各種メタデータを含むフォントデータの流出はフォントメーカーにとって何を措いても阻止したい事態であることは容易に想像がつくから、これはそう簡単には折り合いは付きそうにない。
さらに、リーディングシステム側が埋め込みフォントの読み込みに対応していないケースもあるため、埋め込みフォントが安定して使えるようになるにはまだまだ時間がかかりそうだ。加えて、紙と違ってファイルサイズの制約があるため、全てのフォントを埋め込んだ「重い」電子書籍は将来的にも歓迎されないだろう。
また、電子書籍での和欧混植はCSSの指定によって可能だが、前述したようにリーディングシステム側が埋め込みフォントの読み込みに対応していないことがあるため、制作側が望む欧文フォントをコンテンツ内に埋め込んで混植に使えるようになるにはまだしばらく時間がかかると思われる。
3.2.6 外字/異体字表現
印刷用フォントの規格である「Adobe Japan 1」では、約23,000種類の字形を用いることができる。これに対して、電子書籍(EPUB3)で使用できる字形の数は現状約15,000種類に留まる。この約8,000字形の差により、人名漢字の異体字や3桁の組数字など一部の文字の表現に影響が出てくる。つまり、印刷物の制作時にはそのまま指定できても、電子書籍では外字画像もしくは埋め込み外字フォントとして扱わなければならない文字が出てくるのだ。
図3入る
印刷データで使用可能な文字数と、Unicodeで使用可能な文字数の差
電子書籍では現状、PNG形式の画像として外字を制作し、インラインで表示させることで外字を表現できる。ただ、PNG形式などで制作した外字画像はコンテンツ内検索に引っかからなかったり、ルビや傍線、圏点が外字画像の部分に表示できないリーディングシステムが存在するなど、現状ではさまざまな問題点がある。利便性や表現とのトレードオフになることを念頭に置き、外字画像の使用は人名など最小限度に留めておくべきと思う。
また、そもそも紙書籍での外字とは異なり、電子書籍の外字は、はっきり周囲の文字と見分けがつく状態になってしまうことも多々ある。
3.2.7 カラー表現
最終的に印刷する紙の種類、インクの量までコントロールできる紙書籍とは異なり、電子書籍ではユーザの手元のデバイスの色再現性によってカラー表現が最終的に決定されてしまう。つまり、制作側が1%、2%単位で色を追い込む必然性は薄いということだ。もちろん「iPad用」などといった形でターゲットデバイスを絞り込めばその限りではないが。
また、一般的には印刷で使用されるCMYKカラーより電子デバイスで使用されるRGBカラーの方が色域が広いため、印刷用データで使用した画像を電子書籍用に流用しても問題は起きにくいが、蛍光インクや箔押し印刷といった電子デバイスで再現の難しい特殊な色も存在するため、注意が必要だろう。
さらに、Kindle PaperwhiteやKobo Touchといったモノクロ電子ペーパーデバイスでカバーなどのカラーイラストを表示させた場合、背景に対して彩度/明度がほとんど変わらず、色相だけが異なるロゴ文字は背景に溶け込んで見えなくなってしまうといったような状況も考えられる。さまざまなデバイスでの表示を考えたテストが必要になってくるだろう。
図4入る
モノクロデバイスでの視認性の低下
いかがだろうか?
同じ「書籍」とは言いながら、紙書籍と電子書籍は似て非なるものであることがご理解いただけただろうか?
もちろん電子書籍は将来大いに期待できる分野だが、それは紙書籍とは異なった表現手段として発達していくだろう。柔軟なWebへのハイパーリンクや動画・音声の埋め込みといったものは、電子書籍でなければ表現できない。一方で製本を含めた「コンテンツ総合パッケージ」としての紙書籍の魅力も確かに存在する。
これら2種類のコンテンツは、どちらか一方が主であるわけではなく、従であるわけでもない。現状では先に紙書籍が刊行され、その後で電子書籍が出ると言った流れが続いているが、おそらく近い将来、先に電子書籍を出し、ある程度の人気が確認できた後で紙書籍を刊行する流れが起きてくるだろう。
電子書籍には写真の代わりに動画を挿入するといったように、双方でコンテンツの構成を変える試みも出てきそうだ。
こうしたことを念頭に置くと、将来的には紙書籍/電子書籍双方の元になるコンテンツをまず作り、そこから双方のコンテンツを分岐生成してそれぞれをファイナライズする、というワークフローに合理性が見えてくる。では「元になるコンテンツ」は何で作るのか。出来るなら特定のメーカーの販売・囲い込み戦略の影響を受けにくいオープンな形式が望ましいし、ある程度制作やチェックのツールが整っていればなお良い。すなわちこれが、国際オープン規格である「XML」に期待される役割ということになる。
(XMLパブリッシング研究会)