3月 04

オライリー提唱の執筆・制作用フォーマットHTMLBook仕様案の日本語訳

公益社団法人日本印刷技術協会(JAGAT)XMLパブリッシング研究会が米国の出版社O’Reilly Mediaが提唱するHTMLBookフォーマットの仕様案及びHTMLBookの紹介ページの日本語訳を公開しています。

 HTMLBookはオープンで、XHTML5ベースでプリントとデジタル双方の本を執筆・制作するためのフォーマットです。XHTML5(HTML5)のサブセットでセマンティクスにEPUBの語彙(EPUB 3 Structural Semantics Vocabulary)を使用しています。

 PDF、EPUB、mobi(Kindle形式)、DAISYなどの電子書籍フォーマットをマルチに提供するO’Reilly Mediaですが、そのO’Reilly Mediaがgitでバージョン管理する出版プラットフォームAtlas(ベータ版)を立ち上げています。そのメインの制作用フォーマット(マルチフォーマット対応のためのソースファイル)にHTMLBookを据えようとしているようです。

 HTMLBookの仕様はまだドラフトの段階であり、HTMLBookの仕様案そのものがAsciiDoc形式で公開されているように、AtlasではまだAsciiDocがメインに使われているように思われます。なお、AsciiDoc形式の他にMarkdownDocBook XMLでの入稿も可とのことです(→参考)。

 HTMLBook、DocBook、AsciiDocの関係については、CAS-UBブログが以下のエントリで解説をしています。

 O’Reilly Mediaのマルチフォーマット対応については以下をご参照ください。

9月 25

障害と開発に関する国連総会ハイレベル会合で成果文書として配布された手話動画とテキストハイライトを同期させたHTML5文書

 9月23日にニューヨークの国連本部で、障害と開発に関する国連総会ハイレベル会合が開催されました。

 この会合の成果文書が、HTML5 with video、マルチメディアDASIY、EPUB3など様々なアクセブルな形式で公開されています。

 

 この中ですごいのはHTML5 with videoでしょうか。手話動画とテキストハイライトが同期されています。


Sign language with text (HTML5 with video)

 マルチメディアDAISYやMedia OverlaysなEPUBの動画版といったものですが、動画とテキストハイライトの同期はDAISYやEPUB3の仕様のではサポートされていません(EPUB3は動画を埋め込むこと自体は可能です)。

 なお、この国連総会の会合は、NHK WORLDでも報道されています。

3月 04

Google Chrome がWebに音声認識機能を埋め込めるWeb Speech API に多言語で対応。WebへのTTS機能埋め込みも可能?

 Google Chromeが安定版のver. 25でWebアプリに音声認識機能を埋め込めるWeb Speech APIに対応しました。しかも、日本語を含む多言語対応です。音声でウェブアプリを操作するといったことが可能になるようです。

 Googleの中の人による紹介動画が公開されています。 

 Googleがデモサイトを公開していますので、音声認識の精度を実際に試すことが可能です。

Web Speech APIの仕様には、このAPIのユースケースとして以下が挙げられています。Web Speech APIはWebの音声入力(speech-input)と自動音声読み上げ(Text-To-Speech)の制御をJavaScriptによって実現することを目的としているようですが、自動音声読み上げ(Text-To-Speech)に該当するものがない・・・?

  • Voice Web Search
  • Speech Command Interface
  • Domain Specific Grammars Contingent on Earlier Inputs
  • Continuous Recognition of Open Dialog
  • Domain Specific Grammars Filling Multiple Input Fields
  • Speech UI present when no visible UI need be present
  • Voice Activity Detection
  • Temporal Structure of Synthesis to Provide Visual Feedback
  • Hello World
  • Speech Translation
  • Speech Enabled Email Client
  • Dialog Systems
  • Multimodal Interaction
  • Speech Driving Directions
  • Multimodal Video Game
  • Multimodal Search
参考

 

Web Speech APIとSpeech Input API

 Web Speech APIの他にフォームに音声入力機能を追加するSpeech Input APIというAPIがあり、こちらはChrome 11から対応しています。input要素にspeech属性を追加するだけなので、実装は非常に簡単です。

 Web Speech APIとSpeech Input APIは機能的に被っている部分があります。どちらもGoogleが提案したAPIのようですが、そのあたりの経緯は以下で説明されています。Speech Input APIを提案した後により広範なWebの音声入出力を扱うWeb Speech APIをJavaScirptベースのAPIとして提案したようです。

参考

 

