Top > IT > EPUB > BadSideOfEPUB
Last-modified: Mon, 26 May 2014 08:27:07 JST
Counter:1791 Today:2 Yesterday:3 Online:4
このエントリーをはてなブックマークに追加

EPUB の良くないところ

EPUB の存在自体は良いものだと思いますが、良くないところも当然あります。ここでは私が EPUB のフォーマットに触れて、良くないと思った点をいくつか挙げておきます。総じて言えることは、EPUB3.0 現在では、フォーマットは未だに曖昧さを多く持っていて、十分に洗練されておらず、資料も十分ではないということです。

フォーマットに曖昧さが見られる

dc:date と dcterms:modified

刊行日を示す方法に、dc:date を利用する方法と、dcterms:modified を示す方法があります。dc:date は省略することができますが、dcterms:modified は省略することができません。厳密には異なるのかもしれませんが、この2つがどういう経緯で定められたのか良くわかりません。片方だけでも十分に機能する上、曖昧さが残ります。EPUB 3.0 の時点では、dc を利用するフォーマットが多く存在し、一方の dcterms は最小のセットでは、この modified を示すためだけに利用されます。将来的に dcterms に移行するにしても、このフォーマットの採択には疑問が残ります。

id を利用した参照

opf ファイルでは、ある要素に id を指定して、その id を基準に他の要素から id を振った要素を参照しています。しかしこの id を参照する方法が複数あって非常に分かり難い。なぜわざわざ異なるフォーマットを利用したのかが理解しがたいです。

具体的には次の通りです。metadata の設定の際は、meta 要素を追加するために、refines 属性を利用します。一方で、spine の設定の際には、idref 属性を利用しています。名称も異なれば、属性値の決定方法も異なります。このあたりは可能なら統一して欲しいものです。恐らく既存のフォーマットである Dublin Core (dc:やdcterm) での情報の埋め込み方法を採用した結果の弊害だと思うのですが、"フォーマット" でうから一貫性を求めてほしいです。

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:creator id="creator01">著者1</dc:creator>
    <meta refines="#creator01" property="role" scheme="marc:relators">aut</meta>
    …
<spine page-progression-direction="ltr">
    …
    <itemref idref="chapter01"/>

意図が不明なサンプル

公式のサンプルにも意図が不明なデータが示されていることがあります。例えば、DCMES creator element の項目です。

次のコードはそのまま引用して抜粋するものですが、このコードにおいて、 id = "role" の必要性はありません。この meta 要素が role を示すためのものであることは property 属性によって示されています。

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    …
</metadata>

これは role を示すために id 属性を定義しなければならないようなミスリードを起こします。勿論ですが、このことは他のテキストと並行して確認しています。他に公式が提示するサンプルの中に id 属性が含まれるものはないハズです。

他に

"こう書くものだ" と断定的に表記されている(特に日本語の)資料が多くありますが(Webかどうかは問わず)、www.idpf.org が示す公式のフォーマットには掲載されていないものが多々あります。伝言ゲーム式に正確ではない情報が伝わってしまっているようです。

少なくとも EPUB3.0 現在の環境で、ディレクトリ名が OEBPS で固定されている必要がある、と述べるべきではないでしょう。ディレクトリ名は META-INF を除いて自由に定義できますし、命名規則についても公式に勧告されるものはありません。 (定かではありませんが、ディレクトリ名が OEBPS でなければ動作しないリーダがあるのですか? そしてそれを示すならば具体例か、あるいはそのようなフォーマットになるに至った背景を示すべきでしょう。)

2.0 から 3.0 への移行について

EPUB のバージョン 2.0 から 3.0 への変化はとてつもなく大きいものです。基本的には様々な問題を改善する方向へ進んでいるように見えますが、変更の大きさは少し調査してもらえれば分かります。機能の追加は兎も角、多くの記述方法が変更されていることから、安定して利用できるフォーマットとは言い難いのが現状であると思います。

