前回のエントリーで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）

　以前のエントリーでDTPデータ内で使われているOpentypeグリフ字形（Adobe1-6）の一部が、電子書籍では外字画像にしないと表現できない問題について書かせていただきました。出版デジタル機構（pubridge）もいよいよ動き始め、実際に電子書籍を作るための環境づくりに入っている方も多いかと思いますので、印刷用DTPデータ→電子書籍で字形が変わってしまう文字についての現時点でのまとめをあらためて掲載しておきたく思います。電子書籍制作環境づくりのお役に立てていただければ幸いです。なお、検証に使用した環境はMac OS 10.7/InDesign CS5です。InDesign以外のアプリケーションでもAdobe1-6グリフ字形を呼び出せるインターフェースを持ったものであれば同様の字形変化が起きるものと思われます。

確実に外字化が必要になると思われる文字

CID/GID番号のみしか割り当てられていない文字

CID/GIDのみの文字（一部）

　UNICODE/Shift_JISの双方に文字コードの割り当てがなく、InDesignなど対応アプリケーション内部からのみ呼び出すことができる文字です。囲み数字や丸数字などを中心に、ざっと数えた限りでは約700文字あるようです。これはそもそもUNICODEにもコード割り当てがない文字のため、確実に外字にする必要があります。InDesign内でこれらの文字を選択し、テキストエディタ等にコピー＆ペーストすると「1A」という文字に化けます。

合字

任意の合字（一部）

　複数の文字コードで構成された文字をInDesign等の対応アプリ内でOpenTypeの機能を呼び出して「合字」として表示している文字です。InDesign字形パレットの分類では、「任意の合字（dlig）」「分数（afrc）」「欧文合字（liga）」などがこれにあたります。InDesign内でこれらの文字を選択し、テキストエディタ等にコピー＆ペーストすると、内包している複数の文字に展開されて表示されます。

現時点では外字化した方が無難と思われる文字

サロゲートペア領域の文字

サロゲートペア領域の文字（一部）

　InDesignの字形パレットの表示でUnicodeのコード番号の表示が「2xxxx」と、先頭に2の付いた5桁になっている文字群です。調べた限りでは303文字あります（参照）。ATOKの文字パレットでは、「CJK統合漢字拡張B」「CJK互換漢字補助」となっています。内部的に2つの文字コードの組み合わせで1つの字形を表示しており（サロゲートペア）、多くのリーディングシステムでは問題なく表示されますが、未対応のリーディングシステムが存在するため現時点では外字化した方が無難と思われます。JIS第3水準・JIS第4水準の文字の他、JIS割り当てのない文字も多数含まれています。使用頻度の高い文字はほとんどありませんが、U+20B9Fの「叱」（印刷標準字体）や、U+20BB7の「吉」（つちよし）などは問題になるかもしれません。全てUnicodeのみに割り当てがある文字のため、ドットブック／XMDFなどではいずれにせよ外字化が必要になりそうです。「EPUB日本語基準研究グループ」のホームページから参照できる、「EPUB3日本語ベーシック基準v1.0」の28ページにこれに関しての記述があります。

外字にするかどうか出版社サイドの判断が必要になる文字

同じ文字コードに2つ以上の字形バリエーションが割り当てられている文字

旧字体（一部）

　旧字体／エキスパート字形／すべての異体字／修飾字形　など、ひとつの文字コードに複数の字形が割り当てられ、InDesignなど対応アプリケーション内部から字形パレット等で呼び出していた文字です。これらに関しては以前のエントリーで詳しく書きましたのでそちらを参照していただければ幸いです。人名・地名等の固有名詞以外では問題になりにくいとは思いますが、一般に字形差がとても微細なため、目で追って確認するのが難しい文字群です。

フォントのバージョンによって字形の変わる可能性がある文字

JIS90字形の文字（一部）

　以前のエントリーでも少し触れましたが、Pr6／Pr5などJIS90字形を基準としたフォントを用いて作られたDTPデータを元データとして電子書籍を制作する場合に、JIS規格の例示字形の変化の影響で字形の変わる可能性のある文字が168文字あります（フォントによって変化に差があるようです）。こちらにも字形差が微細なため、目で追って確認するのが難しいものが多く含まれます。一点しんにょう→二点しんにょうへの例示字形変更なども行われたため、人名漢字などで問題になるパターンが多くありそうです。JIS90→JIS2004の例示字形変化について、詳しくはこちらをご参照ください。

ドットブック／XMDFなどで外字化が必要になる可能性のある文字

Shift_JISに割り当てがなく、UNICODEのみで使える文字

Unicodeのみの文字例（色つきのもの）

　文字コードがShift_JISのドットブック、Unicodeが仕様上は使えるものの、おそらく既存のリーディングシステムの互換性の問題でShift_JISが使われることが多いと思われるXMDFで外字化が必要になりそうな文字群です（HTMLのように数値文字参照等で表記できるのでしょうか？手元の資料ではちょっとわかりませんでした）。XMDFビルダーではピンク色で表示され、XMDFビルダー内簡易ビューアではゲタ記号に化けて表示されるようです。EPUB3は文字コードがUnicode（UTF-8）のため、外字化しないでそのまま表示できます。

◇

　このほか、「インライン画像として文字を作り、テキスト内に挿入していた文字」や、「外字の表示用に独自OpenTypeフォントを制作して表示していた文字」、「Biblosなどの市販外字フォントを利用していた文字」など、各ドキュメントごとに対応が必要になる場合も当然ありますが、これらは個々に対応するしかないと思われるため詳しくは書きません。以前フォントメーカーの営業の方にお聞きした話では、望ましい字形をDTPアプリケーションソフト内での操作なしで表示するために、フォントメーカーにカスタムフォントを特注して使用している印刷会社もあるとのことです。このような場合、その印刷会社以外の会社でDTPデータから電子書籍化する場合に、全ての文字を目で追って確認する必要が出てくるため校正費用がとても高くつくことが予想できます。可能であれば元DTPデータを制作した会社での電子書籍化が望まれるところです。

　また、出版デジタル機構および緊デジ関係者の方への要望として、特に上述の「基本字形に変化してしまう字形」および「フォントのバージョンによって字形の変わる文字」に関して、どのレベルまでを必ず外字にしなければならないのか（人名・地名のみ外字化するのか、初稿で外字化する文字を確認して指示していただけるのか、あるいは全て外字にするのか）、外字対応のガイドラインを策定し、出版社／制作会社の双方に告知していただきたく思います。

（2012.5.11）