私は、基本的にEPUBに反対である。EPUBは確実に流行らないであろうと考えている。
何故か。
EPUBとは、HTMLやCSS、Javascript、他のリソース（画像や動画など）を、あらかじめ定められた書式に従って、ZIPで固めたフォーマットである。
しかし、それなら何もZIPで固めなくてもいいではないか。普通にHTMLでマークアップして、CSSでスタイルを指定して、Javascriptでスクリプトすればいいではないか。なぜわざわざ共通のZIPの「固め方」の規格が必要になるのか。
なるほど、確かに共通の方式を決めておけば、専用デバイスなどでも読みやすくなるかもしれない。しかし、そもそも専用デバイスなどは必要ないのである。持つべきものは、汎用的なコンピューターである。専用デバイスではない。
配布用に、ひとつのファイルにまとめるのは理にかなっている。その方法にもっとも普及しているZIPを使うのも、悪くはない。さて、そのZIPファイルを、展開するとか、そのままマウントして仮想ファイルシステムとして使うとかは、読者側のやることである。わざわざ共通化するまでもない。
EPUBの問題点は、現時点で広く普及していないということである。EPUBを描画できるソフトウェアが、PCには欠けている。いまだに各ブラウザーはEPUBをネイティブにサポートしていない。最も汎用的なPCの中でも、もっともEPUBと親和性の高いブラウザーでサポートされていない現状では、EPUBは使えないフォーマットである。今、使えないフォーマットは、将来も使えないフォーマットである。技術の世界においては、今使える技術こそが優れているのだ。一年後に使えると宣伝されている技術などは、無価値も同然である。その点では、FlashやPDFにも劣るのである。
もちろん、単にZIPを展開して、内部のファイルを取り出して使うことはできない。EPUBのファイル構造は、展開したものを簡単にブラウザー上でみることができるように構成されてはいない。手動で簡単に編集できない。専用のビューワーが必要なのである。したがって、現行のブラウザーではまともに閲覧することが出来ない。
さて、HTML自体は、インターネットのHTTPプロトコルで、標準のマークアップ言語として、長らく使われてきた。HTMLには、いまだに様々な問題があるものの、広く使われている実績がある。新しいマークアップ言語を設計しようという声は、あまり聞こえない。あるのは、HTMLを、下位互換性をなるべく保ったまま改良しようという意見だけである。したがって、HTMLは電子書籍を記述するのに十分な力を備えていると言える。
HTMLを直接使えばいいのだ。そのようにすれば、専用リーダーは、機能の極端に制限されたものではなく、汎用的なコンピューターにならざるを得ない。これは将来に良い影響を与える。消費者の利益を考えれば、リーダーは汎用的なコンピューターになるべきである。iPadやAmazon Kindleのように、不当に機能を制限されたオモチャに成り下がってはならない。自由を求める我々は、そのようなオモチャに魂を売ってはならない。
現行のCSS3のwriting-modeのドラフト化には、EPUBの規格団体、IDPFによる努力もあっただろう。それは、オープンな規格の受ける恩恵である。EPUBが優れているかどうかは、別の問題である。
追記：コメントに対して
しおり、HTML、CSSなどは、クライアント側で解釈されるものである。標準規格があること自体は望ましいが、クライアント側の解釈を強制させることはできない。
たとえば、あるクライアントは、HTMLに対してある種の変換を行うかもしれないし、また、CSSによるスタイル指定を無視して、ユーザー側にとってより閲覧しやすいスタイルを適用するかもしれない。
どのようにコンテンツを再生するかは、クライアント側の自由である。
もし、HTMLやCSSが、標準団体によって規格準拠を認証された再生装置によってしか再生できないなどと規定していたら、今日の興隆はなかったであろう。
電子署名や暗号化などのいわゆるDRMに関しては、技術的に不可能なことを可能だと見せかけているに過ぎない。第一、名前が誤解を招いている。偽装化とか難読化とか、「コピー防止お願いのフラグ」などという名前に改めるべきである。クライアント側で復号できる以上、改変も再配布も技術的に可能である。クライアントがそれをしないのは、単にクライアントの実装者が規格を準拠して、コピー防止お願いのフラグを尊重するという、いわゆる紳士協定を結んでいるからに過ぎないのだ。
それに、私的利用の範囲内における複製や翻案は、著作権の及ばないところである。EPUBをサポートしていない環境のために、EPUBを別のフォーマットに変換する。これは私的利用の範囲であって、著作権の及ばないところである。
永遠にサポートされる技術などというものはありえない。たとえば将来、HTMLがもはや古臭いフォーマットとして誰からも顧みられることがなくなり、HTTPプロトコルも忘れ去られ、そもそもインターネット自体が絶滅している日がやってくるかもしれない。もちろん、その時には、現代では想像もできないぐらい優れた代わりの技術が使われているのである。今あるコンテンツは、すべてより優れた媒体、フォーマットに変換をしなければならない。
ゆえに、私的利用の範囲における複製や翻案が重要なのだ。
もしこれができないのだとしたら、その規格は消費者の権利を不当に制限しており、また将来的にコンテンツは閲覧できなくなるであろう。そのような規格で配布されるコンテンツはボイコットするべきである。
従来の紙の本にはない制限を、何でわざわざ付け加えるのか。
そもそも人類の記録媒体の歴史を省みるに、石に刻み、木簡や竹簡、羊の皮や木の繊維から作られた紙、そして電磁的記録媒体となった。後の世の事など誰が知っているというのか。
本としての流通のためのメタデータを考えたら、また暗号化・電子署名を考えたら、パッケージフォーマットが必要になる。ZIPでまとめるだけでは駄目なのだ。別にEPUBだけじゃなくて、ODF, OOXML, Widget Package, JARとZIPの上に作られたパッケージフォーマットの前例は多々ある。
ReplyDelete暗号化や電子署名が何で必要になるのですか。
ReplyDelete読者の利便性を妨げるだけではないですか。
紙の本にはそんなものはないのです。
EPUBは単にHTML/CSSのZipパッケージだけではありません。そのあたり少し認識が不足されたご意見ではないかと思います。
ReplyDeleteEPUBはXML/HTML/CSSの上に本というアプリケーションのための言語を定義しているというか。出版社情報とかタイトルとか表紙とか目次とか栞とか非常に多岐にわたっています。EPUBリーダーは単にWebブラウザ＋Zip解凍じゃだめなんです。
そのあたりをもしご存じなければ調べられることをおすすめします。現状では日本語の資料はほとんどありませんけれど。（流行しないというご意見は変わらないかもしれませんけれど、誤解に基づく情報は直された方がいいように思います）
出版社情報やタイトルなどのメタデータの書式は、統一されていると便利でしょう。
ReplyDeleteただし、表紙や目次はHTMLで作成できますし、目次はJavascriptを使って、heading要素などから自動生成することもできます。
しおりはビューワー側の機能でしょう。
しおりはもちろんビューワー側の機能ですが、それはしおりに限ったことではなく、EPUBの仕様とは「EPUBビューアはEPUBをどう解釈してどう動くべきか」というビューワー開発者のための情報なのです。
ReplyDeleteついでにいえばHTMLやCSSといった多くのWeb標準も、ビューワー（HTML/CSSの場合はいわゆるWebブラウザ）はそれをどう解釈してどうすべきかを定めたブラウザ開発者のための情報として書かれています（最近はコンテンツオーサーのための情報を付加する例もでてきましたが）。
こうした仕様の原則をご理解いただくのは、仕様への正しい見方を築くうえで大事なことかと思います。
目次に関しても付言すると「HTMLで目次っぽく表示され、リンクで飛べばそれでいいだろう」というご意見だと思うのですが、EPUBでは構造化文書として「これは論理的に目次として定義されている」というのが大事なことだというコンセプトになっていると思います。
もちろん「本なんて文字が並んでて読めればいいよ」というのであれば、PDFでも全然問題ないのですが、見かけ上の紙をシミュレートするPDFと、論理構造化した文書にCSSでスタイルを与えるEPUBとではコンセプトが違う、という理解は大事なポイントだと思います（そんな論理構造なんかいらないよ、PDFみたいに読めればいいよ、というご意見なのだと思いますが）。
電子署名がないと改変して再配布し放題になりますが、それでもいいですか？電子署名は読者の利便性は損ないません。暗号化（DRM)についてないほうがいいという意見はわかりますが、今の時点でそれが出来ない仕様が受け入れられるとは思いません。
ReplyDelete「表紙や目次はHTMLで作成できます」とのことですが、EPUB3 Content Documentsでどう表紙・目次を扱っているか見てみてください。HTMLでやるための統一的なやり方を定めているにすぎません。
パッケージフォーマットは多々あるのになぜEPUBだけは駄目なのかという根拠を示していただけると、より建設的な議論になると思います。