─グーテンベルクの遙か彼方へ─このブログはEPUB3をはじめとした電子書籍制作の現場からの「現地レポート」を目指しています。電子書籍制作、アプリケーション開発など、多方面の方々からの積極的なご意見をお待ちしております。※『InDesign→EPUB3用XHTML作成ワークフロー』は通常エントリに移動しました。『ジャンル別まとめ/ダウンロード』からアクセスできます。前ページへEPUB用IVS/サロゲートペア文字チェッカーを作ってみた2013/05/07前回のエントリで書かせていただいた通り、現状IVS/サロゲートペア文字はビューアの表示でトラブルになるケースが多いため、EPUB3データの中にIVS/サロゲートペア文字が混入していないかどうかチェックするためのチェッカーを作ってみました。X0213に符号位置割り当てのないスペース文字が一部のリーディングシステムで文字化けするとのお話がありましたので、こちらのチェックもできるようにいたしました(ある方よりご要望をいただいたため機能を追加しました)。引数としてEPUBファイルのパスを与えてやると内容をチェックしてログを出力するだけの簡単なものですが、制作の役に立てていただければ幸いです。Mac、Winともに使用することは可能ですが、環境によってはモジュールの追加インストールが必要になるかも知れません。MinGW」と入力)。3.0を組み込み、同時にログ出力できるようにしたドロップレットを作ってみました。10.6/10.7/10.8で動作を確認しています。10.5でも動作自体はしたのですが、Perlの呼び出しでエラーが出ました。Perlのアップデートが必要になると思われます。実行ログMac版ドロップレットはIVS/サロゲートペア文字のチェックとEPUBCheckを連続実行しますので、多数のepubファイルをまとめてチェックすると多少の時間がかかります。チェック結果は、epubファイルと同じ場所に出力される「EpubTotalDataCheck.log」で一括確認できます。同名のファイルが存在していた場合は末尾に追記します。チェック完了時にアラートを表示また、全てのファイルのチェックが完了するとアラートを表示します。バックグラウンドでチェックさせておいても安心です。こちらのスクリプトを使用したことにより生じた損害等につきましては、一切責任を負いかねますので、あくまで自己責任にてご使用ください。ドロップレットのダウンロードはこちらからどうぞ。ダウンロードはこちらなお、Windowsでは、事前にActiveperl等のperl環境のインストールが必要です。(2013.5.07)ご要望をいただき、ログファイルにチェックした日付・時刻を出力する機能を追加いたしました。(2013.5.09追記)「電書ちゃんねる」に、epubcheckに関する記事が掲載されたようです。「エラーメッセージ一覧日本語訳」はとても参考になるありがたい資料ですのでぜひ参照することをおすすめします。(2013.5.23追記)数値文字参照形式でドキュメント内に挿入されたIVS/サロゲートペア文字、特殊幅スペース文字のチェックに対応させる形でソースコードを修正しました。Mac用アプリにつきましては「EPUB3トータルデータチェッカー1.1」にてEpubCheck3.0.1にも対応させました。(2013.5.29追記)特殊幅スペース文字として「|」(U+007C)が検出されていた問題を修正しました。ダウンロードコンテンツも同様に修正済みです。IVS・サロゲートペア文字※1対応の最新状況をチェックしてみました。外部からのEPUB3の取り込みをサポートしていないビューアもありますので完全とはいきませんが、ある程度の参考にはなるのではないかと思います。チェックしたのはこのあたりを参考にしてサロゲートペア303文字、前回のmonokanoさん、NAOIさんの資料を参考にしたIVS文字127文字(Windows8でIVS対応した文字)です。IVS文字、サロゲートペア文字ともにこのテストの文字が全てではありませんので、あらかじめご了承ください。各ビューアの画面スクリーンショットを収めたPDF資料をダウンロードできるようにしておきましたので、適宜ご参照いただきながらお読みいただければと思います。テストに使用したepubデータも同じくダウンロードできるようにしましたので、お手持ちの端末等で自由にお試しください。IVS文字の表示にはビューアだけではなく、フォントの側の対応も必要となりますので、今回のテストでは各ビューア内で選択可能なフォントにそれぞれ切り替え、スクリーンショットを撮っています。添付資料内のフォント名表記は各ビューア内の表記に従いました。これはあらかじめお断りしておきたいのですが、IVSやサロゲートペアで表すような文字は、一部の学術系書籍および人名漢字以外ではほとんどニーズのないような文字が大半を占めます。従って、これらの文字の現時点での正確な表示をもって各ビューアの品質の絶対評価をしようとは思っておりません。前回のエントリで述べたように、Windows8のIVS対応によってテキスト内にIVS文字が混入する可能性を否定できなくなりましたので、「IVS文字を適切に無視して親字のみを表示する」実装は期待したく思っています。」(20BB7)※2のように、ATOK等の日本語入力システムで無意識に入力可能な文字も存在していますので、少なくともこういった比較的使用頻度の高い文字に関しましては、主要ビューアでの早い段階での表示対応を望みたいと思っています。E0101)が化けていることを除けば、かなり理想的な対応状況です。」はサロゲートペア文字+IVS異体字の組み合わせですので、化けている理由はそのあたりかもしれません。IVSで本来求められる「最低限親字を表示し、IVS文字を適切に無視する」という実装になっており、高く評価できます。化けている文字はおそらくフォント側に字形が収録されていないものと思われますので、ビューア側の実装としてはまず合格と言って良いように思います。◎:正しく字形を表示(iOS6)iPad、iPhoneなどのiOS端末で使用できるAppleのEPUB/PDFビューア、iBooksです。iOS6.1.3ではおおむねIVS文字は親字が表示されてIVS文字は無視され、サロゲートペア文字は縦横ともにきちんと表示されるというかなり評価できる状態です。」(2000B)などいくつかの文字が化けますが、これはフォントに字形が収録されていないためでしょう。iOS5.1.1の環境ですと、サロゲートペア文字が縦書き時にほとんど表示できず、かろうじて表示できている文字も化けているというような状態になりました。IVS文字も「□」で表示されてしまっています。つらい状態ですが、古い環境ではあり、まあ致し方ないところかと思います。Readerは.TTFフォントは全て表示可能だが、公式にはライセンスに従ってIPAex明朝およびIPAexゴシックをオプションアプリ形式で配布している、とのコメントをいただきましたので、今回は「標準フォントセット」およびオプション配布の「IPAex明朝」、「IPAexゴシック」についてテストをしました。テスト結果はかなり面白いもので、「標準フォントセット」ではIVS文字がきちんと異体字字形で表示されるもののサロゲートペア文字は全く表示されず、「IPAex明朝」/「IPAexゴシック」ではIVS文字は「□」で表示されてしまうもののサロゲートペア文字はきちんと表示されました。PaperWhiteです。kindleに関しましては、epubファイルをkindlegen2.8にてmobiデータに変換し、テストしております。」(237FF)以外はきちんと表示されています。この2文字につきましては、おそらくフォント側に字形がないために表示できていないものと思われます。」を正しく表示できています。フォントの違いによるものと思われます。」(2000B)が消えてしまう以外はきちんと表示出来ています。」(2A61A)が化けるのですが、これはフォントに収録されている字形数の差によるものと思います。」(200A4)が横転表示されてしまいました。使用頻度の高い文字はほぼ無いのですが、該当する文字を使用する場合にはCSSで正立を指示する必要がありそうです。◎:ほぼ全ての字形を正しく表示KinoppyのWindows版アプリです。iOS版とほぼ同じ状態です。レンダリングエンジンが同一であることが推測できます。◎:全ての字形を正しく表示KinoppyのMac版アプリです。」がきちんと表示され、さらに横転してしまっていた文字も正立しています。Mac版のみバージョンが1.4.3ですので、レンダリングエンジンのバージョンアップの結果、きちんと表示出来るようになったと見てよいかもしれません。すれば、近い将来iOS版やWindows版のKinoppyでも正常な表示が期待できそうです。注力していくのではないかというイメージがありますし、そういった分野ではIVS/サロゲートペア文字の表示に関して実際にニーズがあるでしょう。Amazon等に対する差別化のポイントとしても有効なのではないかと思います。こちらは組版の確かさには比較的信頼感のある端末だったのですが、IVS/サロゲートペア文字の表示に関しては、各行のIVS/サロゲートペア文字の後ろの文字列がごっそり消えてしまうという結果になりました。これはEPUB3コンテンツにこれらの文字が混入していた場合、完全に可読性が損なわれる「事故」になってしまうことを意味します。Kobo向けコンテンツの制作では、IVS/サロゲートペア文字がコンテンツ内に含まれていないかをきっちりチェックし、外字画像にするなどの対応を取る必要がありそうです。Android版です。こちらはIVS文字は「□」で化けて表示され、サロゲートペア文字は正常に表示されるという標準的な結果が出ています。IVS文字は化けてしまいますが、可読性を致命的に損なうわけではありませんので大きな問題にはならないでしょう。touchではきちんと読めないコンテンツがある」時点でストアの魅力を多少なりともスポイルするのは間違いありません。Touchのファームウェア修正を期待します。△:縦書き時に内容を表示出来ずMacで比較的良く使われていると思われる汎用EPUBビューア、Murasakiです。こちらはIVS文字が「□」で化けて表示され、サロゲートペア文字を含む縦書きのファイルを表示しようとするとアプリがフリーズしてしまうという結果が出ました。webkitのサロゲートペア文字対応の問題に引きずられているものと思うのですが、詳しいことはわかりません。個人的にMurasakiはEPUB制作時のチェック用として多用しているビューアですので、早い段階で修正されることを望みたいです。Chrome内で使用できる汎用EPUBビューア、ReadiumをMac版Chrome内で動かした場合です。サロゲートペア文字が縦書き時にほとんど化けてしまい、表示できません。表示出来ている文字も本来のコード位置とは異なる字形が表示されてしまっています。IVS文字に関してはほぼ全ての文字が異体字字形で表示されているのですが、文字が全て横転して表示されてしまっています。」がサロゲートペア文字+IVS文字の組み合わせなことに関係がありそうです。Chrome内で使用できる汎用EPUBビューア、ReadiumをWindows版Chrome内で動かした場合です。IVS文字は「□」に化けてしまう他、縦書き時に横転して表示されてしまっています。サロゲートペア文字は横書きではきちんと表示されるものの、縦書き時には直前の始めカギ括弧が消えてしまっています。Readiumは本来、校正用のビューアとして本命視されていただけに、現在のこの状態は残念です。ライセンス団体「Readiumファウンデーション」として法人化とのニュースがありましたので、今後IVS/サロゲートペア文字の表示を含めてレンダリングエンジンの改善を期待したく思っています。◎:正しく字形を表示SONYの電子書籍ストア、ReaderのAndroid版アプリです。IVS文字、サロゲートペア文字ともに、テストに使用した文字に関してはほぼ完全な対応でした。」(29FCE)もきちんと表示出来ていますので、ある程度独自のカスタマイズがなされているように思われます。最初に書いたように、こうした異体字の表示については人名漢字と一部の学術書以外ではほとんどニーズはないように思いますが、各ビューアのレンダリング実装の進捗度が想像できて、個人的にはなかなか楽しい実験でした。原稿にIVS文字が含まれている可能性をEPUB制作者も想定しなければなりません。サロゲートペア領域の文字の中には、ATOK等で特に意識せずに入力可能な文字がすでに存在しています。これらの文字の混入によってコンテンツの可読性が完全に損なわれる「事故」を誘発してしまうことはなんとしても避ける必要があります。今後、制作サイドにはEPUB内のこうした特殊文字を検知し、排除するスキルが必要になるでしょう。ビューア開発サイドの方には、「例え特殊文字が含まれていたとしても事故にならない実装」を求めたく思っています。SIP)」と表記するのが正しいと思いますが、実際のEPUB3データのハンドリングとしてはビューアでEPUBを展開する際にUTF-16などに展開され、その際の処理で追加漢字面の文字化けが起きると推測されるため、ここではわかりやすさを重視して「サロゲートペア文字」と表記しています。0213では「吉」に包摂されているため独立した字形として収録されていないが、UnicodeのCJK統合漢字拡張Bには独立した字形が存在するため、実際には入力が可能。KBDownload(2013.4.18)ご指摘をいただき、技術的な用語を若干修正いたしました。Reader自体は.TTFファイルなら何でもOKで、公式にはライセンスに従ってIPAフォントをオプションアプリ形式で配布している形になる」とのコメントをいただきましたので、表記を修正させていただきました。(2013.4.18追記)Android端末の機種によってもフォント表示結果が変わってくるとのご指摘をいただきましたので、機種名を追記しておきます。Lion」、Windows環境は「Windows7」にてテストしました。~」に参加してきました。IVS普及への姿勢が少し見えてきた感はありますので、印刷/電子書籍の業界に実際に近々出てきそうな影響についてちょっと書いてみたいと思います。Microsoftのセミナーに関しては「ちくちく日記」さんにレポートが上がっておりますので、そちらも合わせてご覧ください。IVS/IVD入門」につきましては、「イジハピ!」さんのエントリが参考になります。IVSとはどういうものかということなのですが、これはごくざっくり言うと「テキストの規格拡張」です。IVSはこれをさらに拡張し、主に日本で人名漢字や地名等で用いられている漢字の「異体字」を表記できるようにしようというものです。IVSはこれを将来的にWebや電子書籍の世界でも使用可能にするために作られた規格です。無視して親字の字形を表示する」というソフトウェア実装が期待されています。これにより、「少なくとも親字は表示される」ようにし、完全な文字化けによって可読性が大きく損なわれることを防ぐわけです。IVSは「テキストの規格拡張」ですので、過去に作られた厖大なあらゆるテキストを扱うソフトウェアに影響が及ぶと考えられ、文字化けや運用エラーなどの事故を引き起こす可能性を否定できません。Office等の日本語入力で一般ユーザーがIVS文字を無自覚に入力できるようになった場合、入力者の母数が大きいため影響がどれだけ広範囲に及ぶかちょっと見当もつきません。DTPや電子書籍ももちろんこの問題と無縁ではありませんので、上記のセミナーにとても興味があったわけです。Windows8のIVS対応はJIS90字形との互換範囲に留まる上記2つのセミナーに出席したことでMicrosoftのWindows8でのIVS対応の方針がおぼろげに見えてきたのですが、どうやら目的としては「JIS90字形とJIS2004字形の同時表示」にあるようです。Vista以降Windows搭載フォントでの字形の基準が変わり、JIS90字形で一般的だった字形が出せなくなりました※1。このためMicrosoftにJIS90字形対応について多数の要望が寄せられ、現状でこのニーズに応える技術がIVSしか見あたらないため、IVSを採用した、という流れのようです。8でIVS文字を入力するためにはMS-IMEの設定が必要になるとのことですので、少なくとも今のところは、DTP等への影響はそこまで大きくはなさそうです。これに関してはちょっと安心しました。8単体でIVS文字が入力可能になった」ことは確かですので、対策は必要です。これまで組版ソフト内でか扱えなかった人名用漢字などを、一般ユーザーが設定が必要とはいえ入力できるようになるわけですから、中には好んで使う人もいると見なければなりません。完全に閉じた環境でDTP制作をしている会社ならともかく、外部からデータを受け取る可能性が少しでもある印刷・制作会社は全て、今後はIVSが混じったデータが入稿されてくる可能性があると見て対処する必要がありそうです。IVSのやっかいな点は繰り返しますが「テキストの規格拡張」だということで、つまりWord内のIVS入りテキストをそのままコピー&ペーストでInDesignやIllustratorに持って行けてしまいますし、OS自体がIVSの字形表示に対応していなくても(何せテキストなので)、データのハンドリング自体はできてしまいます。XPのメモ帳で保存したデータにIVSの異体字指定文字が混じってくる可能性もあるのです。PerlやRubyなどのテキスト処理プログラムも例外ではありません。なると、WordやExcelのドキュメントのみをチェックすればいいという話でもなく、「全ての形式のデータをテキストに落としてチェックする」くらいの対策が必要になるでしょう。IVSに対応はしていますが、親字とIVSの異体字指定文字をアプリ内で別々に選択できてしまう少々怖い仕様なこと、Illustrator等は現状でIVSに対応していないことを考えると、まだDTPで安心して運用できる状況とは言い難いため、現状ではテキスト内でIVSが使われている箇所を特定し、字形パレット等から入力できるGSUBの異体字に置き換えてやることになるかと思います。IVSはテキストですので、(特に127文字程度であれば)Indesignタグテキスト等を経由させて同一字形のGSUB異体字に変換してからInDesignに取り込むこともそう難しくはなさそうです。再校等で追加入稿されてきたデータや、Illustrator等での対応に気をつける必要はあります。IVS表示に対応していないツールでは化ける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対応状況につきましては、いずれ調査の上、別エントリでご報告したいと考えております。KBDownload(2013.4.04)monokanoさんにご指摘いただいた部分を修正いたしました。修正したのが主な修正点です。Tajimaこちらにて、電子書籍&Web制作を担当しています。このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。整うことを願って、現場からの声を発信していこうと目論んでおります。当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。License.『電書魂』のコンテンツはクリエイティブ・コモンズによりライセンスされています。記事名の記載と、記事へのリンクを貼って頂ければ、コンテンツを自由にご利用いただくことができます。