以前のエントリーで印刷用DTPデータを電子書籍化する際に発生する外字問題に関して書かせていただきました。緊デジの事業開始も迫っていますので、今回はそもそも電子書籍で「外字」を使うということがどういうことなのか、ごく一般的な注意点について書かせていただきます。なおこれは、主に出版社サイドの方に対してのエントリーのつもりで書いております。過去のエントリーとの表記の重複等があるかとは思いますが、あらかじめご了承ください。制作サイドの方向けには、別途出版デジタル機構さまより詳細な資料が提示されるかと思いますので、そちらをご参照ください。

現在電子書籍で使用できる文字数は、印刷物のそれよりかなり少ない

電子書籍で使用可能な文字の数

　さまざまな種類の「外字」そのものの定義については、こちらのWikipedia項目に詳細な説明がありますので、ここでは今回問題になりそうな電子書籍での「外字」について簡単に述べるに留めておきたく思います。

　上記Wikipedia項目の表記のうち今回問題となる「外字」は、「文字コードなどの特定の文字集合に含まれない文字」を指します。より詳細には、印刷用文字集合規格であるAdobe-Japan1^※1に含まれていながら、UnicodeやShift_JISに含まれておらず、テキストファイル内でそのまま表示できない文字のことです。

　一例として「小塚Pr6N」の場合を見てみますと、InDesignで使用できる文字数は23058文字、うちEPUB等で使用できるUnicodeで表現できる文字数は15393文字です。XMDF／ドットブックで使用できるShift_JISの場合はさらに少なくなり、約7000文字です。UnicodeやShift_JISで表現できない文字は、外字画像として表現するか、もしくはInDesignがバックグラウンドで保持している親字への変化を容認するかといった対処が必要となります。

合字／CIDのみの文字の文字化けの例

　つまり、現状電子書籍で使用できる文字数が、印刷用データの作成環境で使用できる文字数よりかなり少ないために、外字での対策が必要となります。この「UnicodeやShift_JISで表現できない文字」のうち、以前のエントリーでも書いたように「複数の文字コードで構成された合字」や「CID/GID番号のみしか割り当てられていない文字」等のテキストで表現できない文字については、そのままテキストで表現はできないため、基本的に制作会社サイドの責任で外字画像にすることになります^※2。

親字への字形変化の例

　一方で、出版社サイドでXMDF・ドットブック／EPUBで表現できる文字に変化することを許容するか、外字にして対応するかの判断が必要となりそうなのは、「印刷標準字体」「エキスパート字形」「JIS90字形」などの微細な字形変化に関する部分です。厳密に印刷物と同じ字形の再現を求めた場合、かなりの文字を外字にすることになりますが、現状、電子書籍（およびWeb）の外字表現には、以下のような問題点があり、通常の紙印刷物と同じような外字の表現は技術的にできません。ご一読いただければ幸いです。

印刷物と電子書籍での「外字」表現の違い

　通常、印刷用DTPデータの制作で外字を挿入する場合には、

1　Illustrator等で外字画像を作り、InDesignの文中に画像をインラインで挿入する
2　フォント作成ソフトを使ってフォントを作り、InDesign内からそのフォントを指定する
3　Biblosなど市販の外字フォントを使用し、InDesign内からそのフォントを指定する

外字がはっきりと確認できてしまう

　などの手順が考えられますが、いずれもきちんと制作されていれば、実際に印刷した際には周囲の文字とほとんど区別がつきません。しかし、現状の電子書籍での「外字」は、テキスト内にPNG等の形式で制作した「画像」を挿入する形になるため、文章の流れの中ではっきりと「外字」であることがわかってしまうことがしばしばあります。

　また、現状電子書籍ではテキストを表示するフォントについても制作サイドで指定することはできず、読者が選んだビューアーに依存することが多いため、外字にした文字が通常テキスト部分とはっきりと違ってしまうといった問題が起きてきます。

フォントを変更しても外字はそのまま

　さらに、読者の好みで本文フォントを切り替えられるビューアーも存在するため、読者がこうしたビューアーを選択した場合、なおさら「外字」がはっきりと目立ってしまう可能性が高くなります。本文をゴシック体に切り替えても外字部分だけは明朝体のまま、といった状況が起こり得ます。

