‘リフロー’ タグのついている投稿

VR/ARでの読書について思うこと

2020/11/13

 先日、メディアドゥからVR/AR用の電子書籍ビューア開発開始というニュースリリースの発表がありました。また、Facebookはスタンドアロンで動作する普及版VRビューア、Oculus Questの後継機に当たるOculus Quest 2を販売開始し、これがいよいよ家電量販店で売られるなどという話も出ています。そろそろ本格的にVR/AR普及が見えてきた感がありますので、ちょっとVR/ARでの読書について期待するところを書いてみたいと思います。

VRによるデバイス画面サイズの制約からの解放

 今、私たちは電子書籍を例えばスマートフォンで、あるいは専用機やタブレットで、もしくはPCの画面で読んでいます。これらの「画面」は、いずれも物理的な実サイズを持っていて、必然的に表示できる文字やイラストの大きさにはデバイスの物理サイズによる制限がかかります。これを緩和するために行っている作業が「テキストリフロー化」で、そうすることで紙の本からの電子化であってもスマートフォンの小さな画面でもとりあえず読めるようにはなります。

リフロー型電子書籍では紙の版面情報の再現は難しい

リフロー型電子書籍では紙の版面情報の再現は難しい

 ただし、例えばもとの本が大判のものであった場合などには必然的にそれに収録されている図版のサイズもそれに合わせたサイズになりますし、その図版を画面の小さなスマートフォンで眺めることが快適な読書体験かと言われれば当然そこには疑問符が付きます。読めはすることと快適に読めることはイコールではないのです。これは、リフローでの電子化を仕事としてやっていると強く実感します。
 さらに、テキストリフロー化はその過程で多くの情報を強制的に削ぎ落とす行為です。例えば実用書などでは見開きの片方のページに大きく図を表示し、もう片方のページに解説文を載せるといったレイアウトのものがありますが、これはテキストリフローでは再現できません。このため、図版の挿入位置を工夫し、テキストの文言を調整するといった作業を行いますが、当然限界はあります。

 VRによってデバイスサイズによる縛りがなくなり、任意のサイズの仮想的な画面を展開できるようになればそのあたりの悩みは一気に解消されるはずです。なにしろ仮想画面なので、例えば「新聞の見開きサイズの画面を展開する」といったことも可能になるわけです。これはとてつもなく大きな進化です。

仮想画面はいくつ出してもよい

複数の「画面」を並べて行うPCでの読書

複数の「画面」を並べて行うPCでの読書

 さらに、VRでは例えば今PC上でウィンドウを複数出しているように、仮想画面を複数並べて「読書」することも可能になるはずです。このメリットがピンとこない方は、今自分たちが(エンタメではない)本を読むときにいくつの「画面」を並行して見ているのかを考えてみればよいかと思います。

 まず、読書対象の本そのものの版面。用語がわからなければそれを調べるために辞書を引くこともあるでしょうからそれも「画面」の一つ。ネットを使って検索して調べることもあるでしょうし、文章中で他の本を引用している箇所があれば、その本を持ってきて該当箇所を調べるようなこともやるでしょう。内容を書き留めるための手元のノートも「画面」と見ることができそうです。
 さらには読書対象の本の中に注が設定されていれば、それと本文を相互参照しながら読むこともしますので、これもそれぞれ別の「画面」と見ることができるでしょう。つまり「読書」というのはそういう多くの「画面」を随時参照しながら行う行為なのだと思います。

 そう考えると、今電子版で売れているのが圧倒的にコミックスやライトノベルのような軽いエンタメで、カタい本が売れにくい状況になっているのも理解できます。コミックスやライトノベルを読むなら「画面」はひとつで済みますが、カタい本を読むにはひとつでは足りないのです。VR技術によって、物理的に多くの面積を専有することなしに多数の「画面」を並べて本を読めるようになれば、それはかなり幸せな読書体験になるのではないかなと思います。

