Adobe Digital Editions 2.0

　Adobeの汎用EPUBビューア、Adobe Digital Editions 2.0です。
　Mac版でサロゲートペア文字の「」（29FCE）が表示出来ていないこと、Windows版でIVS文字の「」（242EE E0101）が化けていることを除けば、かなり理想的な対応状況です。「」はサロゲートペア文字＋IVS異体字の組み合わせですので、化けている理由はそのあたりかもしれません。IVS文字で異体字が表示されず、親字が表示されているものもありますが（6FF9 E0101など）、Unicode IVSで本来求められる「最低限親字を表示し、IVS文字を適切に無視する」という実装になっており、高く評価できます。化けている文字はおそらくフォント側に字形が収録されていないものと思われますので、ビューア側の実装としてはまず合格と言って良いように思います。

iBooks3.1

　iPad、iPhoneなどのiOS端末で使用できるAppleのEPUB/PDFビューア、iBooksです。
　iOS6.1.3ではおおむねIVS文字は親字が表示されてIVS文字は無視され、サロゲートペア文字は縦横ともにきちんと表示されるというかなり評価できる状態です。フォントに游ゴシック体を選択した場合のみ「」（2000B）などいくつかの文字が化けますが、これはフォントに字形が収録されていないためでしょう。
　ただiOS5.1.1の環境ですと、サロゲートペア文字が縦書き時にほとんど表示できず、かろうじて表示できている文字も化けているというような状態になりました。IVS文字も「□」で表示されてしまっています。かなりつらい状態ですが、古い環境ではあり、まあ致し方ないところかと思います。

Himawari Reader Ver3.3.0

　Android環境で広く使われている汎用EPUBビューア、Himawari Readerです。
　作者の中野さんより、Himawari Readerは.TTFフォントは全て表示可能だが、公式にはライセンスに従ってIPAex明朝およびIPAexゴシックをオプションアプリ形式で配布している、とのコメントをいただきましたので、今回は「標準フォントセット」およびオプション配布の「IPAex明朝」、「IPAexゴシック」についてテストをしました。
　テスト結果はかなり面白いもので、「標準フォントセット」ではIVS文字がきちんと異体字字形で表示されるもののサロゲートペア文字は全く表示されず、「IPAex明朝」／「IPAexゴシック」ではIVS文字は「□」で表示されてしまうもののサロゲートペア文字はきちんと表示されました。

Kindle PaperWhite ファームウェア5.3.4

　Amazonの電子ペーパー端末、Kindle PaperWhiteです。
　なお、kindleに関しましては、epubファイルをkindlegen2.8にてmobiデータに変換し、テストしております。
　IVS文字は全て「□」で表示され、サロゲートペア文字は「」（26AFF）および「」（237FF）以外はきちんと表示されています。この2文字につきましては、おそらくフォント側に字形がないために表示できていないものと思われます。

Kindle for Android 3.8.2

　KindleのAndroid版アプリ、Kindle for Androidです。
　Kindle PaperWhiteとほぼ同様の結果ですが、こちらは「」と「」を正しく表示できています。おそらくフォントの違いによるものと思われます。

Kinoppy for Android Ver 1.4.2

　紀伊国屋書店の電子書籍ビューア、KinoppyのAndroid版アプリ、Kinoppy for Androidです。
　IVS文字が異体字字形で表示され、サロゲートペア文字も「」（2000B）が消えてしまう以外はきちんと表示出来ています。フォントを「IPAexゴシック」に切り替えた場合のみIVS文字の「」（2A61A）が化けるのですが、これはフォントに収録されている字形数の差によるものと思います。

Kinoppy for iOS Ver 1.4.2

　KinoppyのMac版アプリ、Kinoppy for iOSです。
　Android版アプリと同様にかなり理想に近い対応ですが、サロゲートペア文字の「」が消えてしまう以外に、縦書き時に「」（200A2）や「」（200A4）が横転表示されてしまいました。使用頻度の高い文字はほぼ無いのですが、該当する文字を使用する場合にはCSSで正立を指示する必要がありそうです。

