日本語EPUBの作成で結構面倒なのが「使える文字と使えない文字のチェック」です。何せ単行本1冊で10万文字くらいはあったりしますので、それを目視でチェックして使えない文字を見分けるなどというのは普通に考えて無理があるわけです。また、例えベテランの作業者なら対処できるとしても、そういう機械的な処理に関しては極力機械に任せて省力化したいところです。ということで自前のチェッカー内に組み込む目的で「Adobe-Japan1-6」および「JIS X 0213:2004（JIS2004）」を対象として外字のチェッカーを作りました。

　ターミナルで

　のような形で指定すると、以下のようなチェックログのファイルを出力します。上の例はAdobe-Japan1-6用チェッカーの指定例ですが、JIS2004用チェッカーも使い方は同じです。

　普段ならリストを貼って公開するところなのですが、なにせ膨大な文字をリスト化しているためとんでもない長さになるため、ダウンロードリンクを貼る形とします。

　なお、Adobe-Japan1-6用のリストは@monokanoさんのご厚意により、テキストエディタ「浮紙」用の特定文字項目ファイル内のリスト（正規表現のパターン）を流用させていただいています。
　JIS2004用のものは自前で調べて書きました。しんどかった（笑）。

　Mac用のアプリに統合したものはこちら。Epubcheckのバージョンも4.2.2に上がっています。

（2020.1.17）

　「JAGAT XMLパブリッシング準研究会 各社EPUBビューア日本語組版表示チェック」を公開しました。

https://juntajima.github.io/XMLPub_EPUBRSCheck/

　日本印刷技術協会（JAGAT）XMLパブリッシング準研究会の2018-2019年の活動としてEPUBのビューアで日本語組版に関連する各種CSSプロパティ等が再現できているかのチェックを行い、その結果をまとめたものを公開するものです。

　有志の研究会での活動ですので、あくまで参考情報という位置づけですが、現在商用電子書籍ビューアにおけるCSS表示対応の公的な情報源が存在しませんので、コンテンツ制作時の参考になることもあるかと思います。

　以下、表示チェックを行うにあたって大変だった点、今後期待したいことなどを書いておきます。

商用電子書籍ビューアの表示チェックは大変な作業

　商用電子書籍ビューアの表示チェックはかなり大変な作業です。商用電子書籍ビューアは通常個々のデバイス環境ごとに「アプリ」として提供されており、サイトで購入した電子書籍をその中で読むことができます。ブラウザと違い、「ユーザーの指定した外部ファイルを読み込むこと」はその流れの外側の話になるわけです。つまり、外部ファイルを読むための機能は別途用意しなければならないものになるため、各ビューアごとに読み込みの方法がバラバラだったりします。KindleなどではiOS版で表示チェックを行うためには事前にファイル形式の変換が必要になったりもするため、実は結構予備知識が必要になります。XMLパブリッシング準研究会での共同チェック作業でも、そのあたりの知識の共有はかなり大変でした。そんな大変なことまでやって外部ファイルを読み込み、表示させる必要がなぜあるのかと言えば、これはひとえに「電子書籍を制作する際にきちんと表示できるかを制作者や発注者が確認するため」です。

そもそも外部ファイルの読み込みをサポートしていないビューアも多数ある

　とはいえ外部ファイルの読み込みをサポートしているならまだ良い方で、読み込みをサポートしていないビューアがまだ多数あるのが現状です。これが何を意味するかと言えば「実際に販売してみるまできちんと表示できているかわからない」ことになるわけで、この点で表示を実環境でチェックしながら制作作業を進められるWebページ制作と電子書籍制作は全く状況が異なっています。電子書籍の実制作では枯れたCSSプロパティしか実質使えない理由がこれです。率直に言って発注者の最終確認が得られない状態で製品が販売まで行くことが健全とは全く思えないのですが、結果としてそうなってしまっているのが今の電子書籍の状況です。
　なお今回のチェックでは相当新しく、実装状況が危ぶまれるプロパティにも踏み込んでいますが、外部ファイルの読み込みをビューア側がサポートしていなければ、実質ずっと新しいCSSプロパティが電子書籍で使えないことになるでしょう。もちろん個々のプロパティのサポート状況を各ビューアに直接問い合わせればその限りではないのですが、これを個別のコンテンツごとにやるのは相当に敷居が高いです。