　参考画像は、緊デジで制作されたものではありませんが、実際に現在市販されているXMDF電子書籍内での外字表示の例です。外字がはっきりと見分けられる状態がご確認いただけるかと思います。

　加えて、例えばEPUB3で「外字にルビを振る」といった処理をした場合に、一部のビューアでルビが表示されないといった現象も確認できています。EPUB3の日本語表現に関してビューア側の実装がまだ定まっていないため、このビューアを問題視できるような状況ではありませんが、こうした状況も存在していることをご理解いただければ幸いです。外字は通常のテキスト表示とは異なる「例外的な処理」になり、電子書籍は紙印刷物とは違って読者サイドの閲覧環境の対応も必要になるため、こうした状況は今後も出てくることが考えられます。

　あくまで個人的な意見ですが、コンテンツの最終的な完成度を考慮した場合、現状の電子書籍での外字対応は固有名詞等に限定し、最小限に留めたほうがコンテンツの相対的な品質は上がるのではないかと考えております。

将来的にはテキストの一部として異体字を表現できる可能性がある

　なお、こうした状況は、漢字の異体字に関しては将来的にUnicode IVSが普及し、異体字を画像としてではなくテキストの一部として（つまり外字ではない形で）表現できるようになれば相当改善されるかもしれません。ただし、前述したように従来の紙印刷物とは異なり最終生成物は紙ではありませんので、IVSに関しても制作環境側だけではなく読者の閲覧環境側での対応も必要となります。従って、順当にIVSが普及するとしても実際にコンテンツ内でIVS異体字を使用できるのはまだ当分先の話になりそうです。

　今回の例でもわかるように、電子書籍はあらゆる意味で黎明期であり、紙書籍と同様の表現力を持つにはまだまだ時間がかかります。各出版社のみなさま、制作会社のみなさま、書店のみなさまのご理解・ご協力をいただき、共に新たな文化を健全に育成していければ良いと考えております。

　なお、以下に以前の記事をもとにPDF化した、外字化が必要となりそうな文字の簡単な資料を用意させていただきました。ご参照いただければ幸いです。

ChangeGlyphCharactor_ID2ebook.pdf

1 file(s) 3.82 MB

Download

　今回お世話になりました方々は以下の通りです（50音順／順不同）。私一人ではこの資料を整えることは到底不可能でした。みなさまの深い知識・技術にあらためて尊敬の念を感じるとともに、ご協力に心からお礼を申し上げます。

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

※1　Adobe-Japan1コレクションには1-6／1-5／1-4などがありますが、ここでは現在最もグリフ数の多い1-6を例として取り上げています。各文字集合規格の詳細につきましては、こちらのページが参考になります。

※2　単位などは通常の文字列に置き換えるといった対応も考えられますが、いずれにせよ一定のルール策定が必要と思います。また、各種字形変化に関しましては、市川せうぞーさんに制作していただいたムービー群が参考になります。あわせてご参照ください。

・Unicodeポイントを持たず、CID番号しか持たない文字は「1A」という文字に化ける

・「箇条書きリスト」の機能を用いて入力したリストの頭につく番号／記号が消える

・「スモールキャップス」「オールキャップス」の大文字が小文字に変わる

・ビブロスフォントセットは元の文字に変わる

・SINGグリフレット機能を利用して入力した異体字・外字は基底文字に戻ってしまう

（2012.6.6）

　EPUB3での外字ルビに関する部分につきまして、実際には存在しない「日本語EPUB3」という規格が存在しているかのような誤解を与えてしまうのではないか、とのご指摘をいただきましたので、表記を「日本語EPUB3自体規格策定が済んでいるとは言い難いため」から「EPUB3の日本語表現に関してビューア側の実装がまだ定まっていないため」に訂正させていただきました。

（2012.6.8追記）