Text-To-Speech(自動音声読み上げ)機能

 ここからは、勉強不足ということもあり、憶測が混ざります。ご注意ください。

 Web Speech APIによって、Text-To-Speech(自動音声読み上げ)機能をJavaScriptで制御することが可能になります。これがBookshareが提供するブラウザ版電子書籍リーダーでのTTS(自動音声読み上げ)機能でおそらく活用されているのではないかと思われます(Googleの公式ブログが言及しているので)。Google Chromeは2011年にTTS APIを公開TTSエンジンを搭載※していますので、それを使用しているのでしょうか。

※2013-07-08追記
Chrome自身がTTSエンジンを搭載したのではなく、OSなどが搭載しているTTSエンジンを利用するためのAPIを公開したという話でした。誤った情報を流してしまい、大変申し訳ありませんでした。
Chrome Text To Speech – Beautiful Google – Google活用の仕方

  以下の動画で紹介されていますが、テキストを読み上げながら、読み上げる箇所をハイライト表示しています。

参考
2月 03

曖昧になるWebコンテンツと「書籍」コンテンツの境界 – HTML5電子書籍余話 その2 –

 当初、このエントリは「Webサイト化する電子書籍– HTML5電子書籍(2) -」のまとめとして書いていたものだったのですが、いつものように長くなってしまったので、エントリを独立させました。
 

1.前回のエントリをうけて

 というわけで前回のエントリでは「Webサイト化した電子書籍」と「電子書籍的UI」を付与する方法について紹介してきました。あのエントリをお読みいただいた方の中には以下のような疑問を抱いた方もいるのではないかと思います。
 
 従来のWebサイトとWebサイト化した電子書籍を区別する必要はあるのか。
  
 コンテンツの由来が紙の「書籍」由来であろうとWebオリジナルであろうとWebサイトとしては同じではないか、「電子書籍的UI」はデザイン上の些細な違いでしかない。そうお考えの方もいらっしゃるだろうと思います。

  正直、意見が分かれるところだと思いますが、私自身は後で述べる理由で少なくとも紙の出版物が消滅するということでもない限りは、今後もある程度区別はされていくと考えています。しかし、WebとWebサイト化した「書籍」コンテンツがビュワーとして同じようなデバイスとブラウザを共有している以上、その違いはこれまでのWebと「書籍」のような絶対的なものではなくなり、相対的なものになっていくだろうも考えています。 
 
 

2. Webコンテンツと電子書籍の共通する大前提

 Webコンテンツもリフロー型電子書籍(Webサイト化したものに限らず)は以下のような様々なサイズのデバイスに対応しなければなりません。


 
 Webコンテンツや「書籍」コンテンツがどれほど優れたデザインをしていようと、読者が読むデバイスで読みづらかったらその読者にとってその「優れたデザイン」は何も意味はありません。「Web」や「書籍」というコンテンツそのもののデザインを論じる前に、その読まれるデバイスへの最適化するためのUIを考慮する必要があります。つまり、デバイスのインターフェイスを無視したコンテンツのUIはありえないということですが、言い換えると
 

  デバイスのインターフェイスがコンテンツのUIを規定する。 

 とも言えます。これが大前提です。

 Webコンテンツとリフロー型電子書籍の場合は、特定のデバイスのインターフェイスの制約に規定されるのでなく、様々なスクリーンサイズのデバイスのインターフェイスに対応しなければならないという制約がコンテンツのUIを規定することになります。
 
 同じ制約のもとで読みやすいUIを追求していく限り、Webコンテンツも「書籍」コンテンツも似たUIを持つ可能性はあります。Webサイト化した電子書籍はデバイスだけではなく、Webブラウザというビュワーまで同じくするのですからなおさらです。
 
 

3. 「電子書籍的UI」の意義

 では、Webコンテンツと「書籍」コンテンツは同じデバイス上で読まれる限りは同義ではないかと言われてしまいそうですが、

  Webコンテンツと「書籍」コンテンツは長さが違う。 
  
  ということで、他にもいろいろと違いはあるのですが、端的にいえば、長さという点で大きく異なります。
 
 「書籍」というコンテンツは100頁強の量でも少ない部類に入りますが、Webコンテンツは紙に打ち出せば、A4で数頁で収まるものが主流です。WebコンテンツのUI(Webデザイン)は大雑把にいえば、そのA4で数頁という長さに最適化するためにこれまで試行錯誤してきたわけです(もちろんそれだけではないですけど)。同じデバイス上で読むとはいえ、WebコンテンツのUIに「書籍」コンテンツにそのまま適用するわけにはいきません。

 将来の有り様はわかりませんが、現在の「書籍」コンテンツには長いコンテンツを読むことに集中できるUIが求められています。「Webサイト化した電子書籍」に「電子書籍的UI」というものを付与する意味があるとすれば、そこにこそ意味があるのだと思いますし、Webコンテンツと「書籍」コンテンツを分かつものだと思います。つまりは、長いコンテンツを読むのに適したUIが「電子書籍的UI」なのであって、必ずしもページめくりのエフェクトが必要だとか具体的なUIを指しているわけではありません。長いコンテンツを読むのに適したUIはコンテンツごとに異なってくるわけですから。
 

 「書籍」コンテンツが100頁強でも短いとされるのはその前提として「紙の書籍」が存在するからです。同じコンテンツが紙版と電子版で刊行という次元の話ではなく、紙の書籍という存在そのものが比較の対象として「書籍」コンテンツの長さをある程度規定している。50頁や100頁の「書籍」コンテンツは読者に「短い」と感じさせ続けるわけです。
  

