ePubは正常なのにKoboでエラー？犯人はAdobeのDRMだ！

手元のePubファイルに問題がないにもかかわらず、Kobo端末でうまく開けないという経験はありませんか？その原因は、多くのファイルを支配している「Adobe Digital Editions」のDRM（デジタル著作権管理）にあります。技術的には正当なファイルであっても、Adobe側の仕様やチェック機構が厳格すぎる、あるいは不具合を抱えているせいで、端末側で「壊れている」と判定されてしまうケースが非常に多いのです。この問題に振り回されないためには、DRMフリーのファイルを選択するか、変換ツールを使って最適化し直すのがエンジニア流の回避策と言えるでしょう。

要するに、Adobeは後方互換性をサポートしているけど、epubの方はと言えば、International Digital Publishing Forumがカオスな状況を作り出して、常に最新のトップ標準を目指そうと競い合ってるんだ。まあ、いつも通りのやり方で、ユーザーに絶えずアップグレードを強いるわけだ。

この情報には本当に助かった。自分の使ってるリーダーソフトが古いから、epubじゃなくてPDFを選んでた理由がよく分かったよ。

自分としては完全に後方互換性サポート派だな。M$が昔やってたドキュメント標準のアップグレードを思い出すよ……あれも、アップグレードしなかったら「運が悪かったね」で終わりだったからな。

結局いつもCSSが原因なんだよ。

でも、根本的に壊れているレンダラーに対しては、CSSのバリデーションなんてできないよ！

epubの標準規格には、どのバージョンのCSSをサポートすべきかという規定がないんだ。最新のCSSが動く保証なんて元からなかったわけだし、レンダラーが壊れてると言うのは少し違う気がするな。

Adobe Digital EditionsとRMSDKは、最近Wipro Engineeringに売却されたよ：https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-... (https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-editions.html)

書き始めた頃は、数ヶ月かけてようやく書き上げた本のバリデーションボタンを押す瞬間が怖くて仕方なかった。なぜなら、いつも何かしらのエラーを突きつけられるから。

LaTeXで卒論の草稿をコンパイルしようとして泣きそうになってた修士課程の学生を思い出したよ。「とりあえず書いて、フォーマットは後で考えればいい」という教えを文字通りに受け取りすぎて、締め切りギリギリになって初めてコンパイルを試してたんだ。

残念ながら、epubやepubcheckは、筆者が言うほど文句なしに素晴らしいリソースというわけじゃない。W3C, Inc.がEPub仕様のメンテナンスを引き継いだ頃（EPub 3.1が現役の頃だったかな）、彼らはWHATWG HTMLや、際限なく拡張される他のブラウザ仕様を参照するようになったんだ(1)。「リビングスタンダード（生きた標準）」ということで、バージョン管理やQAが存在しない。その結果、見出しやセクションの定義を見直したHTMLのバージョンをベースにしたことで、Epub 3.2は既存のepubを非準拠にしてしまった。Calibreや他のツールがいまだに3.1、あるいは2を推奨しているのはそのためだよ。

CSSのmin()関数が拒否される件も、極めて複雑なCSS仕様をまるごと取り込むことが有益ではないという良い例だ。結局のところ、電子書籍リーダーは常に進化するモダンなブラウザじゃないんだよ。

僕の理解だと、Kobo端末はファイル名を.kepub.epubにすると、より高度なレンダリングエンジンが使えるようになるよ。（たしかePub 3ベースだったはず？）これで問題が解決するかは分からないけど、自分はKoboに転送する前に、必ずkepubify (https://pgaskin.net/kepubify/try/ (https://pgaskin.net/kepubify/try/)) を通して変換してるよ。

Adobeも昔からずっとこんな感じだよ。Flashで膨大な市場シェアをドブに捨てたのも、QAに数百万ドル投資する代わりに、あんな信頼できないパートナーはいない方がマシだという結論で全ブラウザメーカーを団結させちゃったからだ。

昔はFlashでいくつかリリースしたこともあるけど、本当にひどいソフトウェアだったよ。ランダムなクラッシュ、ある場所の変更が関連のない機能に悪影響を及ぼすような「ハイゼンバグ（特定しようとすると消えるバグ）」とかね。しかも、800ドルくらいしたのにサポートは皆無。再現可能なバグをいくつも報告して検証用コードも送ったけど、次のリリースが出るまで返事一つなく、送られてくるのは「バグが直ってるかもしれないから、定価でライセンスを買って確かめてね」という自動返信だけだった。

HTML-to-epubコンバーターのEPublish ( https://frequal.com/epublish/ (https://frequal.com/epublish/) ) を作った時、同じような壁にぶつかったよ。異なるスタックと様々なバージョンのEPUBで作られた無数のリーダーとの互換性を維持するのは本当にフラストレーションが溜まる。

自分の初の小説「Means and Motive」を出版した時もEPublishを使ったんだけど、DRMフリーでここで公開してるよ：https://www.amazon.com/dp/B0GYCZJVGX (https://www.amazon.com/dp/B0GYCZJVGX)

今のところ互換性の問題は聞いてないから、EPublishはターゲットとするEPUBのバランスをうまく突けてるんじゃないかな。とはいえ、Web開発でIE6をターゲットにしていた古き良き（悪しき）時代を思い出すのは同意するよ。古いリーダーが未だに存在してる以上、どうしても一番下のレベルに合わせなきゃいけないからね。

そもそもmax-widthみたいなプロパティをサポート（あるいは無視）してくれるePubリーダーを使ってるだけで幸せだと思ったほうがいいかも :-P。

正直、自分もたまにePubファイルを編集するんだけど、表示がおかしくなったり動かなくなる余計なスタイルを削るためにやってるんだ。自分では問題ないファイルでも、他の人からは「読めない」と言われることもあってさ。本当に、どうしても必要な凝ったフォーマット（画像にできない数式とか、どうしても必要な場合のみ！）以外は、IE4ですら誤表示しないような、これ以上ないほどシンプルなHTMLに固執すべきだと思うよ。

まあ、そんなことが実現するとは思えないけど、究極の互換性を求めて、一番シンプルなHTML/CSSに変換し直してくれる「epubリコンストラクト」ツールでも作ろうかなと考えたりもするよ :-P。