9月, 2012 | 電書魂

‘2012/09’ カテゴリーのアーカイブ

iPadとkobo touchで固定レイアウト／リフローを切り替える

2012/09/10

　先日、特定ページのみを固定レイアウトに設定したEPUB3サンプルを作成し、ブログにアップしたのですが、どうも挙動を観察した限りではkobo touchはEPUB3 Fixed Layoutに対応しておらず、コンテンツはリフローで表示されているようです。指定ページでフォントサイズを変更できてしまうことからそれがわかります。また、iPadのkoboアプリもどうやらページごとの固定レイアウト指定には対応していない様子で、全体の指定がリフローか固定レイアウトかのみを見て表示を切り替えるため、こちらも全体がリフロー表示されていました。
　データをReadiumで開きますと固定レイアウトのページの周囲のみに枠が表示されるため、きちんと一部ページ固定レイアウトの指定はできているようなのですが、まだまだビューア側のEPUB3固定レイアウト対応は不十分といったところでしょうか。
　ただ、このkobo touchの固定レイアウト非対応という仕様を逆手に取れば、「iPadのkoboアプリやiBooksでは固定レイアウトで表示され、kobo touchではリフロー表示される」ちょっと面白い仕様のEPUB3ファイルが作成できそうかなと考えましたので、挑戦してみました。

1　メディアクエリを設定してEPUBをパッケージ化

ヘッダ行にメディアクエリを記述

　前回同様にまずこちらの手順で作成したXHTMLデータを流し込み、FUSEeβで固定レイアウトEPUBパッケージを書き出しますが、今回は異なるデバイスでそれぞれに最適化させた表示をさせるためにCSS3のメディアクエリを利用しました。メディアクエリ（Media Queries）というのは表示環境ごとに異なったCSSを適用するための設定で、画面の縦横のピクセル数などを検知して、適用するCSSを切り替えることができます。メディアクエリの設定についてはこちらなどが参考になります。
　今回はkobo touchとkoboアプリ／iBooksでCSSを切り替えて最適な表示をさせるために、これを利用します。
　kobo touchの横幅ピクセル数は600pxですので、これを境にCSSを切り替えることとし、XHTMLのヘッダー行に以下のように記述しました。

<link href="../style/kobotouch.css" rel="stylesheet" type="text/css" media="only screen and (max-width:600px)" />
<link href="../style/koboapp_ibooks.css" rel="stylesheet" type="text/css" media="only screen and (min-width:601px)" />

　これで横幅600ピクセルを境として「kobotouch.css」と「koboapp_ibooks.css」が切り替わります。

2　FUSEeβで固定レイアウトEPUBとして書き出す

固定レイアウトEPUB3パッケージを書き出す

　前回同様、必要なファイルの登録を済ませた後、とりあえずEPUB3パッケージとして書き出してしまいます。前回の経験でkobo touchがEPUB3固定レイアウトに対応していないことがわかりましたので、今回は固定レイアウトに対応しているiPadのkoboアプリ及びiBooksに合わせて、幅768px、高さ1024pxの固定レイアウトEPUBとして書き出しました。iBooksに対応させるため、今回は「iBooksを有効にする」のチェックボックスをオンにしました。

　なお、第3世代iPadの解像度は幅1536px、高さ2048pxですが、ここの指定（viewportの指定値）は幅768px、高さ1024pxで問題ないようです。iPhone版でも全体がそのまま縮小表示されるところを見ると、どうも縦横比だけを見ているのではないかと思われるのですが、そのあたりは専門ではないので深くは突っ込みません^※1。

3　拡張子をEPUB→ZIPに変更してパッケージを解凍する

　前回同様に作成したファイルの拡張子をEPUB→ZIPに変更し、パッケージを一度解凍します。これにより、XHTMLなど各ファイルの修正、CSSの記述・修正が行えるようになります。

4　「fixed-layout.css」へのリンクを削除する

fixed-layout.cssへのリンクを削除