必ずしも全てが仮想画面でなくてもよい

 さて、そうは言っても「やはり紙の本がいい」という方はたくさんいるのではないかと思います。でも例えば、紙の本を読みながら辞書や参考文献などを仮想画面として適宜呼び出せるとしたらどうでしょうか。単に別画面を見せるだけなら「スマホを横に置いておけばいいじゃん」という意見が出そうですが、おそらくGoogleやAppleあたりはそれだけでは済ませない世界を構想しているように思えます。紙の本を読みながら、わからない用語があったときにタッチペン的なものでなぞれば視界内に辞書の用語解説ページが仮想画面としてポップアップしてきて参照できる、そんな世界が来るように思うのです。

 そういった現実世界のものに電子情報をオーバーライドして見せる技術は「AR(Augmented Reality/拡張現実)」と言い、こちらは現在GoogleやAppleが熱心に研究を進めている分野です。今はまだ視界全てを置き換えるVRとは別物として開発されていますが、VR機器の前面のカメラで周囲の映像を取り込んで内部ディスプレイに投影すればAR的な表示ができますので、本質的に地続きの話です。なのでMicrosoftなどはMR(Mixed Reality)という用語を使っていたりもします。

Google翻訳ではスマホをかざすだけで翻訳文が表示される

Google翻訳ではスマホをかざすだけで翻訳文が表示される

 今、GoogleはGoogle Glassプロダクトを継続的に進めていますし、スマートフォンでGoogle翻訳のアプリを起動すれば対象のテキストを写すだけでリアルタイムに翻訳文がスマホ画面の中で見られたりもします。また、Google ブックスの展開を見れば理解できるように、彼らは本の世界へのコミットにも熱心です。
 もちろん超えなければならない技術的な壁はまだいくつもあるでしょうが、もう想像できないほど先の話ではないように思います。5年後、10年後にはARメガネをかけながら読書している人はちらほら見かけるようになるのではないでしょうか。期待をこめてそういう世界の到来を待ちたいと思っています。

(2020.11.13)

緊デジ(電書協)仕様のリフロー型EPUB3を作ってみる

2012/12/03

 AmazonのKindleストアもついに日本展開を開始し、Google Play Booksもサービス開始するなど、いわゆる「黒船」陣営も軒並み出揃ったことで、ついに本当の意味での「電子書籍元年」が始まった感があります(Apple iBookStoreが未だにロールアウトしないのが気になるところではありますが)。こうした中でpubridgeと紀伊國屋書店、楽天koboとの電子書籍配信・販売合意が発表され、緊デジ事業で制作されたコンテンツの提供先も確定しました。これから先も次々に提供先が増えていくことになるのでしょうか。

 緊デジ仕様のEPUB3は、まだ校正用ビューア等の仕組みが発表されていないため正式には制作開始前の状態ですが、「電書協EPUB3制作ガイド」に準拠するという方針は発表されており、「緊デジ版EPUB3テンプレート」も発表されているため、既に制作自体は可能です。

 ということで、以下は緊デジ仕様のリフロー型EPUB3コンテンツ制作の具体的な流れです。あくまでまだテスト段階ではありますが、ご参照いただければ幸いです。

1 本文用のXHTML/CSSファイルを準備する

本文用のXHTML/CSSファイルを準備

本文用のXHTML/CSSファイルを準備

 本文用のXHTML/CSSファイルを準備します。私は今回、テキスト部分に関しては以前のエントリで発表させていただいたInDesignでXMLのタグ付けをしてXMLを書き出し、Perlで変換する方法でXHTMLファイルを制作しましたが、これは印刷用データからの変換を前提としたワークフローですので、もとがテキストデータであれば初めからDreamWeaverなどweb系のツールを利用したほうが効率は良いかと思います。XHTMLファイルのタグ付けルールは前述の「緊デジ版EPUB3テンプレート」及び準拠している「電書協EPUB3制作ガイド」に従います。

 画像のみで1ページのページに関しては、「kinidigi_reflow_template」内の「p-005.xhtml」(1ページ画像テンプレート)を元に、タイトル、ファイル名、alt(代替名称)を書き換えてファイルを準備します。

 「電書協EPUB3制作ガイド」は基本的に紙書籍の電子化を目的としたガイドラインで、印刷データや.book、XMDFといったレガシーフォーマットからの変換を念頭に置いているものと思われ、全体的に現在もしくは近い将来に各ビューアが実装可能なプロパティだけに絞り込んだ、かなり保守的な仕様です。そのため電子ならではのインタラクティブな表現などはほとんど期待できませんが、その分ビューアの側の表現の揺れなどはそこまで気にしなくても良さそうな印象があります。緊デジ用EPUBに用いるためのXHTMLファイルは、この「電書協EPUB3制作ガイド」に従い、基本的に支給されたCSSファイルの記述を利用する形で制作します。通常書籍で必要とされる表現はほぼ網羅されていますので、書籍(文章もの)のコンテンツであればほぼ事足りるものと思います。自分でclass名を定義する必要はほとんどありません。