今後も同程度の変更が含まれる可能性があるように見えます。フォーマットの曖昧さについてはこのページでも語っていますし、IDPF が EPUB を正式なフォーマットにしたのは 2007 年です。中身こそ HTML や XML がベースとなっていますが、比較して、歴史の短さは言うまでもないでしょう。

同時に、変更を正しく理解できているユーザも多くはないようです。私も正しく理解できていない一人です。一部の熱心な開発者や啓蒙活動を行っている方は正しく変更を提示してくれています。一方で、Web で見つかる多くの記事が 2.0 と 3.0 の情報を混在させているか、あるいはそのサンプルに含まれるコードが互換性のために残されていることを明示していません。

書籍の制作者側から

互換性を残すことは重要ですが、それをするには多くの時間と労力がかかります。もしもプロフェッショナルでないのであれば、コンテンツの制作者側はリーダ側の対応に任せて新しいフォーマットにのみ対応する方が良いかもしれません。2.0 から 3.0 への変更はそれほどまでに大きなものです。リーダやオーサリングツール(EPUB を作れるソフト)の開発者には負荷が大きなままですけれども。

XHTML5 というフォーマットの存在

このページで、資料の掲載情報に誤りが含まれることがある、という話題に触れたので、関連するもう1つの話題として XHTML5 、あるいは HTML5 と EPUB3.0 の関係について触れておきます。

以下の内容を予約すると、"HTML5 を XHTML形式で書く"、というのが厳密な表記であって、"EPUB と HTML5 は互換性がある" と書くのは、正しくない情報を含んでいますよ、ということです。

多くの資料に、"EPUB は HTML5 と互換性がある"、と書いていますが、これは誤りで、厳密には互換性はありません。"親和性が高い" と表記している資料の方が親切です。EPUB は、バージョン 3.0 までの今のところは XHTML を正式なフォーマットとしていますから、HTML5 と "完全な" 互換はありません。HTML5 が、EPUB の定めるフォーマットを内包することはあるかもしれません(多分内包します)が、逆はあり得ません。

具体的には、HTML5 では画像タグ(要素)を <img> と書いても良いし、<img/> と書いても良いですが、EPUB(XHTML) では、<img/> としか書くことができません。したがって、HTML5 > EPUB(XHTML5?) は成立しても、EPUB(XHTML5?) > HTML5 は成立しません。

以下はさらに余談です。

検索すると膨大な数の情報がヒットしてしまうので、もう事実上存在することになっていますが、厳密には XHTML5 という名前のフォーマットが存在しません。呼称の都合上、便利なので、XHTML5 と呼ばれています。酷い難癖を付ければ、EPUB は XHTML5 で書く、というのも誤りで、"XHTML 形式の HTML5 で書く" というのが正しい、ということです。

HTML5 のフォーマットを掲載している W3C のページ を見ると分かりますが、ページに掲載されている要素は、HTML のものでもあり、XHTML のものでもあります。また W3C の XHTML についての言及についても以下の通り引用しておきます。

http://www.w3.org/standards/webdesign/htmlcss より引用

XHTML is a variant of HTML that uses the syntax of XML, the Extensible Markup Language. XHTML has all the same elements (for paragraphs, etc.) as the HTML variant, but the syntax is slightly different. Because XHTML is an XML application, you can use other XML tools with it (such as XSLT, a language for transforming XML content).

XHTML 形式の利点については少し検索して調べれば見つかるのでここでは言及しませんが、単純に、XML 形式のデータを利用できるという点と、より厳密なルールに従わせることによって、そのデータを描画する各システム間の誤差を少なくしよう、ということでしょう。(詳細は私にもよく分かりません。)

XHTML5 という呼称については、ユーザ間で当たり前のように利用されていて、内容を示す適切な呼称である、ので私は利用しても良いとは思います。まぁそれにしても EPUB 3.0 の時点で単に HTML5 で良かったように思えますが。