　各XHTMLファイルにFUSEeβが自動挿入する「fixed-layout.css」へのリンクの記述を削除します。この自動挿入される「fixed-layout.css」の内容は<body>タグのwidthとheightの指定ですが、これが原因で解像度の異なるkobo touchで表示が崩れますのでリンクを削除し、メディアクエリで振り分けられる固定レイアウト用のCSSファイル「koboapp_ibooks.css」にこちらの記述を追記します。さらに「fixed-layout.css」ファイルそのものも削除します。

5　opfファイルを編集する

opfファイルを編集する

　ファイルが存在していないのにopfファイル内に登録が残っていますとバリデートチェックでエラーが出ますので、パッケージファイル「content.opf」をテキストエディタで開き、さきほど削除した「fixed-layout.css」ファイルの登録行を削除します。

<item id="style.fixed-layout.css" href="style/fixed-layout.css" media-type="text/css" />

　上記の行をまるごと消します。なお今回はファイル全体を固定レイアウト指定しましたので、前回行った固定レイアウト指定関連の修正は行っていません。

6　iBooks用表示指定ファイルを修正する

iBooks用表示設定ファイルを編集する

　EPUB3パッケージデータ内「META-INF」フォルダ内の「com.apple.ibooks.display-options.xml」をテキストエディタで開いて修正します。このファイルはiBooks用の表示指定ファイルです。ここに「<option name="fixed-layout">true</option>」とあるのがEPUBファイル全体の固定レイアウト指定の指示で、パラメータがtrueかfalseかでiBooksでファイルを開いた際のリフロー表示／固定レイアウト表示が切り替わります。
　今回は2行目の「<option name="open-to-spread">true</option>」の「true」を「false」に修正しました。この設定は最初にファイルを開いた際にページを見開きで表示するか、1ページを拡大して表示するかの切り替え設定です。今回は1ページを拡大して表示させる設定にしました。こちらの参考ページを見る限りではデバイスの画面の向きをロックすることなども可能なようですが、今回は設定しませんでした。また、EPUBファイル内にjavascriptを埋め込み、iBooks内で動作させる場合などは、ここで「interactive」の設定を「true」にしておく必要があるようです。

7　CSSの記述・修正

iBooksでのサンプル表示

　CSSの調整を行います。今回は2種類のCSSをメディアクエリで分岐適用しますので、それぞれの画面サイズごとに設定を順次追い込んでいきます。今回はDreamweaverを利用してデバイスをシミュレーションしながら設定し、最終的な調整はパッケージングしたEPUB3ファイルを各デバイスで開いて表示を確認しながら行いました。
　なお今回は、koboアプリ／iBooksでは2段組で一部の写真を裁ち落とし的に配置して雑誌風のレイアウトを狙い、kobo touchでは画面横幅一杯に写真が表示されるようにしています。

8　EPUB再圧縮、kobo／Readiumで確認

　EPUBデータを再圧縮し、ビューアで最終確認します。圧縮の方法などは前エントリステップ8のリンクをご参照ください。

◇

　以下から今回作成したサンプルデータをダウンロードしていただけます。kobo touch（リフロー表示）、iPad版kobo App（フィックス表示）、iBooks（フィックス表示）のほか、Mac版およびWindows版のReadiumで表示を確認しています。ただしフォントサイズは固定で大きくすることができず、Readiumには画面拡大の機能はないため個人的にはおすすめしません。おそらく文字が小さすぎるものと思います。Macで読む場合にはフィックス表示には対応していませんがMurasakiが比較的読みやすいようです（ただし文字を拡大するとレイアウトが崩れます）。
　また、iPhone版のkobo App／iBooksでも閲覧は可能ですが、やはり文字が小さすぎますので、固定レイアウト関連の記述のみを削除したiPhone用バージョンを作成しました。画面の横幅に合わせてリフローで表示されます。きちんと表示をCSSでコントロールするようにしておけば、こうした複数デバイス向けの展開も比較的簡単に行えます。