見出しid番号を連番で振っておく

見出しid番号を連番で振っておく

 もし、各作品ごとにCSSの追記が必要な場合は、必ず「book-style.css」内の作品別カスタマイズ領域内に記述します。その場合でも電書協ガイド(17ページ)で規定されている「RSによる対応を想定するHTML 要素とCSSプロパティ」の範囲内での記述に留める必要があります。

 本文用のXHTMLファイルは最終的に「p-001.xhtml」「p-002.xhtml」といった形で連番のファイルにリネーム※1し、目次に表示させたい見出しには「id="toc-001"」といった形でユニークな見出し番号を振っておきます。なお、IDの属性番号は1文字目は必ず英文字である必要があります。これはXHTMLを含むXMLの属性名命名規則の縛りです。数字は2文字目以降にしか使用出来ませんので念のため(私は一度やらかしました)。

2 カバー/注意書き/奥付/本扉などのXHTMLファイルを準備する

テンプレートをコピーし、書き換える

テンプレートをコピーし、書き換える

 「緊デジ版EPUB3テンプレート」のファイルをコピーし、書き換える形で、カバー/注意書き/奥付/本扉などのファイルを整えます。

 カバー「p-cover.xhtml」は、タイトル名を書き換え、イメージファイルのalt領域にタイトル名を記述すればOKです。カバーに用いる画像ファイルは「cover.jpg」の名前で準備しておいてください。

 電子化にあたっての注意書き「p-caution.xhtml」は、タイトル名と縦/横の記述を書き換えればOKです。

 奥付は通常、電子化クレジット「p-credit.xhtml」と、底本奥付(テンプレートの「p-006.xhtml」を参照)の2種類が必要です。電子化クレジットは各出版社から支給されるデータをもとに入力することになります。底本奥付は画像を用意し、タイトル名とファイル名の連番(p-xxx.xhtml)、目次用のid番号を書き換えればOKです。底本奥付用の画像ファイルは「original_credit.jpg」の名前で準備しておいてください。

 本扉「p-titlepage.xhtml」も基本的には画像ページでOKですが、出版社からの指定があった場合はテキストで準備することになります。画像の場合はテンプレートの「p-005.xhtml」(1ページ画像テンプレート)を元にファイルを整えます(ファイル名は「p-titlepage.xhtml」にリネーム)。テキストの場合はテンプレートの「p-titlepage.xhtml」を書き換えてください。

 書き換えが必要な箇所は、「電書協EPUB3制作ガイド」(26ページ〜)に色文字で示されています。ご参照ください。

3 作成した各ファイルをEPUB圧縮用のフォルダにまとめる

 「kinidigi_reflow_template」のフォルダをまるごとコピーし、フォルダ名をリネームしてから、作成したXHTMLファイルを「xhtml」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKですが、次のステップで「OPFパッケージファイル生成アプリ(緊デジ用)」を使用する場合は、「p-toc.xhtml」はそのまま残しておいて下さい(名前の抽出用です)。画像ファイルは「image」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKです。

4 OPFパッケージドキュメントを準備する

ファイルごとの見開き表現の有無を記述