販売時にはサーバサイドで変換処理がかかることもある

　また、外部ファイル読み込みできちんと表示ができていたとしても、実際に電子書籍を販売する際には別途サーバサイドで変換処理が行われ、表示が変わってしまうケースもあります。例としてAmazon Kindleでの埋め込みフォントの例を挙げておきます。サーバサイドで変換がかかり、埋め込みフォントが除去されてしまったりするようなことが起きます。

公的なEPUBビューア表示チェックの仕組みができることを望みたい

　Webの世界にはwpt.fyiのように、公的なRS表示チェックの枠組みがあります。ただ現状、電子書籍ビューアは上記のような理由でそういった仕組みを利用して個々のCSSプロパティの対応状況を確認することができません。今後、電子書籍ビューアが継続的に発展してゆくためには、何らかの公的な表示チェックの仕組みが必要になると思います。制作サイドの一員として、そういった枠組みが整備されることを強く望みます。

（2019.7.10）

　先日発表がありましたEPUBの公式データチェッカー、EPUBCheck4.2なのですが、試用してみたところ、これまでのバージョンでは出なかったエラーが表示されてしまいました。具体的には以下のようなエラーです。

ERROR(NAV-011): ./Desktop/test.epub/item/navigation-documents.xhtml(19,73): ‘toc’ nav must be in reading order; link target ‘item/xhtml/p-001.xhtml#toc-2C4CB0422A16-4C9E-B148-05A28E0A49C9’ is before the previous link’s target in spine order.

　従来のバージョンでは出ていなかったエラーが新バージョンでは出るようになったということなので、どういうことなのかちょっと策定に関わった方などに聞いてみたのですが、どうやら以下のような話のようです。

1. もともとEPUBの仕様としては論理目次（電書協ガイド仕様の場合はnavigation-documents.xhtml）のリンクの表示順はOPFのSPINEの順番と同じでなければならないという決まりがあった
2. ただ、これまでのEpubCheckにはそれをチェックする仕組みがなく、論理目次のリンクの表示順を自由に変えてもエラーにはならなかった
3. 今回のアップデートで厳密にそこをチェックするようになり、エラーになるようになってしまった

　確かに規格を厳密に解釈すればエラー扱いになるのかも知れませんが、これに沿ってチェックをすると現在既に市場で流通しているEPUBファイルがかなりの確率でエラー扱いになりそうなのでちょっと困ったなという印象です。EPUB3.0.1に関してはエラー扱いにしないなどの形でもう少し既に大量に流通しているものへの後方互換性を考慮して欲しかったというのが正直なところです。

　とは言え新規に作るものはこのルールに従って作れば良いわけなのでそこまで問題はないはず。過去に作ったものへの対応は今後ファイル受け入れストア側の対応状況を見ながら考えたいと思っています。現場に大きな負担がかからない形で収束すれば良いのですが。

　なお、OPFについて少し解説しておきますと、これはそのEPUBの書誌情報や収録されているファイル等を記述するパッケージとしてのEPUBのコアになるファイルで、その中のSPINEブロックというのは「EPUB内に複数収録されているXHTMLファイルを見せる順番を決める」ことがメインの目的になるものです。ビューア上でEPUBを見ていくとここに書かれている順番通りに内容が表示されます（その他、ページめくり方向の規定や見開き時にページをどちらに配置するかの指定もここ）。今回はここの記述の順番とビューアの目次機能から呼び出す方の目次（論理目次）の記述順が同じでないとエラーになるようになった、という話になります。

（2019.5.22）