4. 曖昧になるWebコンテンツと「書籍」コンテンツの境界

 とはいえ、Webコンテンツと「書籍」コンテンツの違いは絶対的なものではなく、相対的な違いではしかないと思います。ここでは、長さを1つの基準にしましたが、「書籍」コンテンツの影響を受けて「長くなるWebコンテンツ」が出てくるでしょうし、もちろんWebコンテンツの影響をうけて「短くなる書籍」コンテンツもでてくるでしょう。Webコンテンツと「書籍」コンテンツの境界線はどんどんあいまいになっていくことになります。

 従来のWebコンテンツと比較すると長い過ぎる、しかし、「書籍」コンテンツと比較すると短いと思えるWebと「書籍」の中間に位置するような、Webとも「書籍」ともカテゴライズできないコンテンツがでてくることに私自身は期待もしているのです。これについては一度以下のエントリで詳しく書いたことがあります。

「書籍」と呼ぶには短い電子書籍というコンテンツと従来よりちょっと長くなったWebというコンテンツの相対的な関係

 

【おまけ】ここであまり書かなかったこと

 このエントリでは「電子書籍的UI」の付与の仕方とその意義については述べましたが、「電子書籍的UI」についてはほとんど言及しませんでした。すでに長いこのエントリがさらに長くなるからというのが主な理由ですが、過去のエントリでも一度書いたことがあります。この長いエントリを読んだ後でもさらに読んでやろうという奇特な方がいらっしゃったら、一度お読みいただけると幸いです。

ぼくのかんがえる電子書籍リーダーのUI : 紙の書籍のUIを真似ただけでは足りなくて 
 

2月 02

Webサイト化する電子書籍– HTML5電子書籍(2) –

 前々回はパッケージ化するHTML5電子書籍について紹介しました。そのエントリをご覧頂いた方からご指摘を頂いて、大幅な修正が2回入りましたが、そろそろ次の回ということで今回はWebサイト化する電子書籍について紹介してみたいと思います。
 

1. 「Webサイト化する電子書籍」とは

 この「Webサイト化する電子書籍」という言葉、これだけで理解できるほど自明なものとは思えませんのでまずは簡単に紹介します。

 HTMLコンテンツはHTML+CSS+JavaScriptで主に構成されます(CSSとJavaScriptは必須というわけではない)。例えば、以下のような構成のコンテンツがあったとします。読者にそれらを格納するフォルダごと渡して、その中にあるindex.htmlファイルを開いてコンテンツを読んでもらうという方法はいろいろと問題があるという話は前々回のエントリで話した通りです。

 ならばということで、前々回のエントリでは、パッケージ化して1つのファイルとして固める方法を紹介しました。今回は単純にいえば上のフォルダをパッケージ化もせずにそのままWebサーバーに上げてしまおうという話になります。つまり、やっていることはWebサイトをアップロードするのと全く同じです。読者にはURLを知らせて、そのURLからコンテンツへ誘導します。

 コンテンツがWeb上に上げられると読者はURLを頼りにコンテンツを行き来することになりますので、そのコンテンツの構成をローカル環境ほど意識することはほとんどありません。さらにハイパーリンクによって他のコンテンツと行き来することも当然ありえますので、他とのコンテンツの境界線はかなり希薄になります。
 
 上の図では一例としてindex.htmlにアクセスしていますが、リンクを貼ることができるものであれば別に他のページでもかまいません。htmlディレクトリの中に001.htmlというコンテンツファイルが格納されているならば、直接、http://example.com/html/001.htmlというURLを指定して読者に誘導してもよいわけです。

 上だけだと、新聞社や雑誌社がコンテンツをサイトに掲載している従来のものとあまり変わりありませんが、さらに踏み込んでコンテンツに「電子書籍的UI」を付与し、読者にはWebサイトではなく、「電子書籍」を読んでいるという意識を持たせようと意図した動きが最近、見られるようになっています。
 
 そんな電子書籍コンテンツをここでは「Webサイト化した電子書籍」と呼ぶことにします。

 では、まずはWebサイトに「電子書籍的UI」を付与する方法から紹介したいと思います。

 

