PDF には改行機能がない。SVG に似た描画形式に近く、より硬直的なので、テキストのリフローのようなことはできない
電子書籍形式に必要なのは、レンダリングされる機器に合わせて適応するセマンティックなマークアップだ。HTML+CSS はもともとその目的のために作られた
したがって本のレイアウト制作者は、本がどう見えるかに対する制御の一部を意識的に読者へ渡す必要がある。多少の視覚的な不完全さは、その代償として受け入れる価値がある。視覚的な完全性が必要なら PDF を使えばよい
もちろんインタラクティブ要素が入ると難しくなる。大きなインタラクティブ要素は必要なときに専用ビューで開き、小さなインタラクティブ要素はリフローを受け入れる形がよさそうだ
SingleFileのことを言っているのだと思う
その話で言うと、Firefoxアドオンの権限体系は変だ。面白いことをするにはほぼすべての権限を要求することになっていて、その結果、悪意ある行為者が買収するアドオンを物色する自然な市場が生まれている
たとえば SingleFile アドオンは、レンダリング済みDOMを覗いてファイルに保存する必要があるので、アクセス権限が必要なのは確かだ。だが、なぜすべてにアクセスしなければならないのかと思う。snapshot DOM once、write to a single file のような権限だけを与えることはできないのだろうか
1件のコメント
Hacker News の意見
電子書籍、セキュリティ、LowJS Webの交差点に強い関心があるので、この話題は重要に感じる
単一ファイルで持ち運べる電子書籍形式は必要だが、PDF はテキストのリフローができないため答えではない
2024年の HTML+CSS は、ほぼあらゆる印刷媒体を再現しつつ、テキストのリフローも可能にする
JavaScript が必須であるべきだとは思わない。電子書籍はサイズを意味のある形で変更できる本であるべきで、JavaScript をオフにしても本としての基本機能は動作すべきだ。インタラクションや補強が必要なら JavaScript を使ってもよいが、JavaScript なしでは本として機能しないならバグだと思う
スタイルをすべてインラインに入れるのは、一部ユーザーの CSP を壊す可能性があるので誤りだと思う。HTML 基準の相対パスリソースとしてスタイルを分離し、電子書籍は別ドメインのリソース読み込みを禁止すべきだ
最後に、単に zip ファイルとして配布すればよい。電子書籍はすでにそういう仕組みで動いているのではないかと思う
ただし逆方向は必ずしも成り立たない。同じファイルの束が展開前には有効な EPUB だったとしても、適当に再度 zip にまとめると有効な EPUB ではなくなることがある
EPUB zip 内の mimetype ファイルは特別で、アーカイブの最初の項目でなければならず、内容は
application/epub+zipだけで、非圧縮の状態で保存されていなければならない意外に多くの zip ツールは、ファイル順を変えたり、一部のファイルだけを無圧縮で保存するのを難しくしたりして、これを面倒にしている。コマンドラインの zip プログラムなら普通はフラグで可能だが、zip ライブラリではかなりつらい。EPUB 生成ソフトウェアを作った経験からの話だ
説明されているのは、HTML、CSS、画像ファイルが zip アーカイブに入る ePub 形式だ
安全にするための CSP も含まれている
以前の .doc ファイルが .docx より使いやすかった点は、数百〜数千個のファイルがあるフォルダで特定の単語を非常に高速に検索できたことだ。zip 形式ではそれができない
さきほど .doc として保存してヘックスエディタで開いてみたところ、実際の内容が平文で入っていた。zip 形式や PDF ファイルは grep で検索しにくく、数千文字程度のテキストに圧縮が本当に必要なのかも疑わしい
Nota の開発者が書いた、EPUB 形式を PDF と同等の水準に引き上げようとする非常によく構成された記事。すでにビューアも作っており、記事自体もそのビューアのブラウザベースの WASM ポートで表示されている
問題の一つは、実質的に XHTML である EPUB がレイアウトをどれだけ正確に再現できるかだ。元記事の基準は文書が「それらしく」見えることだが、PDF に匹敵するには、少なくとも改行まわりで HTML に新しいレイアウト機能が必要だというニュアンスがある
前進する方法は二つあるように見える。一つはブラウザがより多くのタイポグラフィツールを提供することで、
text-wrap: prettyが役立つと言われているが、少し試した限りでは改行品質が良くなるようには見えなかった。もう一つは改行を事前計算することだが、これは固定レイアウトレンダリングでしか可能ではないまた著者は注釈に触れているものの、どう実装しようとしているのかはよく分からない
これは EPUB3 でもすでに可能だが、スマートフォンのような画面では見やすくないという欠点がある。リーダーによってはデフォルト値を上書きできるが、そうするとリーダーが文書を見やすく作り直してくれることを期待しなければならない
代替案は、EPUB が一般的な画面タイプごとに複数のレンダリングを指定することだ。完璧ではなくても、文書制作者がデフォルトを用意し、ユーザーが望めば上書きできるようにするのは良い妥協案に見える
電子書籍形式に必要なのは、レンダリングされる機器に合わせて適応するセマンティックなマークアップだ。HTML+CSS はもともとその目的のために作られた
したがって本のレイアウト制作者は、本がどう見えるかに対する制御の一部を意識的に読者へ渡す必要がある。多少の視覚的な不完全さは、その代償として受け入れる価値がある。視覚的な完全性が必要なら PDF を使えばよい
もちろんインタラクティブ要素が入ると難しくなる。大きなインタラクティブ要素は必要なときに専用ビューで開き、小さなインタラクティブ要素はリフローを受け入れる形がよさそうだ
注釈と参照はすでに EPUB 仕様、もしかすると HTML 仕様にも入っているのではないかと思う
また、ポップアップのために長押しする方式が一般的なハイパーリンクアンカーより優れているという点には同意しない。リーダーの「戻る」機能がきちんと動作するか、双方向参照に「戻る」リンクがあれば、移動する方式のほうがはるかに邪魔にならない
XML 文書と XSL スタイルシートを一緒に配布し、レンダリング用の FO に変換し、同じ文書について対象デバイスやページサイズごとに複数のスタイルシートを用意できる、というアイデアだった
Firefoxで SinglePageアドオンを使って、現在のページDOMをスタンドアロンのHTMLファイルとして保存している。CSSと画像用の
data:URLをインラインに埋め込み、依存関係とスクリプトは削除する方式だ完璧ではないし、ブラウザが常に後方互換性を維持してくれるとも信じていないが、ページをPDFや複数ファイルとして保存するよりは好みだ
興味深いことに、このアドオンが失敗した数少ないページの一つが、まさにポータブルEPUBに関するこの記事だった。体裁を整えるために魔法をかけすぎているようだ。保存されたページは読めはするが、スタイルは元のものとはまったく違っていた
Androidのfbreaderが、すべての本をEPUBファイルのスタイルではなくアプリ設定どおりに同じ表示にしてくれる点が気に入っている。CSSを適用したり、ファイルに含まれるスクリプトを実行しようとするのを見たことはないし、今後もそうならないことを願う。外部依存関係をロードするのはさらに悪い考えで、そもそも許可されていることすら知らなかった
その話で言うと、Firefoxアドオンの権限体系は変だ。面白いことをするにはほぼすべての権限を要求することになっていて、その結果、悪意ある行為者が買収するアドオンを物色する自然な市場が生まれている
たとえば SingleFile アドオンは、レンダリング済みDOMを覗いてファイルに保存する必要があるので、アクセス権限が必要なのは確かだ。だが、なぜすべてにアクセスしなければならないのかと思う。
snapshot DOM once、write to a single fileのような権限だけを与えることはできないのだろうか当時は理由をうまく説明も理解もできなかっただろうが、ありえない願望のように扱われた。今見ると、単に10年ほど時代とずれていただけだったようでうれしい
KOReaderはあまり親切ではないが、より多くの制御を提供する。用意されている複数のCSSファイルから特定のものを選ぶことも、自分で書くこともできる
KOReaderの利点としては、優れた OPDSサポート と、簡単にセルフホストできる同期サーバーもある
この機能があれば、このシステムを使うページではSinglePageは不要になる
その部分を見て、もう一度見直した。「したがって、より軽量なEPUB読書システムであるBeneを作ることにした。今みなさんが使っているのがそれだ。この文書はEPUBであり、右上のボタンを押せばダウンロードできる」という部分だ
デスクトップブラウザで読んでいるときは、直接教えられるまでまったく気づかなかった。モバイルではヘッダーが画面をより多く占めるので目立つが、それ以外はほとんど普通のウェブページのように動作する
おそらく良い兆候だ
一部のコメントで言われているのとは違い、文書を最初にロードするときにスピナーを見た、あるいは少なくとも気づいた覚えはない。スマートフォンでは見えたが、かなりすぐに過ぎ去った。それがWASMプログラムのロードなのか、初回ロード時だけに起きるのかはわからない
通常のウェブページやPDFと違って、すべてのアセット、つまりePub全体がダウンロードされるまでレンダリングが始まらないように見える
記事で扱うと思っていたが扱われていなかった違いは性能だ。PDFはページ同士がかなり独立するように最適化できるため、段階的レンダリング、ランダムアクセス、高度な並列化が可能だ
ブラウザがEPUBを開けないという理由だけでも、やや失敗が予定されたプロジェクトのように感じる。PDFはリンクすれば多少のコンテキスト切り替えはあっても、ブラウザが開いて表示してくれる。
EPUBは説明どおりなら実質的にHTMLなのに、ブラウザが開かないのは奇妙だが、Chrome/Mozillaの官僚たちを説得するのは簡単ではなさそうだ。
もう一つ気が滅入る点は、HTMLとCSSがあまりにも巨大で肥大化してしまい、EPUB/HTML用の「リーダー」を実装できる人がほとんどいないことだ。実質的に「新しいブラウザを実装せよ」になってしまう。DjotのようなパースしやすいMarkdownに、レンダリング機能を少し載せる方式のほうが、長期的には可能性がありそうに見える。
個人的な当座の妥協案は、CSS、SVG、スクリプト、base64画像まで全部単一のHTMLファイルに入れることだ。EPUBに似ていて、やや肥大化して見た目もよくないが、少し気を使えば動作し、ブラウザが自然に開ける。
ただしユーザーには「このWebページはダウンロードしてオフラインで保存できるのだ」と知る方法がない。外部リソースのないHTMLであることを示す
.htmlsのような拡張子があるとよさそうだ。EPUBについても、ブラウザが同じことをできない理由はなさそうだ。すでにまさにそれを行うブラウザ拡張機能もある。EPUB形式が一般性を得るかどうかの問題だ。
その後、雑誌のようなデザインやレイアウトが「必要」になったが、それでも文書ベースだったのでかなりよかった。
その後、HTMLをアプリケーション配布プラットフォームとして無理やり押し込もうとした。現在のCSSレイアウトは、ようやく従来型のアプリケーションレイアウトエンジンにかなり近づいた。
この20年は、適切なクロスプラットフォームのアプリケーション配布方式がなかったために、かなりの部分が浪費されたと思う。Javaを除けば、だが。
この形式がどこでも再現可能に動作するには標準化される必要があり、新しいレンダリングエンジンの実装も容易でなければならない。WebViewに依存する方式は、進むべき道のようには感じない。
PDFの美点は、非常に信頼できるところにある。10年前のPDFも、今日でも昔とまったく同じようにレンダリングされる。
この取り組みが成功するには、文書の範囲を大幅に狭める必要がありそうだ。許容されるXHTMLのサブセットは非常に限定的であるべきで、どこでも同じ見た目でレンダリングされる能力を優先すべきだ。まず固定ページサイズの固定レイアウト、その次にリフロー可能な文書であるべきだ。包括的なテスト文書とレンダリング出力を含む標準も必要だ。
ブラウザ対応がないなら、サーバー側でEPUBをナビゲート可能なサイトに変換するプロキシを書き、章移動コントロールと簡単なレイアウトオプションを付けるのは、それほど難しくないだろう。
もちろん、そのようなプロキシで商用電子書籍の大半を読もうとすると、必要なDRM対応が法的に非常に問題になる可能性が高い。
考えてみると、出版社が承認するDRM EPUBのブラウザ対応は、一般のWebページ向けDRM対応と技術的には半歩の違いにすぎず、かなり恐ろしい見通しだ。
PDFは不要な複雑性を抱えたひどいレガシー形式だと思う。PDFの用途の大半は印刷と関係ないので、組版の論理もしっくりこない。
ほとんどのユースケースでは、スマートフォン、タブレット、コンピュータで読みやすいことのほうがはるかに重要だ。
著者がiBooksはスクロール表示をサポートしていないと言っていたので驚き、自分で確認してみた。macOSのiBooksはePubファイルのスクロールをサポートしていないが、iOSとiPadOSではサポートしている。Appleの非常に奇妙な判断だ。
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
技術文書がPDF以外の形式で配布されていて、読みや検索が快適だった例を見たことがない。スマートフォンでも同じだ。
読むデバイスやウィンドウサイズのような一時的な状態に応じて見た目が変わる文書は望んでいない。著者がきちんと設計したレイアウトが固定された文書が欲しい。
小さな画面やウィンドウで読むときも、単純なテキスト文書でないなら、レイアウト変更ではなく、素早いズームと移動が快適な賢いリーダーが欲しい。一部のAndroidリーダーのように、縦スクロールやPage Up/Page Downが横位置まで動かしてしまい、テキスト列を読みづらくする愚かな挙動はあってはならない。
従来のテキスト列の最大幅に関する推奨事項を守るだけでも、スマートフォンで快適に読むには十分だ。著者が過度に幅の広い列を作り、従来のタイポグラフィ規則を破るときだけ、スマートフォンでの読書が不便になる。
そのため、すべてに合う一つの標準を作ろうとするのは悪い考えのように思う。デジタル文書標準は二つあるほうがよさそうだ。一つはネットワーキングを除く完全なマルチメディアとインタラクション機能を備えた形式、もう一つはそのサブセットとして、白黒で、マルチメディアなし、インタラクションは主に文書内ハイパーリンク程度に制限された形式だ。
そして、ほぼそのような二つの形式はすでに存在する。HTML、MHTML=EML、そしてEPUBだ。
もちろん、物理的な保存と、まれなデジタル固定レイアウト文書向けの第三の形式も必要で、その役割はPDF/Aがすでにかなりうまく果たしているように見える。
複数ページのSVGも可能かもしれないが、複数ページをきちんと印刷するには、結局まずPDFにエクスポートする必要がありそうだ。Inkscapeを見て言っている。
8日前に134ポイントを獲得した「Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)」があった
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
EPUBリーダーがブラウザにない何を提供しているのか気になる。今のところ答えはただ一つ、些細なものだけに見える。.epubファイル、つまりzipファイルをディレクトリのように扱えるという点だ
EPUBリーダーとブラウザのサブセットの違いが本当にそれだけなら、最も単純で手間も少ない方法はこうだろう
既存のブラウザに、特定の条件下でzipファイルをディレクトリのように扱わせる
元記事で述べられている完全なローカルアセットを保証する、機械的に検査可能なHTMLの制約を定義する。リンクを除くすべてのURLが相対パスでなければならない、という要求だけでも十分かもしれない
この制約を満たすzipファイルを「ポータブルEPUB」と宣言する
既存のものも新しいものも、専用EPUBリーダーはすべて忘れる
完全なローカルアセットについては、すべてのオブジェクトがローカルで利用可能なフォールバックを持つことを要求してほしい。該当するフォントを取得できなければ標準フォントを使う、といった具合だ。完璧には見えなくても、フォールバックの範囲内に制限すれば妥当に動作するはずだ
まだ十分に扱われていない失敗モードが一つある。正しく動作しない画像だ。根本的に画像はリフローできないからだ。かなりの部分はSVGの使用で解決できるだろうが、本物のラスタ画像の場合はそうはいかない。結局、いくつかの解像度を提供するしかなさそうだ
関連する問題も経験したが、よい答えはまだ見ていない。解像度を認識し、十分な解像度があるときにより詳細な画像を取得するSVGだ。サブピクセルの線を描くとぼやけるが、同じ画像を拡大するとその線が役に立つ。Windowsアイコンは複数の解像度を含められ、状況に合ったものを使う方式でこの問題を認めている
著者はShriram Krishnamurthiの指導を受けるポスドク研究員だ。Shriram Krishnamurthiは**Programming Languages: Application and Interpretation(PLAI)**の著者であり、**Data-Centric Introduction to Computing(DCIC)**の著者の一人でもある
今PLAIとDCICをどちらも読んでいるが、著者たちが教育用の芸術作品に仕上げるために注いだ細やかな配慮には本当に感嘆している。あれは本物の愛情だ
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDFはフォントを埋め込めるが、実際には埋め込まずシステムフォントに依存することが多い。理由の一つは、フォントをPDFに入れるとファイルサイズが大きく増えることがあるためだ。場合によっては、単一のフォントが残りのファイル全体より大きいことすらある
PDFを生成するソフトウェアでフォント埋め込みを実装したことがあるが、安定して動作させる方法を見つけるのは意外に難しかった
PDFが一貫してレンダリングされるというのも、思っているほどではない。同じPDFが、どのPDFビューアを使うかによって異なってレンダリングされることが何度もある。たいてい違いは微妙だが、時にはかなり大きな差が出る境界ケースもある。同じバージョンのAcrobat Readerが、OSによってPDFを異なってレンダリングするケースも経験した
したがって互換性のあるシステムフォントを使えば、レンダリングされた文書レイアウトは変わらないはずだ。もちろん、古いAdobe PostScriptフォントとメトリクス互換だと宣伝しながらも微妙な差があるシステムフォントの例はある
少数の標準システムフォントを除けば、PDF文書は通常、そのフォント全体ではなく、実際のテキストで使われた文字に対応するグリフのサブセットだけを含む
日常の中のThe Daily WTFだった