- 検証を通過したDRMなしの EPUBでも、Kobo では「corrupted」として扱われることがあり、問題はファイル形式のエラーではなくレンダリングエンジンの互換性にある
- epubcheck は EPUB の構造と規約準拠を確認する事実上の標準検証ツールだが、特定レンダラーの古い CSS パーサの問題までは検出できない
- Kobo は Adobe の独自電子書籍レンダリングエンジン RMSDK を使用しており、このエンジンは EPUB2 ベースで作られた後に EPUB3 向けへ軽く更新されたものの、現代化はされていない
- 問題の原因は
max-width: min(150px, 30vw); という 1 行で、この有効な CSS level 4 コードが RMSDK でサポートされておらず、Adobe Digital Editions と Kobo で書籍の読み込み失敗を引き起こした
- Kobo 互換性を確認するには epubcheck だけでは不十分で、Adobe Digital Editions で実際に開いてみる追加検証が必要
epubcheck を通過した EPUB から始まった問題
- Adobe のツールは Creative Suite が業界標準だったり代替が乏しかったりするため使われることが多く、この文章の問題意識も Adobe ソフトウェアへの不満から出発している
- 新しい本は読者に直接提供されるDRM なしの
EPUB ファイルとして配布され、配布前に複数の工程を経て epubcheck の検査を通過した
epubcheck は適切に構成された電子書籍を確認する事実上の標準ツールであり、manifest が書籍内の断片や画像を漏れなく反映していなければ通過できない- HTML 要素の順序が合っていなかったり、International Digital Publishing Forum の規則から少しでも外れたりすると検証に失敗する
epubcheck を 100% 通すことは初心者には簡単ではないが、出版実務者にとっては型リンターや形式的なテストスイートに近い役割を果たす- 本来期待されるのは、
epubcheck を通過した本が EPUB 互換リーダーやアプリならどこでも動作することだ
Kobo でだけ「corrupted」が発生する
- 新しい本は
epubcheck ruleset 3.3 を通過したが、ある読者から「corrupted」というメッセージが出ると報告された
- 下位互換性の可能性を確認するため EPUB2 版も提供したが、そのファイルも規則に完全準拠していたにもかかわらず同じ問題が発生した
- その読者は、複数世代のKobo 端末で本が開けないと伝えた
- 同じ EPUB は Amazon Kindle、Apple Books、Thorium など他の環境では問題なく動作した
- 調査の結果、Kobo は Adobe の独自電子書籍レンダリングエンジン RMSDK を使っていることが分かった
RMSDK と Adobe Digital Editions に絞り込まれた原因
- RMSDK は Adobe Digital Editions の中核エンジンであり、複数の Kobo 端末や旧型の Sony・Nook 端末でも使われている
- このエンジンは 2010 年ごろに EPUB2 を中心に作られ、EPUB3 向けに軽く更新されたものの、現代化はされなかった
- RMSDK が使われている事実だけでは、
epubcheck と Kobo の結果が食い違う問題はすぐには解決しなかったが、デバッグの方向性を与えた
- Adobe Digital Editions に本を入れると予想どおり読み込みに失敗し、エラーメッセージも表示されなかった
- 再度読み込もうとすると、すでに追加済みの本なので取り込めないというメッセージが出たが、画面は白いままだった
- その後、複数の派生ファイルを作ってテストしたが、すべての派生版は引き続き
epubcheck を通過した
- フォルダ構造の再配置、メタデータ削除、言語属性削除、新しい UUID 生成、ディレクトリのフラット化、拡張子変更、ZIP の再生成、
manifest の変更を試した
- それでも Adobe Digital Editions の読み込み失敗は繰り返された
実際の原因: 有効な CSS 1 行
- スタイルシートを無効化すると本が突然読み込まれるようになり、問題の範囲がスタイルシートに絞り込まれた
- スタイルシートの一部だけを適用した複数の派生版をさらに作った末に、問題を引き起こす 1 行が特定された
.copyright img {
max-width: min(150px, 30vw);
}
- このコードは完全に有効な CSS level 4 コードだが、RMSDK はこれをサポートしていない
- このコードをより古い書き方である
max-width: 150px; に変えると、Adobe Digital Editions で本が正常に開くようになった
- RMSDK の CSS パーサはおおむね 2013 年時点にとどまっており、flexbox、grid、数学関数、カスタムプロパティをサポートしていない
- 認識できない CSS に遭遇すると、フォールバックや明確なエラーではなく静かにクラッシュする
epubcheck は基本的な CSS 検査を行うが、根本的に壊れた特定レンダラーに合わせて CSS を検証することはできない
Kobo 互換性検証の教訓
- 2026 年になっても Kobo が書籍レンダリングの基盤として RMSDK を使っているため、有効な CSS 1 行が有効な EPUB 全体を「corrupted file」にしてしまうことがある
- この場合、Kobo は明確なエラーメッセージやフォールバックなしに本全体を開けなくなる
- 問題を避けるため新しいバージョンが配布され、読者が同じエラーを再び経験しないよう対策が取られた
- 理想的には RMSDK が CSS の旧式な状態から脱却するか、少なくともエラー処理を提供すべきだが、現時点では問題はそのまま残っている
- Kobo 互換性を確実にするには**
epubcheck だけでは不十分**で、Adobe Digital Editions で実際に読み込めるか確認する必要がある
- EPUB は電子書籍のための優れたオープン標準だが、多くの実装はアクセス制限を優先する構造の中で根本的な欠陥を露呈している
1件のコメント
Hacker Newsのコメント
Adobeも昔からずっとこんな調子だった。Flashの莫大な市場シェアを自ら吹き飛ばしたが、代替策はQAに数百万ドルかければ済む話で、その結果すべてのブラウザメーカーが「こんな信頼できないパートナー抜きでWebを進めたほうがいい」という結論で一致することになった
昔Flashでいくつか出したことがあるが、ランダムクラッシュや、ある領域の変更が別モジュールの無関係な機能を壊すようなハイゼンバグだらけのひどいソフトウェアだった。価格は800ドル前後だったのにサポートは実質なく、最小テストケースまで付けて簡単に再現できるバグをいくつも報告したが、次のリリース後に「直っているかもしれないので定価のライセンスを買って確認してほしい」という自動返信を受け取っただけだった
MusicWorksもあって、どちらもかなり初期のMac専用だった。こんな話をすると年がばれる
JavaScriptビルドシステムの幾重にも積み重なった構造と「Web標準」は、ただ何かを描いて少し簡単な関数を書き、それをどこにでも埋め込める、あるいはダウンロードできる静的ファイルにすることより、はるかに難しい。Flashの代替を使おうとすると設定に時間を取られすぎるし、その「標準」自体ももっとひどい
Flashを殺したSteve Jobsも嫌いだし、Webでもっとも驚異的な技術の一つをお粗末に管理したAdobeも嫌いだ。今育っている子どもたちは、Flashがどれほど魔法のようだったか知らない。Web版のRobloxやMinecraftのような存在だった
Webサイトは今でも2000年代初頭のFlash以下だ。数十年たってもその力の一部を真似しているだけで、使いやすさにはまったく及ばない
電子書籍リーダーソフトウェアをかなり長く作ろうとして、結局悪魔と取引するつもりでRMSDKの上に載せようとした
ところが、そもそもアクセスする手段がまったくない。独立開発者にはライセンス料が高すぎるという意味ではなく、もちろんそれもあるのだが、話をする相手自体がいない。Webサイトに書かれたメールアドレスは何の返答もなく、「興味を持ってくれてありがとう」とか「追って連絡する」といった一言すらない
以前そこで働いていた同僚にRMSDKへのアクセス手順を尋ねたところ、社内文書を探してみたが何も見つからなかったと言っていた。LinkedInでRMSDKに関係ありそうな人を探して聞いてみても同じだった
一方で出版社は、ほとんどの本をApple、Amazon、Adobeのような既知のDRMベンダーのいずれかを通してしか配信しておらず、前の二つは完全に閉じている。これが反競争的な独占行為でないなら何なのかわからない
私の知る限り、Koboデバイスはファイル名を
.kepub.epubにすると、より高度なレンダリングエンジンを使う。ePub 3ベースだと思うが、ここでの問題を直すかどうかはわからない個人的には、Koboに移す前にePubをkepubify(https://pgaskin.net/kepubify/try/)で変換している
https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
Kobo Clara Colourが本当に気に入っていて、Adobeリーダーさえ外せれば完璧だと思う。KOReaderも使ってみたが、OverDriveの図書館本とKobo Storeが好きなので完全には乗り換えなかった
残念ながら、epubとepubcheckは筆者の言うような、議論の余地のない立派な基準ではない。W3C, Inc.がePub 3.1あたりで仕様管理を引き継いだ際、WHATWG HTMLや肥大化し続けるブラウザ仕様群をそのまま参照した([1])
こうした「生きた標準」にはバージョン管理もQAもない。その結果、ヘッダーとセクショニングを再定義したHTMLバージョンを前提にしたことで、ePub 3.2は既存のePubを非準拠にしてしまった。だからCalibreや他のツールはいまだに3.1、もっと言えば2を勧めるのだ
CSS
min()関数が拒否される件も、複雑すぎるCSS仕様を丸ごと持ち込んでもあまり役に立たないことを示している。電子書籍リーダーは常に最新状態に更新されるブラウザではないからだ[1]: https://news.ycombinator.com/item?id=41326179
EPUBの互換性問題では、常にCSSを真っ先に疑うべきだ。「モダンな」CSS機能を使っておいて、flexboxやgridがないと不満を言うのはWeb開発者の発想だ
EPUBがWebとスタックの一部を共有しているからといって、両者が完全に重なるという意味ではないし、そうある必要もない。電子ペーパーの内蔵リーダー機器の大半はレンダリングにブラウザを使わず、用途特化のHTML/CSSパース・レンダリングツールチェーンをファームウェアに焼き込んで、ごくたまにしか更新しない。興味があればKOReaderのcrengineやESP32で動くCrosspoint readerを見るといい
そのブログ記事は自信過剰なAI文体の匂いがするが、だまされてはいけない
デバイスを探している人向けなら PineNote もある
https://pine64.org/devices/pinenote/
価格は高めで、すぐに使えるソフトウェアは少ないが、デバイスの所有権や、どのソフトウェアを実行できるかという点では、はるかに率直で制約も少ない
PineNote の使用感をうまくまとめた記事もある
https://shom.dev/posts/20250308_pinenote-day-one/
https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...
Kobo も、できることを制限しているわけではない。KOReader のような代替電子書籍リーダーソフトをサイドロードして、内蔵リーダー機能を改善できる
Kobo は実際に電子書籍リーダーソフトウェアを完全に書き直している最中で、EU ではベータ版をダウンロードできる。ほぼ確実にもう RMSDK ベース ではない
Adobe は管理者としてお粗末で、その後の移行も台無しにし、最終的にはエンドユーザーとプラットフォームをさらに苛立たせる第三者に売り渡すことで、EPUB DRM 市場を LCP に丸ごと差し出したようなものだ。プラットフォーム各社はこれまで以上の速さで Adobe から離れつつある
「何か月も作業して仕上げた本で、検証ボタンを押す瞬間が怖かった。いつも何かしら文句をつける点を見つけてきたからだ」というくだりを見て、LaTeX の論文ドラフト をコンパイルしようとして泣きそうになっていた修士学生を思い出した
「とにかく書いて、書式は後で考えろ」という言葉をあまりに文字どおりに受け取って、締め切り直前になって初めてコンパイルを試していた
迫る締め切りがその体感にどう影響したかは分からないが ;-P
読者がそもそも
max-widthのようなものをサポートするか、少なくとも無視してくれる ePub リーダー を使っているなら、それだけで幸運だと思うべきだ :-P個人的には ePub リーダーを使っていて、不要なスタイルのせいで動かなかったり変に表示されたりするファイルを、ときどき自分で修正しなければならなかった。こちらでは問題なかったファイルが、他の人には読めなかったという話も聞いたことがあり、本当に必要な凝った書式でない限り、IE4 でも大きくは崩れない程度のごく基本的な HTML にとどめておくほうがよいと思う
だから、いつか ePub を最もシンプルな HTML/CSS に再構成してくれる epub reconstruct ツールを作ろうかと思うことがある。理想的には、最大限の互換性のために設定可能であるべきだ
どのコンピューターでも高速に動くサブセットを決めて、自分が作るウェブページではそれだけを使ったらどうかとよく考えていた。ePub でも誰かがそういう範囲を整理してくれれば、ずっと有用になるはずだ
Adobe Digital Editions と RMSDK は最近 Wipro Engineering に売却された: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
筆者のもどかしさは理解できるが、古くてアップグレードされていない、あるいはアップグレードできない ePub リーダーを使っている読者がどれほどいるだろうか。著者がすべての読者に作品を届けたいなら、最小公約数 に合わせるしかない
それが 2013 年の何かだとしたら残念だが、それが市場の現実だ