Kinoppy for Windows Ver 1.4.2

　KinoppyのWindows版アプリです。
　iOS版とほぼ同じ状態です。レンダリングエンジンが同一であることが推測できます。

Kinoppy for Mac Ver 1.4.3

　KinoppyのMac版アプリです。
　サロゲートペア文字の「」がきちんと表示され、さらに横転してしまっていた文字も正立しています。Mac版のみバージョンが1.4.3ですので、レンダリングエンジンのバージョンアップの結果、きちんと表示出来るようになったと見てよいかもしれません。だとすれば、近い将来iOS版やWindows版のKinoppyでも正常な表示が期待できそうです。

　紀伊國屋書店は今後、学術書・専門書に注力していくのではないかというイメージがありますし、そういった分野ではIVS/サロゲートペア文字の表示に関して実際にニーズがあるでしょう。Amazon等に対する差別化のポイントとしても有効なのではないかと思います。

Kobo Touch ファームウェア2.4.0

　楽天Koboの電子ペーパー端末、Kobo Touchです。
　こちらは組版の確かさには比較的信頼感のある端末だったのですが、IVS／サロゲートペア文字の表示に関しては、各行のIVS／サロゲートペア文字の後ろの文字列がごっそり消えてしまうという結果になりました。これはEPUB3コンテンツにこれらの文字が混入していた場合、完全に可読性が損なわれる「事故」になってしまうことを意味します。Kobo向けコンテンツの制作では、IVS／サロゲートペア文字がコンテンツ内に含まれていないかをきっちりチェックし、外字画像にするなどの対応を取る必要がありそうです。

楽天Kobo Android版 バージョン4.8

　楽天KoboのAndroid版アプリ、楽天Kobo Android版です。
　こちらはIVS文字は「□」で化けて表示され、サロゲートペア文字は正常に表示されるという標準的な結果が出ています。IVS文字は化けてしまいますが、可読性を致命的に損なうわけではありませんので大きな問題にはならないでしょう。
　ただ、koboに限らず「購入した書籍をどの端末でも読むことができる」のが今の多くの電子書籍ストアの売りですので、「kobo touchではきちんと読めないコンテンツがある」時点でストアの魅力を多少なりともスポイルするのは間違いありません。早い段階でのKobo Touchのファームウェア修正を期待します。

Murasaki バージョン2.1

　Macで比較的良く使われていると思われる汎用EPUBビューア、Murasakiです。
　こちらはIVS文字が「□」で化けて表示され、サロゲートペア文字を含む縦書きのファイルを表示しようとするとアプリがフリーズしてしまうという結果が出ました。おそらくwebkitのサロゲートペア文字対応の問題に引きずられているものと思うのですが、詳しいことはわかりません。個人的にMurasakiはEPUB制作時のチェック用として多用しているビューアですので、早い段階で修正されることを望みたいです。

Readium Version 0.9（Mac）

　ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをMac版Chrome内で動かした場合です。
　サロゲートペア文字が縦書き時にほとんど化けてしまい、表示できません。また、表示出来ている文字も本来のコード位置とは異なる字形が表示されてしまっています。
　IVS文字に関してはほぼ全ての文字が異体字字形で表示されているのですが、文字が全て横転して表示されてしまっています。また、「」（242EE E0101）のみが縦書き時に化けてしまい、横書き時にもIVS文字の部分が化けて表示されてしまっているのですが、これは前述したように「」がサロゲートペア文字＋IVS文字の組み合わせなことに関係がありそうです。

Readium Version 0.9（Windows）

　ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをWindows版Chrome内で動かした場合です。
　IVS文字は「□」に化けてしまう他、縦書き時に横転して表示されてしまっています。また、サロゲートペア文字は横書きではきちんと表示されるものの、縦書き時には直前の始めカギ括弧が消えてしまっています。

