以前のエントリーで、Unicodeにコード位置を与えられており、1文字で表現できる合字（U+2668「♨」など）をInDesign内で入力する際に方法が2通りあり、字形が全く同じであるために目視確認による校正作業ができない、といったことを書かせていただきました。「旧字体」「印刷標準字形」等に関しても同じ状況で、かなり困った状態だったのですが、InDesign環境設定の「代替字形」チェックボックスを使うことで、とりあえず合字などをどちらの方法で入力したものなのか見分けることはできそうですので、お知らせしておきたく思います。「すべての異体字」などで字形置換が行われている文字もこちらで見分けられそうです。ただし以下はあくまで一時しのぎの「対処療法」で、外字対策が必要な全ての文字が見分けられるわけではなく、使う上で十分な注意も必要になることをあらかじめご留意ください。

注意が必要だが、「代替字形」チェックボックスで置換字形のチェックが可能

環境設定「代替字形」チェックボックス

　InDesignには環境設定メニューの「組版」タブ内に「代替字形」というチェックボックスがあります。本来の字形とは違う字形に置換して表示されている文字をInDesign内でハイライト表示するためのものです。このInDesign環境設定の「代替字形」チェックボックス自体ははるか以前からあり、確認した限りではCS2の時代から機能自体は存在していたようです。そんな機能があるなら以前のエントリーは何だったんだと言われそうなのですが、実はこの機能には重大な欠点があり、日本語組版で無条件に使用できる機能ではありませんでした。

句読点等までハイライトしてしまう

　この「欠点」というのは「縦組み時の自動字形切り替え（vert）まで全てハイライト表示してしまう」というものです。これにより、句読点や括弧類、拗促音などまで全てがハイライト表示されてしまい、本来の対象文字以外が大量にピックアップされてしまいますので、縦組みで字形置換をチェックする目的ではまともに使えません（そして、印刷標準字形等の字形置換を使用している書籍は文芸書等に多く、そうした書籍は縦組みで制作されている場合が多いことは容易に想像できます）。

　ただ、今回は最終目的が「電子書籍にすること」ですので、縦組みで作成されたDTPデータであっても「組み方向を横組みに切り替える」ことでこの機能を有効に生かせるのではないかと思い、テストをしてみました。

横組み切り替え時の注意点

改行位置で合字が泣き別れ

　組み方向切り替えには、注意しなければならない点がいくつかあるようです。まず、テキストボックスが「フレームグリッド」ではなく「テキストフレーム」になっている場合、改行位置に合字が来ていた場合に文字が泣き別れになってしまう可能性があるようです。テキストボックスが「フレームグリッド」になっている場合は、今回テストした限りではこの問題は出なかったのですが、データの状態次第では同様の問題が出てくる可能性はあります（ちょっとテストしきれません）。
　また、縦中横に設定されていた数字やアルファベット類、縦組みで表示することを前提として挿入されていたインライン画像類などのチェックにも影響が出そうです。

グリフ置換文字のみをハイライト

　こうした問題を考えると、「もとの縦組みドキュメントをコピーし、横組みに切り替えてあくまで代替文字のチェック用として使う」あたりが無難な利用法ではないかと思います。ドキュメントを2つ並べて横組みの文字のハイライト表示を参考に縦組みドキュメントを修正していくイメージです。

　テストしてみた限りでは、文字パレットの機能を用いて字形置換された合字や、字形パレットで字形置換された旧字体（つまり文字化けを起こすもの）のみがきちんとハイライトされますので、チェック目的に限定すれば十分役に立ちそうです。

字形パレットで合字を上書き

　ちなみに例えば「温泉」で入力されて合字変換されている「♨」の親字を「♨」そのものに変換するには、字形パレットの表示メニューを「選択された文字の異体字を表示」にし、文章中でハイライト表示されている該当文字「♨」を選択して、字形パレット内に表示された字形「♨」をダブルクリックし、文字を上書きすればOKです。ただ、合字の場合、構成要素の一部分のみ（「温」のみなど）を引っかけて選択してしまうことが多々ありますので、慎重に構成要素全てを選択した上で文字を上書きする必要があります。

「代替文字」でチェックできない文字

　なお、このInDesignの「代替文字」チェックボックスでチェックできる、外字対応が必要になる可能性がある文字は「合字」「印刷標準字形」「すべての異体字」など、InDesign内の機能で字形切り替えが行われているものに限られます。「CID/GID番号のみしか割り当てられていない文字」「ビブロスフォントなどの外字フォントを用いて表示されている文字」「JIS規格の例示字形の変化の影響で字形の変わる可能性のある文字」などは、InDesign側で行われている字形切替ではないため、このチェックボックスではハイライト表示されませんので注意が必要です。「インラインで埋め込まれた外字画像」ももちろん同様です。こうした文字類は、別途チェックが必要ですのでご注意ください^※1。

※1　チェックした限りで「代替字形」でのハイライト表示対象は以下の通りです

合字：○（「♨」などUnicode1文字で入力できる文字のうち、文字パレットの「任意の合字」を用いて変換せずに入力された文字（＝合字ではない）を除く）

旧字体・エキスパート字形（GlyphForm）：○（字形置換が行われた文字のみハイライト）

すべての異体字（aalt）：○　CID番号しか持たない文字：×　箇条書きリスト：×

スモールキャップス：×　オールキャップス：○　外字フォント：×

JIS例示字形の変化の影響で字形の変わる可能性のある文字：×

（2012.6.18）

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