2.電子書籍的UIを付与する

 

treesaver.js

 treesaver.jsはHTML+CSS+JavaScriptでWebサイトを電子雑誌ライクなUIを実現するオープンソースのJavaScirptフレームワークです。

treesaver.js
http://www.treesaverjs.com/

  紹介動画を見ていただくとわかりますが、スマートフォンからデスクトップ版のブラウザまで様々なスクリーンサイズのデバイスに対応した電子雑誌なUIをもったサイトをつくることができます。


 
 2つのデモサイトが公開されています。

 

aside

 Web上に電子雑誌を公開することを提案しているサイトです。興味をもったら連絡しろぐらいのことしか書いておらず、利用する方法がよくわかりませんでした。個別に交渉なんでしょうか。

aside
http://www.asidemag.com/

  このasideのサイトそのものがそのサービスのデモサイトになっています。iPadで確認することができます。お持ちでない方も以下の動画でそのデモの紹介されていますのでご覧ください。

aside magazine Trailer from aside magazine on Vimeo
 
 ここまではどちらかと言うと「書籍」コンテンツをWebサイト化することを主たる目的としていますが、以下のCSS3ののGenerated Content for Paged Media Moduleは「書籍」コンテンツのWebサイト化に使うだけではなく、通常のWebサイトに「電子書籍的UI」を付与するために利用できそうな仕様になっています。 

CSS3のGenerated Content for Paged Media Module

 これはフレームワークではなく、W3Cが検討しているCSS3の仕様の1つです。プリントメディアの特徴をCSSを使用して実現することを目的としています。

CSS Generated Content for Paged Media Module
http://www.w3.org/TR/css3-gcpm/

 この仕様をブラウザが実装するようになれば、スタイルシートを指定するだけで、以下のような電子書籍的なUIを実現することができるようになります。


 

 といえ、この仕様はまだドラフトの段階で安定版のブラウザで実装しているものはありません。普通に使用できるのはもう少し先の話になりそうですが、Opera開発版では先行して実装されているので、それを使って試すことも可能です。
More fun using the Web, with getUserMedia and native pages – Dev.Opera

 このCSSを実装したデモサイトもすでに用意されています。上の開発版で訪問するとデモサイトに実装されたこの仕様を確認することができます。
Opera Reader: Paging the Web

※2012/6/18追記 
 先日公開されたOpera12でCSS Generated Content for Paged Mediaがサポートされるようになりました。
Opera の新機能

3.Webサイト化する電子書籍のメリット/デメリット

 AppleのApp Storeの審査がときおり問題になる現状を見ると、プラットフォーマーの意向に左右されずにすむことがWebサイト化の一番のメリットかもしれません。(HTML5に対応した)ブラウザがすべてそのコンテンツのビュワーになるわけですので、対応するデバイスが劇的に増えることになり、利用者層の拡がりも期待できます。また、コンテンツはサーバーで集中的に管理できますので、読者の読書環境を一元的に提供することも可能になります。

 しかし、一方でWebサイト化するならば、独自でサーバーを用意しなければなりません。場合によってはシステム開発も独自に行う必要があるでしょう。コンテンツを有料で配信するのであれば、その課金についてもなんらかの手段を用意しなければなりません。仮に用意できたとしても、サイトの無料化と有料化の間で揺れ続けている新聞や雑誌の動向を見ても、Webサイトの有料化は非常にハードルが高いと思われます。
 
 米国のPLAYBOYがウェブ雑誌としてWebサイトに移行しましたが、事例としてはまだまだ少ないようです。デメリットを勘案すれば、小規模なコンテンツプロバイダが既存のプラットフォームを捨てて、Webサイト化に移行するのはかなり高いハードルを乗り越えなけれなりません。当面はWebサイト化はブランド力をもった雑誌や大量の定期購読者を抱えているような雑誌、もしくは巨大なプラットフォームの間で行われるにとどまるかもしれません。

 しかし、一方で既存のWebサイトを例えば、iPadで見るときは「電子書籍的UI」で見せるといったWebデザインの延長として提供することは充分ありえることです。デバイスのインターフェイスにあわせて柔軟にUIを最適化させる、その最適化の手段の1つとして「電子書籍的UI」を組み込むということです。ブログや新聞、雑誌のようなテキストコンテンツが主となるWebサイトはその候補の筆頭だと思いますが、公的機関や大学、研究所がサイトで公開している報告書や広報誌もその候補になり得ます。また、メディアがサイトの有料化に踏み切る際に電子書籍的なUIを付与するという選択肢もありえるかもしません。 

 

 

1月 25