　Readiumは本来、校正用のビューアとして本命視されていただけに、現在のこの状態は残念です。Readiumプロジェクトは先日、非営利電子書籍規格ライセンス団体「Readiumファウンデーション」として法人化とのニュースがありましたので、今後IVS／サロゲートペア文字の表示を含めてレンダリングエンジンの改善を期待したく思っています。

Reader（Android版）バージョン3.1.2

　SONYの電子書籍ストア、ReaderのAndroid版アプリです。
　IVS文字、サロゲートペア文字ともに、テストに使用した文字に関してはほぼ完全な対応でした。ReaderのレンダリングエンジンはベースがAdobeのRMSDKですので、異体字表示対応の優秀さはこれによる部分も大きそうなのですが、Adobe Digital Editions 2.0で文字化けしていた「」（29FCE）もきちんと表示出来ていますので、ある程度独自のカスタマイズがなされているように思われます。

Unicode IVSは「テキストの規格拡張」

　まず、そもそもUnicode IVSとはどういうものかということなのですが、これはごくざっくり言うと「テキストの規格拡張」です。Unicodeは世界中の文字をひとつの文字集合規格で表現できるようにして国による文字コードの違いによる「文字化け」トラブルを解消し、コード変換のコストをほぼゼロに近づけることを目指す壮大なプロジェクトですが、Unicode IVSはこれをさらに拡張し、主に日本で人名漢字や地名等で用いられている漢字の「異体字」を表記できるようにしようというものです。これらの文字はこれまではInDesignなどの印刷用組版アプリや官公庁の戸籍運用システムなどの閉じた環境内でのみ使用可能でしたが、Unicode IVSはこれを将来的にWebや電子書籍の世界でも使用可能にするために作られた規格です。

　技術的には、ひとつの文字を表すのに「親字＋異体字指定文字」というデータ構造を取っており、ビューア側のフォントがIVSに対応していないなどの理由で正しく目的の異体字を表示出来なかった場合には、「異体字指定文字を無視して親字の字形を表示する」というソフトウェア実装が期待されています。これにより、「少なくとも親字は表示される」ようにし、完全な文字化けによって可読性が大きく損なわれることを防ぐわけです。

　ただし、なにしろIVSは「テキストの規格拡張」ですので、過去に作られた厖大なあらゆるテキストを扱うソフトウェアに影響が及ぶと考えられ、文字化けや運用エラーなどの事故を引き起こす可能性を否定できません。
　特にWindowsやMac OS、Microsoft Office等の日本語入力で一般ユーザーがIVS文字を無自覚に入力できるようになった場合、入力者の母数が大きいため影響がどれだけ広範囲に及ぶかちょっと見当もつきません。DTPや電子書籍ももちろんこの問題と無縁ではありませんので、上記のセミナーにとても興味があったわけです。

Windows8のIVS対応はJIS90字形との互換範囲に留まる

　上記2つのセミナーに出席したことでMicrosoftのWindows8でのIVS対応の方針がおぼろげに見えてきたのですが、どうやら目的としては「JIS90字形とJIS2004字形の同時表示」にあるようです。Vista以降Windows搭載フォントでの字形の基準が変わり、JIS90字形で一般的だった字形が出せなくなりました^※1。

　このためMicrosoftにJIS90字形対応について多数の要望が寄せられ、現状でこのニーズに応える技術がIVSしか見あたらないため、IVSを採用した、という流れのようです。従って、Windows8搭載フォント内でのIVS対応は127（122＋5^※2）文字に留まり、さらに現状Windows 8でIVS文字を入力するためにはMS-IMEの設定が必要になるとのことですので、少なくとも今のところは、DTP等への影響はそこまで大きくはなさそうです。これに関してはちょっと安心しました。

今後はIVS入りドキュメントが入稿されてくる可能性がある

　さて、そうは言っても条件付きとは言え「Windows 8単体でIVS文字が入力可能になった」ことは確かですので、対策は必要です。

　これまで組版ソフト内でか扱えなかった人名用漢字などを、一般ユーザーが設定が必要とはいえ入力できるようになるわけですから、中には好んで使う人もいると見なければなりません。つまり、完全に閉じた環境でDTP制作をしている会社ならともかく、外部からデータを受け取る可能性が少しでもある印刷・制作会社は全て、今後はIVSが混じったデータが入稿されてくる可能性があると見て対処する必要がありそうです。

