「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）

　W3C文書「日本語組版処理の要件（JLREQ）」の改版作業が始まっています。JLREQは海外のシステム開発者などに向けて日本語組版を扱うシステムで対応するべき要件を伝える目的で作られた文書で、現在最新の第2版は2012年4月に発行されていますが、これをより正しく、使いやすい形に直してゆく作業です。

　この流れで私もW3CのJapanese Text Layout task force (jlreq)の会合で現場サイドとしての参考意見を述べることになりました。せっかくですので日本の組版関係者からの意見も集約したく思い、このブログを書いています。あくまで私が出版・組版関係の人の意見を聞くために個人としてやる聞き取りであって、W3C公式でもなんでもないのでお間違いなきよう。GitHubにissue立てるの慣れてる人はそちらが早いと思います。

　一応「日本語組版処理の要件（JLREQ）」がどういう性格の文書なのかということについて触れておきます。これはW3Cの正式な文書なのですが、「規格書（Specification）」とは異なり、「要件（Requirement）」になります。ざっくり言いますと「日本語組版で行うべき処理（＝紙の本の組版作業において行われてきた処理）をそれを実現する技術的な方法には踏み込まずに記述したもの」です。書かれている処理には従来手作業で行われてきたものも多く含まれていますので、Webなど自動流し込み処理を前提とせざるを得ないシステムでは実現困難なものも多く入っています。従って、「日本語組版処理の要件（JLREQ）」に記述があるからといって、将来確実にWeb等で使えるようになる、という話では全くありません。ただし、新たに海外のシステム開発者が日本語組版に関連するシステムを作るような場合に真っ先に参照される文書であることも間違いなく、実際W3C仕様の中には日本語組版処理の要件を参照先としたリンクが多数既に入っています。次世代の組版ソフトが開発される際にも当然参考にされるでしょう。このことから、やはり将来日本語の表示環境に今回の改訂が大きな影響を及ぼしそうとは言えるかと思います。

　つまり、「これまで紙の本作りで行われてきた組版処理の方法を自動処理的にできるかどうかは考えずにひとまず記録しておいて、（日本人だけでなく）誰もが参照できるようにしようよ」という話なので、「日本語組版処理の要件」に目を通していただき、普段やっている組版処理とは違う記述が標準とされていて違和感があったら教えて欲しいですし、普段の仕事で普通にやっていることが項目ごと抜けていたら指摘していただければ有り難いです。それは改版に盛り込む価値のある情報の可能性があります。

　私も参加していますJAGAT XMLパブリッシング準研究会では、過去数年にわたってJLREQに沿ってCSSの実装状況を見てきており、それについての議事録はこのブログの過去エントリにまとまっています。以下にリンクをまとめて掲載します。

JLREQとCSS（1）
JLREQとCSS（2）
JLREQとCSS（3）
JLREQとCSS（4）
JLREQとCSS（5）
JLREQとCSS（6）
JLREQとCSS（7）
JLREQとCSS（8）
JLREQとCSS（9）

　こちらなども参考にしていただき、JLREQ改訂に関してのご意見をいただければと思います。これはどういった要望がありそうかについてのざっくりとした意見募集ですので、技術的な実現の難易度などは気にせず自由に意見を寄せていただいて大丈夫です。ご意見はこちらのブログのコメント欄に書き込んでいただいても構いませんし（コメント許可制のため表示反映までに時間がかかりますのでご了承ください）、Twitterで私のアカウント宛てにメンションを飛ばしていただいても構いません。その際はハッシュタグ「#jlreq」等を付けていただけますと後日拾い上げる際に漏れがなさそうかなと思います。

　出版・組版関係者の方、よろしくお願いいたします。

（2019.4.25）