iBooks Authorのibooks形式ってなんぞや– HTML5電子書籍余話 –

 先日の「HTML5電子書籍(1)」の続き、というよりも、(1)と(2)の間に入る余話になります。

 (2)を書いている途中であれの発表があったもので、そのまま続きを書いてよいものか調べておりました。それでせっかく調べたので、ということでまとめてみました。あのAppleの発表を実況サイトを追った範囲では、HTML5とJavaScritpばかりが強調されてEPUBには全く触れていなかった印象でしたからね。

というわけで、AppleのiBooks Authorです。

 

1. ibooks形式を作る

  まずはiBooks Authorでibooks形式の電子書籍を1つ作ってみます。といっても、ほとんどサンプルをそのまま使用したものにします。

 ファイル名は「ibooks_auhtor_test」にしました。スペルミスは一度笑ってスルーしてください。 
  
 このままサンプルをibooks形式のファイルとして書き出してしまおうと思います。

 「ファイル」→「書き出す」を選択すると以下のような画面がでます。

 ここで「iBooks」を選択するとibooks形式でコンテンツを書き出すことができます。

 
 
 これで、一応ibooks形式の電子書籍を作成できました。 

 

2. ibooks形式の中身を見る

 
 ではでは、ということで、ibooks形式の中身をのぞいてみたいと思います。
 
 拡張子のibooksをzipに変更して、そのzipファイルを解凍すればibooks形式の中を開くことができます。上で書き出したibooksファイルの中身を見てみると以下のようになっています。 

 中身を見ているとファイル構造そのものはほとんどEPUBです。コンテンツファイルがXHTML5で作成されたり、SVGや動画、音声ファイルに対応したりしているので、EPUBはEPUBでもEPUB2かEPUB3のどちらなんだろうかと迷うところもありますが、「ibooks.opf」ファイルがEPUB2のものなので、EPUB2かEPUB3かと言われると、EPUB2なのかなと思います。

とはいえ、
 
 トップレベルのディレクトリにある「minetype」ファイル(このファイルは〜形式であると宣言するファイル)には
 

application/x-ibooks+zip
 

とEPUBと異なるminetypeがしっかり定義されています。

 さらに各CSSの冒頭では

 
@namespace ibooks "http://www.apple.com/2011/iBooks"
 

と「-ibooks-」という独自の接頭辞が定義され、「-ibooks-」の接頭辞を持つibooks独自のプロパティが至るところで使用されています。
 

 つまり、ここまでの話を総合すると
 
ibooks形式=EPUB2をHTML5対応させて独自拡張したApple独自のフォーマット(読めるデバイスはiPadに制限)

 と言ってしまってよいかと思います。

 さらに@wakufactory さんが以下で紹介されているようにDashboardウィジェットというHTMLウィジェットで作成したウェブアプリを組み込むこともできます。

iBooks AuthorのHTMLウィジェットの作り方

 ウィジェットという形でウェブアプリを組み込めるならば、正直、使い方次第でもう何でもありになってしまいそうです。インタラクティブな機能はEPUB3の仕様が含有するそれの範囲を超えているのではないでしょうか。
 

 ちなみに・・・、なのですが、@commonstyle さんにお教えいただいたところによると、ibooks形式の拡張子を「.ibooks」から「.epub」に変更するとAdobe Digital Editions ver.1.72(ADE)では開けてしまうようです。

 実際に拡張子を「.epub」に変更して試してみると完全ではないようですが、一応、開けました。こういうところにEPUB由来を感じます。

 
 でも、ADEで開けても、肝心のiBooksでは開けないんですよね・・(レイアウトは崩れるが一応開けるEPUBビューワーはいくつか確認できました)。
 
 

3. ibooks形式のソースの編集する

 ところで、iBooks Authorで手軽に作れるのはよいとして、そのソースを直接編集できないのかという疑問も。

 上述のように中を開くことはできます。中のソースを直接編集してまたibooks形式に変換できるのかということですが、EPUBをベースにしているので、ibooks形式に固める方法もEPUBと同じ方法でいけるようです。つまり、以下のような感じで

$ cd ibooks_auhtor_test
$ zip -0 -X ../ibooks_auhtor_test.ibooks mimetype
$ zip -r ../ibooks_auhtor_test.ibooks * -x mimetype

と、minetypeファイルを除く形で圧縮をかけるとibooks形式のファイルに再度固めることができるようです。

 とはいえ、Appleの規約がそれを許すかどうかはよくわかりません(規約の拘束力がどれほどのものかも含めて)。

でも、一応、技術的には可能と。最も仕様が公開されないとどこまでいじってよいのかもよくわかりませんね。

 