＞＞TravelogueVietNum ダウンロードはこちら

※ダウンロード先を私の所属する会社のホームページ内ダウンロードコーナーに移動しました。内容の改訂等は行っていません。

※1　viewportの指定値に関しては参考ページに、横738px、高さ985pxでの指定例があるなど、今ひとつ最適な値がわからない感があります。いずれより詳しい情報が手に入ったら別エントリで報告できるかもしれません。

（2012.9.10）

EPUBパッケージ内のIDPFのバリデータを通らない記述を修正しました。

（2012.10.29追記）

ダウンロード先を私の所属する会社のホームページ内ダウンロードコーナーに移動しました。内容の改訂等は行っていません。

（2012.12.25追記）

タグ: EPUB3 Fixed Layout, iBooks, kobo, サンプル, メディアクエリ
カテゴリー: 未分類 | コメントはまだありません »

第39回出版UD研究会セミナーに行ってきました

2012/09/05

　第39回出版UD研究会「情報アクセシビリティの世界から見た本のアクセシビリティ」に行ってきました^※1。ゲストスピーカーはIBMフェローの浅川智恵子さんで、中学校時代に事故で失明されていながら努力の末にIBMに入社され、点字翻訳システムや視覚障がい者用ホームページ読み上げシステムの開発など情報アクセシビリティの研究を続けてこられた方です。ちょっとどれだけの努力をすればそれが可能なのか見当がつきません。本当に頭が下がります。

　一般的にアクセシビリティの確保といいますと、高齢者・障がい者を含む誰もがサービスやコンテンツにアクセスできるようにすることを指し、わかりやすいところでは建物におけるバリアフリー設計などがそれにあたります。
　今回のセミナーでは、視覚障がい者向けの点字翻訳技術や音声読み上げ技術、スマートフォンなどを利用したクラウド経由での障がい者支援システムについての説明の後、書籍のアクセシビリティ確保のための電子化に関する話があり、なかなか興味深い話を聞くことができました。

　これまでの決められた判型・フォントサイズで印刷される紙の書籍では、アクセシビリティの確保と言っても、大きめのフォントサイズで印刷することや、高齢者向けに拡大版を出すといったような対策しか考えようがなく、コスト面での制約から商業ベースで多くの書籍をアクセシブルにすることは難しいものがありました。この結果、点字翻訳や音声録音といった視覚障がい者向けコンテンツの制作は、我が国ではもっぱらボランティアベースで行われてきたのが実情です。
　しかし、読者が手元の設定で文字サイズを変えられるリフロー型の電子書籍では、このあたりは商業ベースの出版物でもぐっと身近な考え方になってきます。むしろ、視覚障がいや老眼などの理由で従来の紙の書籍を読むことが難しい層であっても、電子書籍であれば読むことができるというのであれば、それはこれまで取りこめていなかった消費者層の取り込み、売り上げ増加に繋がってくる決して小さくないファクターになってくるとも言えそうです。
　これに加え、特に教科書などの公的性格の強いコンテンツは、今後法令によって一定レベルのアクセシビリティが求められる可能性があるとの話もあり、制作サイドがどういった考え方を持って電子コンテンツを作っていくべきなのか最初にしっかり確認しておくことはとても大事と思います。

　ということで、今回のセミナーの説明に入ります。最初にお話のあった黎明期の視覚障がい者向けリーディングシステムの話も面白かったのですが、今後のコンテンツ制作に直接つながる話ではないので省略させていただき、まずは視覚障がい者の音声認識スピード及び、音声読み上げ技術の話からです。

早く読む技術、ナナメ読みの技術

