EPUB3の仕様が2011年10月に確定してから3ヶ月ほど経過して、作成ツールやEPUB3リーダーなどがちらほらと現れてきています。ちなみにEPUB3ビューアーについては、以下にすこしまとめた一覧がありますので、参考までに。
・ブラウザ・ビュアー – epubcafé
しかし、あえて今回はEPUB3ではなく、HTML5電子書籍について、2回にわけて書いてみたいと思います。
と・・・いいつつも、まずはEPUBの話から始めます。
目次
1. EPUB3でインタラクティブな電子書籍
EPUB2ではJavaScript自体を「実行するべきではない」とされていましたが、EPUB3になって、JavaScriptの利用が可能になりました。これによって動的でインタラクティブな電子書籍が作成できるようになります。
2.4 Scripted Content Documents
EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML5] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification and its sibling specifications as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of HTML5 forms.
from EPUB Content Documents 3.0
ただし、EPUBは様々なデバイスで読まれることが想定されています。例えば、デスクトップのような、何でもできてしまうデバイスから、iPadのようなタブレット型PC、サイズの小さいスマートフォン、そして、E Inkのような電子ペーパー端末まであります。特に動画に強い液晶と異なり、動的なコンテンツに弱い電子ペーパー端末はインタラクティブなコンテンツに向いているとはあまり言えません。また、全てのEPUBビュアがJavaScriptに対応しているわけではないのです。
そもそも・・・
EPUB3の仕様ではEPUBビュアーのJavaScriptのサポートはオプション。
なのです。
ですので、仕様の上でもすべてのEPUB3ビュアーがJavaScriptに対応するとは限らないのです。
JavaScriptによる動的でインタラクティブなコンテンツの作成する場合でも、JavaScriptに対応していないビュアーでもそのコンテンツが読める範囲内で使用しなくてはなりません。JavaScriptが使用できないとコンテンツが全く読めないとか、コンテンツとして意味をなさないといったものはEPUB3の仕様上認められておりません。
で、ここからが、ようやくこのエントリの本題です。
そういうわけで(かどうかはわかりませんが)、より自由に作りたいという動機からEPUBではなく、HTML5で電子書籍を作ってしまおうという動きがちらほらと米国を中心に見られるようになりました。
この動きを大きく分けると以下の2つの動きに分けられると思います。
- HTML5で作成したコンテンツをアプリケーションとしてパッケージ化
- Webサイトの電子書籍化 -Webサイトとの境界線が曖昧化するパッケージメディア-
このエントリでは1のHTML5で作成したコンテンツのパッケージ化された電子書籍を紹介します。2のWebサイト化の話は次のエントリで紹介しようと思っております。
2. パッケージ化されたHTML5電子書籍
HTML5コンテンツはHTML5+CSS3+JavaScriptで構成されます。もう少し具体的に言えば、Webサイトなどで公開されているHTMLで作られたコンテンツもhtmlファイル、css、JavaScriptで構成されるファイル群です。これらを全て1つのフォルダに入れることでコンテンツとしては一応成立します。
とはいえ・・、例えば、以下のような構成のコンテンツがあったとして、読者にはその中にあるindex.htmlファイルからアクセスしてもらって・・・となるわけです。
これは厳しい・・。少なくとも私は気分が萎える・・・
読者が必要のないファイルをうっかり開いてしまう可能性も高く、コンテンツのソースを変更してしまって読めなくなってしまう可能性も低くありません。そもそもこの状態では権利保護のへったくれもありません(あ、でも、不可能ではないのか。)。
そういうわけですので、コンテンツを配布するにはやはり以下にように1つのファイルとしてに固める必要があります。
1つのファイルとして固める。
読者にはファイルの中身を意識させない・いじらせない。
EPUBやKindle形式のようなフォーマットも、おおざっぱな見方をすれば上のようにhtmlファイルなどを固めたパッケージ用フォーマットとして見ることができます。
EPUBやKindle形式のようなフォーマットとして固めるのではなく、HTML5として固める方法として、以下の2つを少し詳しく紹介します。
- ネイティブアプリ化
- ウィジェット化
2.1. ネイティブアプリ化
電子書籍をネイティブアプリ化することでパッケージ化する。つまりはアプリ版の電子書籍をHTML5で作るということです。iOSやAndroidのApp Store経由で流す場合はそれぞれのOSにアプリケーションとしてインストールすることになります。
ビュアーアプリを必要とせずに、単体でコンテンツを読むことができます。コンテンツと一緒にそれを読むためのビュアーアプリも一緒にバンドルされているというイメージになります(正確にはそのデバイスのもつレンダリングエンジンを使用すると思われるので、すべてがバンドルされているわけではない)。
しかし、ネイティブアプリを作成する場合、たとえば、スマートフォンやタブレットPC向けに作成しようとすると
- iOS: Objective-C
- Android: Java
- Windows Phone: C#/VB
という感じでプラットフォームごとに別々の言語を使用しなくてはなりません。
ちょっとそれはやってられない・・・という方のためにPhoneGapというフレームワークがあります。
PhoneGap
HTML+CSS+JavaScriptで開発したアプリケーションをネイティブアプリケーション化するフレームワークです。ネイティブアプリ化させることができるだけではなく、様々なプラットフォームに対応させることが可能になります。現時点ではWebアプリではアクセスができないデバイスのネイティブな機能にアクセスするAPIも多く提供していますので、カメラをつかったインタラクティブな電子書籍などもつくることができるようになります。
Supported Features « PhoneGap
また、これはiOS専用ですが、Bakerという電子雑誌用のフレームワークもあります。
Baker
Baker Ebook Framework 3.1
・HTML5ベースを使った電子書籍フレームワーク「Baker」 – MOONGIFT
簡単にいうと、Xcodeのプロジェクトです。コンテンツをいれるbookディレクトリ以外はすでに用意されているので、このbookにコンテンツファイルであるhtmlファイルやcssなどをいれてやり、コンパイルすればそれだけでできる。
<img src=”https://code.kzakza.com/wp-content/uploads/2012/01/baker1-e1326375184227.png” alt=”XcodeでBakersを展開している図” title=”baker” width=”450″ height=”442″ class=”shadow” size-full wp-image-1331″ />
上のBakerをさらに利用したLakerというフレームワークもあります。より動的でインタラクティブなものがつくれるようになっているのでしょうか。デスクトップ用ブラウザでも見られるコンテンツの作成も実験的にサポートしているようです。
Laker
Laker
・jQueryやHTML5を使ってiPhoneやiPad向け電子書籍を作成する為のフレームワーク・Laker – かちびと. net
電子書籍をネイティブアプリとして作成するメリットとデメリットは以下になるかと思います。
メリット
・1つのファイルとしてパッケージ化できる。
・iOSやAndroidのApp Storeなどのプラットフォームにコンテンツを配信し、有料化することができる。
・PhoneGap等のフレームワークを使用すれば、ハードウェアの機能にアクセスすることができる。
デメリット
・ネイテイブアプリなので読者に「インストール」という「読書」にあまりふさわしくない行為をさせてしまうことになる。
・プラットフォーマーの意向に左右されやすい。
・プラットフォーマーに支払う手数料のコスト
・永続性の問題(プラットフォームのOSのバージョンアップをいつまでもサポートできるのか)
既存のプラットフォームに乗せて課金ができる、コンテンツを有償で配信できるというのは、コンテンツプロバイダにとってなによりの利点かもしれません。デメリットのプラットフォーマーの意向に左右されやすいというのは、その利点の裏返しとも言えます。パッケージはしたいけど、プラットフォーマーの意向には左右されてたくないぞぉという人にとってはウィジェット化という選択肢もあります。
2.2. Webウィジェット
ウィジェットはアプリ化と同じでHTML5+CSS+JavaScriptを一つのアプリケーションとして固めたものです。W3Cでかなり検討が進んでおり、ほぼ固まったと言える状態です。
・Widget Packaging and XML Configuration(勧告)
・Widget Interface(勧告候補)
・XML Digital Signatures for Widgets(勧告案)
これらの仕様の詳細については以下のIBMの解説が詳しいのでこちらをご覧ください。
・W3C ウィジェットの構成とパッケージ化
現在、どのブラウザがWeb Wedgetに対応しているかは私が調べた範囲ではよくわかりませんでしたが、Operaは対応しているようです。あと、iOSアプリのCloudReadersもWidgetをサポートしているらしいです。
・Opera: Widget packaging and configuration support in Opera Presto 2.7
ただし、上で紹介したIBMの解説でも紹介されていますが、HTML+CSS+JavaScriptをパッケージ化するウィジェットがすでに複数のプラットフォーマーから提供されており、W3CのWeb Wedgetで一本化とはなかなかすぐにはいかないのではないかと思われます。
2.3. その他
その他、以下のようなフォーマットも存在します。ブラウザが主にサイトを一纏めにして保存する際の使用されるようです。
- MHTML形式(Firefoxはプラグインが必要になるが、他の主要なブラウザでは読むだけなら対応しているらしい。)
- webarchive形式 (Safari)
WARC(Web ARChive) は違いますよね・・。
ウィジェットが選択肢になるのは、もう少し先になるのかなと思います。ただし、プラットフォーマーに左右されずにパッケージ化できるという点では非常に魅力的な方法であると思われます。一本化されるのがW3Cの仕様かどうかは分かりませんが、いずれはまとまるのではないかと思います。そうあって欲しいですね。
プラットフォーマーの意向に左右されたくない。しかし、Wedgetが使用できるのはまだ先かというところで、いっそWebサイトに移行してしまおうという動きも見られるようになっています。これについては、また次のエントリで紹介します。
※2012/01/11訂正
当初、このエントリはパッケージ化の手段としてネイティブアプリ化のみを紹介しておりましたが、W3C Webウィジェットの仕様やMHTMLなどについて、HTML5コミュニティ、EPUBコミュニティ、Twitter上でお教えいただきました(ありがとうございます!)ので、構成を変更してWebウィジェットなどの紹介も追加いたしました。
※2012/01/12訂正
Objective-Cを使わずともHTML+CSS+JSだけでXcodeを使ってiOSのネイティブアプリが作れるかもと書いていましたが、HTML+CSS+JSだけではできないと神崎渉瑠さんよりコメントにてご指摘を頂きましたので、「ネイティブアプリ化」の項を修正・加筆書しました。。そもそもiOS SDKも必要ではないか(ツッコミ)。その件をご指摘くださった神崎渉瑠さんのコメントも合わせてお読みいただけると幸いです。
メーリングリストで書いてないことに関して。
HTMLも、CSSやJavaScriptはオプションですよ。
CSSやJavaScriptを全くサポートしないブラウザもたくさんあります。
XCodeによるHTMLビューワーのネイティブアプリ化は、HTMLビューワーを設定するためのコードをObjective-Cで書く必要があります。
もちろんC#やJava、tcl/tk、c++を使えば、
Windows、Linux/X-Windowアプリ、携帯電話アプリ(iアプリ、ezアプリ、softbankアプリ)なども作れます。
PhonegapやTitaniumを使用すると、その部分を、Phonegap/Titaniumが肩代わりしてくれるというものです。
ヴィジェットではなくウィジェットです。
ウィジェットは、
Operaウィジェットを始め、Mac Dashboard、Windowsサイドバー、Yahoo!ウィジェットなどが有名です。
W3Cのは、それら固有の機能を一般化、標準化したものだと思います。
ビデオフォーマットも、Windows Mediaplayer、Realplayer、Quicktime movieなど、たくさんあります。
いろんな人に見てもらうために全種類用意すれば良い、というのが、ウェブ/HTMLの考え方でした。
(今はflv1つでまかなえるため、flvしか作らない人が多いと思います。)
同じように、
ウィジェットも、それぞれのウィジェットエンジン用に移植すれば良いだけ、、、まあ、言葉で言うのは簡単ですけどね。
ビデオのエンコードでさえやらない人が多いのに、CSSやJavaScript、XMLファイルまで入りますから、、、
JavaからC++/C#、Linux/*BSDからWindowsへの移植より、はるかに簡単だとは思いますが。
JavaScriptもブラウザ固有機能から、ECMAScriptという標準言語仕様を作られました。
今後、そういう「多くの企業が採用した一企業のアイデア」というのが、どんどん標準化していくと思います。
その際、Microsoftが考えたAjaxやDHTMLのように、オリジナルからかけ離れた標準になったりすると、混乱を招くことになると思いますし、
互換性のある標準を目指してほしい物です。
kzakzaです。貴重なご指摘ありがとうございます(MLもありがとうございます。こちらはまた別途返信させていただきます)。
>XCodeによるHTMLビューワーのネイティブアプリ化は、HTMLビューワーを設定するためのコードをObjective-Cで書く必要があります。
完全に認識が間違っておりました。ご指摘をうけて「ネイティブアプリ」の項を修正しました。
>ヴィジェットではなくウィジェットです。
これもお恥ずかしい限りで、修正いたしました。
ウィジェットやJavaScriptについてもそうなのですが、各ブラウザ、プラットフォームが独自に用意している機能やAPIなどを標準化してWeb全体をオープンなプラットフォーム化させるという最近のW3Cの動きには非常に面白いと思いますし、そうなってほしいと思います。
オープンな標準化が進むことを私も願うばかりです。