ファイルごとの見開き表現の有無を記述

 OPFパッケージドキュメントを準備します。OPFパッケージドキュメントは、書誌情報やユニークIDの記述、EPUBパッケージ内に収納する全ファイルの登録、コンテンツの並び順や右綴じ/左綴じの規定、見開き表現の有無などを規定するもので、電書協ガイド/緊デジのテンプレートでは「standard.opf」の名称で規定されています。基本的にこのファイルを書き換えることになります。なお、このファイル名は「META-INF」フォルダ内の「container.xml」に登録されていますので、変更するとEPUBファイルとしてパッケージングができなくなります。

 今回私は、以前のエントリで発表済の「OPFパッケージファイル生成アプリ(緊デジ用)」を使用してOPFパッケージドキュメントを準備しました。image/xhtmlの登録作業や書誌情報やユニークID入力補助を目的としたアプリです。なお、このアプリを利用した場合でも、ファイルごとの見開き表現の有無(spine項目内「properties="page-spread-left"」記述部分)は手動で書き換える必要があります。
 ちなみに緊デジ仕様のEPUBでは、ユニークIDにJP-eコードを用いる部分が電書協ガイドのそれとは異なります。もし上記アプリを用いて緊デジ仕様以外のEPUBを制作する場合は、JP-eコードはuuid等に置き換える必要があります。

5 目次(p-toc.xhtml)ファイルを準備する

目次ファイルを準備する

目次ファイルを準備する

 目次ファイル「p-toc.xhtml」を準備します。なお、ここで言う目次ファイルは本文内にページとして表示される目次ファイルです。リーディングシステム内メニュー表示用の目次ファイルは「navigation-documents.xhtml」ですが、こちらには「表紙」「目次」「電子化クレジット」のみが登録され、緊デジでのEPUB3制作では通常書き換える必要はありません。この「p-toc.xhtml」も「OPFパッケージファイル生成アプリ(緊デジ用)」で自動抽出が可能です。ただし、目次は各書籍ごとに底本の体裁が異なるため、いずれにせよ後から細かな部分の編集は必要と思われます。

 目次のリンクの確認は、ファイルをSafari/Chrome等のブラウザで開くことで行うことができます。目次に限らず体裁の確認は、実際にEPUB圧縮するのと同じ構成のフォルダにXHTMLファイルを収納した上で、ブラウザで行うのが便利です。

6 EPUB圧縮を実行する

epub packagerを用いたepub圧縮

epub packagerを用いたepub圧縮

 OPFファイル、目次ファイルを上書きし、EPUB制作に必要な全てのファイルが整ったところで、EPUB圧縮を実行します。macで作業をしている場合は、フォルダ内の不可視ファイル「.DS Store」を除去する必要がありますので、まず「Ds Store Remover」にEPUB圧縮するフォルダをドラッグ&ドロップし、「.DS Store」を除去します(同種のアプリは複数あるようです)。

 その後、実際にEPUB圧縮を行います。ターミナルでコマンドを打ち込んで圧縮することも出来るのですが、私は普段「epub packager」を利用しています。ドラッグ&ドロップで圧縮できるので便利です。

7 エラーを修正する

epub Checkerでバリデートチェック

epub Checkerでバリデートチェック

 epub内のエラーを修正します。xhtml内idの二重登録、画像ファイル名の記述ミスなど、epub制作には間違いは付き物です。これをチェックし、全てのリーディングシステムできちんと表示されるepubを制作するために、バリデータでepubをチェックする必要があります。

 前出の「epub packager」では、epub作成時にバリデートもしてくれるのですが、実際にどういった部分に問題があったのかまでは表示してくれませんので、「Not Valid」と表示された場合は、バリデータでepubデータをチェックし、エラー部分を修正する必要があります。私は同じ会社から出ているアプリ「epub Checker」に、生成されたepubをドラッグ&ドロップし、バリデート作業を行っています。これはIDPFのepubcheckを内部的に利用したGUIアプリですが、epubcheckに関してはIDPFからCUI版のコマンドラインツールも配布されていますので、Windowsなどの環境でもそちらを利用してバリデート作業を行うことができます。epubcheckのエラーメッセージについては、前エントリ「IDPFのバリデータに叱られてみた」をご参照ください。

 全てのエラーを修正し、バリデータをノーエラーで通過できれば、epubファイルはひとまず完成です。

※1 電書協ガイドでは、ファイル名/id番号共に版元ごとに変更可能な項目として指定されていますが、本エントリではサンプルコンテンツの表記に従って「連番」としています。項目があまりに多数に及ぶ場合など、修正がしやすいような命名法を採用しても特に差し支えはありません

(2012.12.3)

 ファイル名/ID名の命名方式に関してご指摘をいただきましたので、追記いたしました。

(2012.12.10)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。