　まず、視覚障がい者は健常者に比べてずっと早いスピードの音声を認識できるという話があり、これはなかなか興味深いものがありました。実際に音声の高速読み上げデモも行われたのですが、私などでは到底何を言っているのかわからない2倍速での再生でも、視覚障がい者の方は普通に聞き取れてしまうとのこと。また、ホームページ読み上げに関連したナナメ読み／要約技術のデモもあり、ぐるなび等の口コミ評価サイトの要約デモが行われていました。これは投稿レビュアーによって書き込まれた各店舗の大量のレビュー記事の中から「良い／悪い」という言葉およびそれに類する言葉を含む段落だけを自動抽出し、読み上げる技術とのことで、実際に聞いてみると確かに大づかみにその店の評価を知ることができます。
　これは視覚障がい者向けだけではなく、例えば目で文章を追いにくい運転中に使うカーナビ等と連携した利用にもニーズがありそうかなと感じました。また、現状読み上げ技術は高齢者向けなどの実装が中心で、視覚障がい者向けの速読技術はニーズが限られているために技術開発が進みにくい面があるとのこと。このあたりは今後の対応に期待がかかるところです。

クラウド・アクセシビリティ／ソーシャル・アクセシビリティ

　コンピュータによる自動認識では足りない部分を、多数のボランティアによる人間の知能で補うことで総合的に優れたサービスを実現する試みも数多く試みられているようです。例えば視覚障がい者がスマートフォンの専用アプリで撮影したものをクラウドサーバーに送って自動画像認識し、音声で読み上げるようなシステムで、認識できなかったものはクラウドサーバー経由でボランティアの元に送られて人間の目で確認、文字入力されて結果が音声で読み上げられる、といったようなソリューションのデモが行われたのですが、なかなか興味深かった点として、単純にボランティアの補正によって補完するだけではなく、認識結果はコンピュータ側に記録としてフィードバックされて自動認識エンジンの改良に使われるとのこと。これはおそらく検索エンジンの画像認識など一般ユースへのフィードバックも含んだ考え方と思われます。ただ、こうしたクラウド連携サービスは現状英語ベースのサービスがほとんどで、日本語の認識という意味では難しい面があるとのことでした。

アクセシブルな電子書籍制作の課題

　さて、本命です。まずは電子書籍制作のコストのお話から。アクセシブルな電子書籍を制作するには、画像をスキャンしてパッケージングするだけではなく（レプリカフォーマット／緊デジフィックス型）、きちんとテキスト起こしをし、構造化する必要があるとのお話がありました。この「きちんとテキストベースで制作され、構造化された電子書籍である」ということが、実際のところ最低限のアクセシビリティの保証とほぼイコールになってくるようです。iBooksなどにはすでにEPUB3文書の合成音声読み上げ機能が実装されていますので、これは確かに頷けるところがあります。
　この構造化テキストの制作工程で特にコストがかかるのは、OCR処理されたテキストを校正する工程、構造化する工程とのことで、特に日本語は26文字しかないアルファベットに比べて圧倒的に文字数が多く、さらに縦組み／横組みの混在、多言語混植、ルビや圏点の存在など欧文書籍にはない要素が多数あるため、OCR処理の技術的ハードルがとても高いとのこと。従ってOCR処理後のテキストに必然的に間違いが多く、校正のコストが高くつくとのお話で、これは制作現場の経験からもその通りと思います。

　またこれは質疑応答の後に関係者の方に確認した話なのですが、現状日本語OCRソフトはShift_JISの範囲の文字認識がせいぜいで、Unicodeの範囲をきちんと認識できるものはおそらくないだろうとのこと。つまり、JIS第3・第4水準漢字は現状OCRでは認識できないと考えた方が良さそうです。さらに、以前のエントリーでも書かせていただいたように、印刷物の制作に使用できる文字の数はUnicodeで使用できる文字の数を上回りますので、こうしたUnicode領域外の異体字などは当然OCRでの自動テキスト化は期待できません。日本語書籍の電子化が遅々として進まないのはこうした部分にも一因があるのではないでしょうか。

　海外ではBookShareというサービスが存在し、国のサポート、ボランティアの支援によりベストセラー書籍が出版された翌日には点字／DAISYフォーマット化されて入手できるルートが整っているとのことなのですが、上記の理由により日本では同一のモデルの成立は困難だろうとのことです。こうした部分を解決するには、日本ではやはり出版社自身による紙書籍と電子書籍の同時刊行が必要になってきそうです。