4. itmsp

 itmpとはなんぞやですが、「ファイル」→「公開」を選択すると「itmsp」というファイル、というかいくつかのファイルを格納したディレクトリが作成されます。おそらくはiBooks Storeで公開する際に使用するものだと思います(未確認)です。

 今回の場合だと、「ibooks_auhtor_test.itmsp」というディレクトリが作成されるのですが、そのディレクトリには

 とibooksファイルとメタデータ、表紙画像が格納されています。メタデータと表紙画像はiBooks Storeの書誌画面として使用するんでしょうか(未確認)。メタデータと表紙画像は予め外部ファイルとして書き出されるですね。
  
 ここで終わってもよいのですが、 これを書きながら感じたことを余談として2つほど以下に書いてみます。そもそも余話であるはずのこのエントリに余談が許されるのかという問題はおいていて・・・

【余談 その1】 iPad上でEPUBは今、どこまでできるのか的な話

 iBooks上ではibooksもEPUBも同じWebkitを使用しているはず。EPUBにはさすがにHTMLウィジェットは組み込めないと思いますが、同じエンジンを使用しているならば、iPad上で読む限り、ibooks形式でできることはEPUBでもできるのではないかと思ったりします(未確認)。

 そう思わせたものが、米O’Reilly社から無料で公開されている以下の電子書籍(EPUB)です。 

 null
HTML5 for Publishers

By Sanders Kleinfeld
Publisher: O’Reilly Media
Released: October 2011

 この書籍では出版社を対象にしたHTML5の紹介がされているのですが、その中のCanvasの紹介で、お絵かきツールをEPUBファイルの中に組み込んでいたりするんですよね。一応、EPUB2なはずですけど。 

 仕様上はあまり推奨されませんが、iBooks上であれば、いろいろとできてしまいそうな気がします。

  で、同じWebkitを使用しているならば、全くとは言わないまでの、それに近いことはできるのではないかと(UIは除く)。

  時間があれば、ちょっと調べてみたいところです。
   

【余談 その2】 iBooksのEPUB3フル対応はいつなの?的な話(推測しか書いてません)

 

 ところで、iBooksのEPUB3のフル対応はいつなのかという問題ですが、Mobile SafariとiBooksがWebkitを(おそらく)共有している以上、iBooksのEPUB3へのフル対応はもう少し先になるかもしれません。

 EPUB3はW3Cの仕様としてまだドラフト段階のCSS3の仕様をいくつか組み込んでいます。EPUB3の仕様はすで確定し、その仕様には「-epub-」という接頭辞も用意されています。しかし、AppleはiBooksのためにだけにドラフト段階の仕様をiOSのWebkitに対応させる気がないのかもなあぁとこういうのいじってみて感じるところです。-ibooks-という接頭辞を用意して独自のプロパティを使用しているアップルさんではありますが。

 もしMoblie Safariと足並みを揃えることになるとしたら、iBooksのEPUB3フル対応はもう少し先になりそうですね。もう少しといっても次のiOSのアップデートまで、半年先とか長くて1年先ぐらいですが。

※2012/01/30 追記
iBooksはEPUB3にすでに部分的に対応しておりましたので、【余談 その2】を「対応」から「フル対応」へ変更しました。
 

1月 11

パッケージ化されたHTML5電子書籍 – HTML5電子書籍(1) –

 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
http://bakerframework.com/
HTML5ベースを使った電子書籍フレームワーク「Baker」 – MOONGIFT

簡単にいうと、Xcodeのプロジェクトのプロジェクトです。コンテンツをいれるbookディレクトリ以外はすでに用意されているので、このbookにコンテンツファイルであるhtmlファイルやcssなどをいれてやり、コンパイルすればそれだけでできる。

 
上のBakerをさらに利用したLakerというフレームワークもあります。より動的でインタラクティブなものがつくれるようになっているのでしょうか。デスクトップ用ブラウザでも見られるコンテンツの作成も実験的にサポートしているようです。

Laker


Laker
http://www.lakercompendium.com/
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も必要ではないか(ツッコミ)。その件をご指摘くださった神崎渉瑠さんのコメントも合わせてお読みいただけると幸いです。

11月 18

HTML5のフォームの機能拡張へのブラウザの実装はどうなんだ? : typeコンテンツ属性の場合

 HTML5のform拡張が今のブラウザでどの程度対応しているのだろうかとちょっと試してみました。あらかじめ断っておきますが、対応していないブラウザでみると、全く何がなんだかなよくわからないエントリです。
  
 まずはtypeコンテンツ属性です。

・typeコンテンツ属性
 <input type=”ココにいれる属性” />

 結論からいうとOperaが一番対応しているみたいですね。次はSafariやChromeといったWebkit系のブラウザですが、Operaの対応ぶりと比較するとかなり差がついてしまっているようです。FirefoxはFF8でも全くといってよい程対応してません。IEは試せる環境がないので試していませんが、IE9だとどうなんのでしょうか。