　前回のエントリーでInDesignのデータ内の異体字について書かせていただきましたが、こちらは現在出版デジタル機構の深沢さんのもとでオールスターのみなさんが対策中ですので、私は予想されるもうひとつの「文字化け」の検証をしてみることにしました。「フォントを含む画像の変換」です。
　DTPデータに挿入されているデータのうち、フォントを含むデータのほとんどはIllustratorで制作されたEPS形式の画像データと思われます。Illustratorの画像内に使用されている全てのフォントがクライアントマシンにインストールされていれば特に問題はないのですが、他社の制作したデータを受け入れて電子化することを考えなければならないコンテンツ緊急電子化事業（以下緊デジ）では、受け入れ側に「フォントがない」ことが十分に想定できます。さらに印刷に使用される和文フォントは決して安くはないため、緊デジの仕事のためだけに使われている可能性のある全てのフォントを購入することは、制作会社サイドにとってかなりの負担になってしまいます。
　緊デジ事業の制作仕様書Ver1.01によりますと、「画像はできるだけDTPデータの貼込画像から取り出すが、困難な場合は底本からスキャンしてもよい」とあり、最終的な逃げ道は「底本からスキャン」という形で用意されているのですが、紙の本からのスキャニング画像は（ドラムスキャナなど）よほど上等なスキャナを用いでもしない限り取り込み時に多少なりとも色が変化してしまいます。そのため、これの修正に少なからぬ時間を要するのが実情です。こうしたレタッチ作業の手間などを考えると、制作側としても可能であれば貼込画像を流用し、作業時間の短縮をはかりたいところです。以下、どういったパターンで画像を取り出すのが最も「文字化け」に悩まされず、短い時間で電子書籍用の画像を準備できるのかの検証です。参考にしていただければ幸いです。

IIllustratorでなくPhotoshopで開いてみる

　XMDFビルダーにはIDML（InDesign Markup Language）経由でInDesignデータ内の貼り込み画像を自動インポートする機能があるのですが、緊デジの仕様書に「図表のキャプションやクレジット文字などは画像と一緒にビットマップ化する」とあることや、取り込まれる画像サイズや挿入位置のコントロールが難しいことから、この機能は使わずに画像を別に用意しておき、原本を参照して後からあらためて挿入する方向性で考えることにしました。

フォントがないと警告が表示される

フォントを埋め込むチェックボックス

InDesignからPDFを経由してPhotoshopへ

　ただ、多くの場合、画像のキャプションはデータ作成時に再校以降の修正のやりやすさを考慮し、InDesign側で挿入されていることが多いように思います。前述したように緊デジの仕様書には「図表のキャプションやクレジット文字などは画像と一緒にビットマップ化する」とありますので、可能であればInDesign内のキャプションもIllustratorの画像データと同時にデータ化したいところです。そこで、InDesignから一度PDFで画像を含むページごとデータを書き出してしまい、これをPhotoshopで開き、トリミングすることでキャプションを含めて画像化する流れを考えてみました。写真データなどフォントを含まない画像データであっても「キャプションを含めて画像化」することは必要になるため、これができれば画像作成の流れを統一することが可能になります。以下、簡単なワークフローになります。

1　InDesignからPDF X-1aで書き出す

書き出し時にフォントがなければ警告が出る

「ファイル」メニュー「PDF書き出しプリセット」から、「PDF X-1a:2001（日本）」を選択し、画像を含むページの組版データをPDFで書き出します。PDF X-1aでの書き出し時点でフォントがなければ警告が出ますので、プリフライトチェックにもなります。

2　PDFをPhotoshopで開き、必要な部分だけをトリミングする

PDFをPhotoshopで開く

書き出されたPDFをPhotoshopで開き、必要な部分だけをトリミングします。Photoshopで開く際に解像度などを入力する必要がありますが、中間作業ファイルですので解像度は高めで構わないと思います。今回は「900dpi」に設定しました。電子書籍用ですので、モードは「RGBカラー」です。トリミング後、「レイヤー」パレットメニューから「画像を統合」を選択し、背景を透明→白にしておきます。

3　解像度を調整する

解像度を変更する

緊デジ仕様書に「ビットマップ画像のサイズは、ターゲットデバイスである長辺1536ピクセル以内とする」とあるので、これに従って画像サイズを調整します（画像サイズに関しては仕様書の記述にまだあいまいさが残っており、もう少し具体化して欲しいところです。底本で版面サイズ一杯に配置された画像の場合に「長辺1536ピクセル」という理解で良いのでしょうか？）。

4　「Webおよびデバイス用に保存」で画像を書き出す