　そして、IVSのやっかいな点は繰り返しますが「テキストの規格拡張」だということで、つまりWord内のIVS入りテキストをそのままコピー&ペーストでInDesignやIllustratorに持って行けてしまいますし、OS自体がIVSの字形表示に対応していなくても（何せテキストなので）、データのハンドリング自体はできてしまいます。Windows XPのメモ帳で保存したデータにIVSの異体字指定文字が混じってくる可能性もあるのです。PerlやRubyなどのテキスト処理プログラムも例外ではありません。そうなると、WordやExcelのドキュメントのみをチェックすればいいという話でもなく、「全ての形式のデータをテキストに落としてチェックする」くらいの対策が必要になるでしょう。

結局DTPでの影響／対処法は？

　さて、では結局DTPで現状Unicode IVS入りのドキュメント入稿にどう対処すべきかということなのですが、以前JEPAセミナーで発表させていただいたようにInDesignはCS4以降でUnicode IVSに対応はしていますが、親字とIVSの異体字指定文字をアプリ内で別々に選択できてしまう少々怖い仕様なこと、Illustrator等は現状でIVSに対応していないことを考えると、まだDTPで安心して運用できる状況とは言い難いため、現状ではテキスト内でIVSが使われている箇所を特定し、字形パレット等から入力できるGSUBの異体字に置き換えてやることになるかと思います。IVSはテキストですので、（特に127文字程度であれば）Indesignタグテキスト等を経由させて同一字形のGSUB異体字に変換してからInDesignに取り込むこともそう難しくはなさそうです。ただし、再校等で追加入稿されてきたデータや、Illustrator等での対応に気をつける必要はあります。

　IVSの有無をチェックする方法ですが、IVSは親字のコードの後に「U+E0100〜U+E01EF」の異体字指定文字が並んでいる構成になっていますので、単純にIVSが含まれている文字を知りたいだけなら、この範囲の文字が含まれているかどうかを各種ツールでチェックすれば良いでしょう。また、現状IVSの表示に対応していないツールでは、異体字指定文字が化けて表示されますので、最悪これを目視でチェックすれば良いことになります。

　MicrosoftがWindows8内で使用可能としたIVS文字に関しましては、以前もお世話になったmonokanoさん、NAOIさん制作の資料をご提供いただけましたので、こちらからダウンロードしてご参照ください（InDesignドキュメントです）。

　おそらく、IVSがテキスト内に含まれているかどうかをチェックするツールの作成自体はそう難しくありません。ただ、なにしろ「WordやExcelのドキュメントを開いてコピー＆ペースト」という完全に一般定着している作業の流れを変えることになりますので、必ずチェックすることを末端まで徹底させることは相当大変そうな話ではあります。

電子書籍ではどうなるの？

　次に電子書籍でのIVS対応状況ですが、まずXMDFやドットブックでは文字コードの基本がShift_JISですので、Unicodeの発展フィーチャであるIVSはそもそも使用できません。字形を再現するには外字画像にする必要があるでしょう。

　EPUB3では、「まだしばらくは使わない方が無難」といったところかと思います。少し前に見てみた記憶では、紀伊国屋書店のアプリ「kinoppy」のiOS版でIVS字形の再現まで確認できた他は、ほとんど対応しているアプリはなく、それどころかIVS文字が化けて表示されたり、IVS文字以降のテキストがごっそり表示されなかったりといったようなビューアの実装が見受けられました。

　ただ、正直まだ黎明期のEPUB3ではビューアアプリのアップデート間隔がかなり短いため、私もまだ最新ビューアの実装は追いきれていません。各電子書籍ビューアの最新IVS対応状況につきましては、いずれ調査の上、別エントリでご報告したいと考えております。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

市川せうぞーさん　小形克宏さん　NAOIさん　monokanoさん