というわけで、Operaを使える環境の方はOperaでご覧ください。

HTML5の新type属性のテスト

 以下はW3CのHTML5の仕様からの抜粋になりますが、HTML4時代からあるtypeコンテンツ属性を含めると以下になるようです。HTML5で新しく採用されたtypeコンテンツ属性、実装にあまり進展が見られないような気がします。

Keyword State Data type Control type
hidden

Hidden An arbitrary string n/a
text Text Text with no line breaks Text field
search

Search Text with no line breaks Search field
tel Telephone Text with no line breaks A text field
url

URL An absolute IRI A text field
email E-mail An e-mail address or list of e-mail addresses A text field
password

Password Text with no line breaks (sensitive information) Text field that obscures data entry
datetime Date and Time A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC A date and time control
date

Date A date (year, month, day) with no time zone A date control
month Month A date consisting of a year and a month with no time zone A month control
week

Week A date consisting of a week-year number and a week number with no time zone A week control
time Time A time (hour, minute, seconds, fractional seconds) with no time zone A time control
datetime-local

Local Date and Time A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone A date and time control
number Number A numerical value A text field or spinner control
range

Range A numerical value, with the extra semantic that the exact value is not important A slider control or similar
color Color An sRGB color with 8-bit red, green, and blue components A color well
checkbox

Checkbox A set of zero or more values from a predefined list A checkbox
radio Radio Button An enumerated value A radio button
file

File Upload Zero or more files each with a MIME type and optionally a file name A label and a button
submit Submit Button

An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission A button
image Image Button A coordinate, relative to a particular image’s size, with the extra semantic that it must be the last value selected and initiates form submission Either a clickable image, or a button
reset

Reset Button n/a A button
button Button n/a A button

from “4.10.7 The input element”. “HTML5 A vocabulary and associated APIs for HTML and XHTML”  
 
 

11月 08

W3CでのDRMの仕様の標準化を進めるべきかどうかの議論を少し追ってみました。

 先週のW3C TPAC(Technical Plenary and Advisory Committee)の中で行われたHTML Working GroupのF2F(顔合わせ)ミーティング(2011/11/3-4)の要約がW3C Blogに掲載されています。その中にDRMの仕様の標準化をW3Cの中で検討できないかという議論が行われたようです。以下はW3C Blogの抜粋です。

DRM

There is a discussion brought to the HTML WG by the WebTV task force to know if there is a possibility to add a mechanism to protect content. There is no resolution yet. On this same topic, an interesting article has been published on the history of the different systems proposed in the past.

from Open Web Platform Weekly Summary – 2011-10-31 – 2011-11-06 – W3C Blog
 
 Web標準でDRMの仕様ができるならこりゃすごい話だと思い、どんな議論がされていたのか、少し追ってみました。

 上で要約されているHTML Working GroupF2Fミーティングの議事録が公開されています。その議事録を読むとDRMについての議論はWeb and TV Interest GroupMedia Pipeline Task Forceが作成したRequirement Document Draft(要求文書案)という要望リストをベースに進められたようです。ですので、DRMについての議論も映像コンテンツの保護を目的するDRMが中心になっているのではないかと思われます。

では、議事録を紹介するまえにこの要求文書案の該当部分を先に抜粋します。

 

Content Security and Digital Rights Management

The delivery of premium media over an unsecured network such as the Internet requires the protection of proprietary and copyrighted content. Standardized support for content protection requires the following.