画像を書き出す

「ファイル」メニューから「Webおよびデバイス用に保存」で画像を書き出します。電子書籍用の画像ですので、普通に保存するより「Webおよびデバイス用に保存」を使って保存するほうがファイルサイズ的に有利です。緊デジ仕様書には画像形式として「JPEG／PNG」の指定がありますので、今回はPNG-24を選択して書き出したのですが、仕様書にもどういった場合にJPEGを選び、どういった場合にはPNGを選ぶべきかの簡単な記述はあった方が良いかも知れません（連続階調の写真→JPEG／単色塗りつぶしイラスト→PNGと理解していますが）。

◇

　以上、緊デジ用「フォントを含む画像の変換」の流れです。結論として、保存時にフォント埋め込みがなされたIllustratorデータであれば、クライアントマシン側に該当するフォントがインストールされていなくても画像化は可能と思われます。ただし、InDesign側でキャプションに使われているフォントの互換の問題はありますし、画像コンバートにはフォント以外の問題もありますので（特色とか・・・）もちろんこれだけで画像制作における問題点がすべて解決するものではありません。また、上記はあくまで現時点（5/29）でのテストであることも付記しておきたく思います。

（2012.5.29）

　前回のエントリーで書かせていただいたInDesignデータからの電子書籍化に伴う外字処理の問題について、文字コード・フォント関連について豊富な知識をお持ちの方々に関心を持っていただき、これをどうにかするための取り組みが始まりました。具体的にはものかのさん、moji_memoさん、市川せうぞーさんの面々で、ちょっととんでもないレベルの方々です。これに対して、publidge（出版デジタル機構）の深沢さんからも関心を寄せていただき、フォントメーカーの方にもアドバイスをいただく形で電子書籍の外字問題に対しての取り組みが始まりました。以下は現時点で判明している問題についての簡単なまとめです。いずれこれに関してはpublidgeから正式にどういった対策をとるべきかのアナウンスがあることと思われますが、すでにかなり「恐ろしい」事実が判明しているので、事前段階での告知の一翼を担う意味で書かせていただきます。

InDesign画面上の表示文字と、内部で保持している文字が違う

　前回のエントリーで、私は「合字」について「複数の文字コードで構成された文字をInDesign等の対応アプリ内でOpenTypeの機能を呼び出して「合字」として表示している文字」を、コピー＆ペーストすると複数の文字に展開されて表示される、と書かせていただきました。
　これに対して安岡孝一さんより U+2668「♨」など、Unicodeで1文字で表示できる文字の合字処理に関してのご質問をいただき（ありがとうございます！）、どうやらInDesign内では「♨」を2通りの入力方法で入力でき、どちらの入力方法で入力したかでテキストエディタにコピー＆ペーストした際の結果が異なるという事実が判明しました。手元にあるInDesign CS5およびCS6の体験版で確認した限りでは、XMLとして書き出した場合やEPUBとして書き出した場合でも、同様の状況が確認できます。以下、具体的な検証です。

　「♨」をInDesign内にInDesignドキュメントに入力するには、以下の2通りの方法があります。

日本語入力システムで変換して入力

1　ATOK・ことえりなどの日本語入力システム上で「♨」と変換した上で入力する。あるいは字形パレットから「♨」を選び、ダブルクリックで入力する（操作としては2通りですが入力されるコードは同じなのでまとめて表記しています）。

「任意の合字」を選んで合字に変換

2　まず「温泉」と入力し、InDesignの文字パレットのドロップダウンメニュー内「Opentype機能」から選択できる「任意の合字を」選んで「♨」に変換する。

コピー＆ペーストで文字が化ける

　この2つの入力方法では、InDesignドキュメント内での表示はどちらも「♨」で全く同じですが、実は内部に保持しているテキストは異なります。そのため、1の方法で入力した「♨」は、テキストエディタにコピー＆ペーストしても「♨」のままですが、2の方法で入力した「♨」は、「温泉」に変化してしまいます。InDesign内ではどちらの入力方法による「♨」なのか目視確認による校正作業が不可能なため、この時点でかなり頭の痛い事実です。

問題は「合字」だけではない