校正作業のゲーム化、パスワード認証との連携

　日本語書籍に比べればまだマシとは思いますが、アルファベット圏でも過去の印刷物のテキスト化に伴う校正のコストに頭を悩ませているのは同じです。そうしたコストを削減するための海外でのさまざまな試みの紹介がありました。
　オーストラリア国立図書館の校正作業の一般開放の試み（Trove）や、フィンランド図書館の校正作業をゲーム化して一般公開する試み（Digitalkoot）などの紹介があったのですが、特に面白かったのはGoogleが買収したパスワード認証システム、reCAPTCHAについての説明です。

　ゆがんだテキストを目で確認して入力することでサイト認証を行う仕組みはすでにあちこちで目にするところなのですが、reCAPTCHAはこれを一歩進めて、パスワード認証用の画像と並べてOCRでの文字認識に失敗した画像を配置し、利用者に双方を入力してもらうことで無数のユーザーに無意識のうちに校正作業に参加してもらうというシステムで、これはすでにGoogle Booksでの書籍電子化にも利用されているとのこと。集合知によって厖大な作業量をカバーする、いかにもGoogleが好みそうなアプローチです。
　Webで調べた限りではこのreCAPTCHAの出題項目に日本語や中国語が出てくることもあるようです。これはGoogle Booksプロジェクトで電子化するためにスキャンしたテキスト画像が自動で振り分けられているものと思われます。英語文化圏の住人に日本語文書の校正入力をきちんと行える人がそう多くいるとも思えないので、あるいは国別に割り振りが行われていたりするのでしょうか。

　また、OCRの認識精度向上のために人間の入力結果を利用する試みもヨーロッパの図書館や公共研究機関を中心に盛んに行われているとのことで、これは是非、日本の研究機関や関連企業にも頑張っていただき、せめてJIS第3水準、第4水準漢字レベルの認識が可能なOCRソリューションに早く登場して欲しいと思っています。素人考えですが、一度文字レベルで自動認識させた仮テキストを、辞書と連携した熟語認識エンジンで整合性チェックする、といったような仕組みでOCR処理の精度アップが図れないものでしょうか？

◇

　最後に、電子書籍のアクセシビリティ確保について制作サイドが心がけるべきことを、以前のセミナーでDAISY関係者の方にお聞きした話なども含めて簡単に箇条書きしておきます。

きちんとテキスト化し、きれいに構造化されたEPUB3であれば読み上げは可能。最低限のアクセシビリティは確保できている。
読み上げ対応EPUB3の構造化言語はDTBookでなくて良い。XHTMLでOK。
画像のalt（代替文字）属性に、適切な内容を入力しておくことが重要。画像ファイル名とかはNG。
「○○ページ上図参照」などの書籍内の位置に依存する表記はアクセシビリティの確保に支障をきたす。
今後、高齢化や法によるアクセシビリティ確保の義務化などにより、アクセシビリティ対策は重要度を増していく可能性が高い。

※1　第39回出版UD研究会　togetterまとめhttp://togetter.com/li/366078

（2012.9.05）

タグ: アクセシビリティ, ユニヴァーサル・デザイン, 出版UD研究会, 音声読み上げ
カテゴリー: 未分類 | 1 件のコメント »

‘2012/09’ カテゴリーのアーカイブ

iPadとkobo touchで固定レイアウト／リフローを切り替える

1 メディアクエリを設定してEPUBをパッケージ化

2 FUSEeβで固定レイアウトEPUBとして書き出す

3 拡張子をEPUB→ZIPに変更してパッケージを解凍する

4 「fixed-layout.css」へのリンクを削除する

5 opfファイルを編集する

6 iBooks用表示指定ファイルを修正する

7 CSSの記述・修正

8 EPUB再圧縮、kobo／Readiumで確認