R9. Security and Digital Rights Management Identification (Dropped. No change necessary)
The media element interface should support the specification of content protection and digital rights management formats (e.g. DECE Ultraviolet, DTCP-IP, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

R10. Security and Digital Rights Management Parameters (LC bug #13333 and #13625)
The media element interface should support secure specification of content protection and digital rights management parameters (e.g. subscription requirements, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

R11. Security and Digital Rights Management Feedback (Gap? Do we just need to agree on common identifiers?)
The media element interface should support the feedback of relevant content protection and digital rights management information (e.g. supported DRMs, DRM ready, need to reactivate license, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

frome Requirement Document Draft

 上のR9はすでに検討から外れましたが、R10とR11が残っています。この2つの要求について11/3のF2Fミーティングで議論が進められたようです。その該当部分の議事録が以下です。

R10
… getting DRM system information
… exchange DRM related messages
… ref: OIPF DAE specification
… R11. Content Protection Feedback and Errors
Tantek: are the slides in the respective bugs?
Clarke no but they could be
ACTION Clarke add contents from the slides of the presentation to each specific bug
[trackbot] Sorry, couldn’t find user – Clarke
MW: Different conclusions though, might be components exposed through the web interface, pass through for parameters is different than webarch that hides platform/device specific things
… re: content protection
… some devices have content protection, some dont’
… my question to the group is: is it acceptable to introduce this capability to the web platform (pass thru), or some other strategy?
Anne: the last time this was discussed on WHATWG list
… least controversial suggestion was API feed bits into the video stream
… DRM would be implemented at the application level
MW: you can’t implement the DRM in the JS
… needs to be implemented in trusted execution environment
[karl] there is nothing secure in life. useless pun.
MW: objective of DRM is not to make it impossible but difficult, for some well defined values of difficult
… need these capabilities in the trusted computing layers
… below the video element
Anne: we are already at the place where you have H264 decoding in JS
… I was just stating the last thing that was discussed on this topic that had some traction beyond we don’t want to go there.
John Simmons of Microsoft: Echoing what Mark said.
… key takeaway
… DRM systems are going to be used on video delivered to devices
… people who develop DRM understand those constraints
… e.g. can’t implement in JS
… key question is whether HTML will be able to accomodate DRM protected content
… or continue like silos today
… which prevent large scale growth of internet television that we’d like to see
MV: related to 179
… there are these two proposals
… 1. for parm
… 2. not use it
… data- and x- are supposed to be prohibited from use
… but no change proposal says use those
… didn’t make sense
… details are in the issue 179 two alternate proposals
… can anyone comment?
PC: project change proposal?
… original change proposal
MV: just above the blue box
… furthermore the data-* mechanism etc.
… can’t be used
… but then in Sylvia’s counter proposals says to use them.
… does the quoted text need clarification
… or is it just a misunderstanding?
Hixie: the data-* attributes are intended to only be used by scripts in the page, not by the user agent
… if you have something the user agents would use, then either we would add it to the language
… or if it was experimental we would use x-* syntax
… e.g. webkit has x-webkit-*
Adrien: the misunderstanding was how x- attribute might be used on the way to standardization
… e.g. like it’s done with vendor prefixing in CSS.
… in order that those experimental implementations don’t drive actual content, we use a vendor prefix
… the proposed standard doesn’t have a vendor prefix
… the vendor prefixes are a temporary measure to experiment while standard is being agreed.
MV: concrete case is UPnP
… available spec
… but no support for it
… slightly different model UPnP video vs. regulary HTML video access
… a separate group UPnP could publish use x-upnp-* params, and encourage others to
Hixie: if they’re writing an actual standard they wouldn’t use x-
… just upnp-
MV: so ok for them to just use upnp- ?
Hixie: I wouldn’t recommend it, would prefer to come to the group
MV: I agree primary idea is bring these in bug 13625 (13635?) also tracks separate attribute
[pimpbot] 11http://www.w3.org/Bugs/Public/show_bug.cgi?id=13625 b.lund, P2, NEW, 13There is no way to pass audio and video content metadata to the user agent that is required in some cases for playback.
PC: I want to point people to the conformance clause in HTML5
… It says you can conform by pointing to HTML5 and other set of additional specifications
… a vertical industry could say you conform to HTML5 and this other specification
… too many people believe you want to force everything into the HTML5 spec.
… I want to support Ian’s view that if something is generic we want that discussion and get that in
… or at least know about it
… so that we can detect when something becomes emergently generic
Hixie: I agree
… the conformance section really it says what’s been true of any spec
MW: I wouldn’t encourage people to write extensions. we have an interest in strongly discouraging separate extension. we don’t want fragmentation.
… if you look at OIPF and HDTV you have 100s of 1000s of pages of stuff
… a uniform platform, that should be our goal
Hixie: in practice as people do start writing specs that start extending HTML in that way, it probably means we failed, but in reality it might happen anyway

from HTML WG f2f — 03 Nov 2011

DRMについての議論がどこまで続いているのか、よくわかりませんでしたので多めに抜粋してあります。

この会議ではClarke Stevens氏がどうもDRMについて、提案をしたらしいのです(おそらく)。そのClarke氏が使用したスライド資料がどうも見つかりませんので、議論はちょっと追いにくいのですが、「HTMLやJavaScriptでやったもんかな〜(疑問)」「HTMLがDRMで保護されたコンテンツに適応できるのか」みたいな意見が出たみたいです。どんな結論がでたのかはよく分かりませんが、おそらく出なかったのではないかと。個人的には有料のWebサイトというものがありえるのではないかと思うので是非議論をすすめてほしいと思うところです。今後、どのように進展していくのか興味深いところです。

さらにWeb and TV Interest GroupのメーリングリストでこのDRMに関する議論を遡ることができます。
Web and TV Interest GroupのMLのDRMに関するやりとり