　さらに、この「InDesingの画面内で見えているテキストと内部に保持しているテキストが異なる可能性がある」という問題は、いわゆる「合字」だけではなく、「旧字体」、「エキスパート字形」、「JIS78字形」などでも確認できることが判明しています。わかりやすい例として「旧字体」の「學」の例を見てみます。

　ユニコード番号“U+5B78”の「學」は、“U+5B66”の「学」の旧字体に当たります。これをInDesign内で入力するには、以下の2通りの方法があります。

日本語入力システムで変換して入力

1　ATOK・ことえりなどの日本語入力システム上で“U+5B78”の「學」に変換した上で入力する。あるいは字形パレットから「學」を選び、ダブルクリックで入力する。

字形パレットで「旧字体」に字形変換

2　まず“U+5B66”の「学」を入力した上で、InDesign内字形パレットのドロップダウンメニューから「旧字体」を選び、「學」に字形を変える。

コピー＆ペーストで字形が変わる

　この2の入力方法で入力した「學」をテキストエディタにコピー＆ペーストした場合、内部に保持している文字は“U+5B66”の「学」であるため、字形が変わってしまいます。InDesign内で目視確認による校正作業が不可能なのは合字と同様です。

現在判明しているその他の問題例

　InDesignのドキュメント内で表示されている文字がテキスト化した際に変化してしまう問題に関しては、他にも以下のような事例が確認できています。

　これらの問題をお手元でご確認いただくために、サンプルファイルをご用意させていただきました。

mojibakesample

1 file(s) 469.05 KB

Download

　ビブロスフォントセット／SINGグリフレットなどは当方の環境にインストールされていないため例として入れていませんが、それ以外の字形変化に関しては一通りご確認いただけるかと思います。

◇

　現在、こちらの問題に関しては上記の方々により、検証と対策が進められています。ただ、これはあくまで有志によるものであり、世の中の全ての製作環境での検証は不可能です。こうした印刷データ→テキストの文字化け問題に関して「こういった問題もあるのではないか」と思われた方がいらっしゃいましたら、是非Twitterでハッシュタグ「#mojibake」でつぶやいてください。どなたでもかまいません。アーカイブし、対策に活用させていただきます。皆さんのお力をお借りして、できるだけ現場に負担のかからない電子書籍制作環境の構築を目指したく思います。現状での進捗状況に関しましては、こちらをご覧ください。

　なお、外字問題では上記の問題に加えて「サロゲートペア領域の文字」「Shift_JISに割り当てがなく、UNICODEのみで使える文字」「インライン画像として文字を作り、テキスト内に挿入していた文字」「外字の表示用に独自OpenTypeフォントを制作して表示していた文字」などの外字化の問題が残ります。異体字・外字対策だけでこうした状況になっていることを考えますと、「印刷用データからの電子書籍制作」が、少なくともXMDF／EPUBなどのリフロー型電子書籍に関する限り高コストにならざるを得ない現状がご理解いただけるかと思います。異体字・外字対策以外にも、インラインの表組みや合成フォント、強制改行やタブなどの特殊文字の変換など、課題が山積みです。

　こうした現状を考えた場合、以前から有識者の方が指摘されていたことではありますが、InDesignなどのDTP制作アプリケーションは制作フローの最終地点として考えるべきであり、将来的な電子書籍制作のハブとして位置づけるべきではない、という結論にあらためて至らざるを得ません。また、将来的には紙書籍に先行して電子書籍を出す「デジタル・ファースト」の動きが出てくるであろうことを考えますと、なおさらInDesign等のDTP制作ソフトに依存した電子書籍制作ワークフローは合理性を持ち得ないものと思います。

　InDesign等のDTP制作アプリケーションはあくまで「印刷物」の制作環境として位置づけ、電子書籍制作環境は別フローとして構築する。その上で双方の制作物を効率的に制作するために、印刷物／電子書籍共通の中間データから最終制作データへの変換ソリューションの最適化を図る。これが、将来的に目指すべき健全な紙書籍／電子書籍双方の制作ワークフローであるということを、あらためて強調しておきたく思います。

　これを実現するには出版社の理解、制作会社の技術蓄積、流通の再整備など課題はたくさんありますが、publidgeの事業がその第一歩となることを心から願ってやみません。

（2012.5.21）