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

JEPA第11回・12回セミナーまとめ

2012/07/31

 7月24日に飯田橋で行われたおよび、第11回セミナー「EPUB3と文字」および、JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」に参加してまいりました。と申しますか、光栄にもJEPA技術主任の村田真さんにご指名いただき、講師の一人として壇上で話すという人生初の体験をしてまいりました。ご来場いただいたみなさま、ありがとうございます。ということで今回は第11回および第12回セミナーのまとめです。

JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」

 後から急遽開催が決まった関係で、第11回セミナーと12回セミナーが同じ日に行われ、第12回セミナー「ISO国際標準と固定レイアウトWS」の方が早い時間に行われましたので、ここでも第12回セミナーについて先に書こうと思います。第12回セミナーはIDPF理事の小林龍生さんのご挨拶の後、村田真さんのセッション。2本立てで前後に区切って行われました。

前半:EPUB3のデジュール標準化の状況

 EPUBは2012年に急速な伸びを見せ、2013年にもやはり急速に伸びることが見込まれる、という説明からスタート。「デジュール標準」というのはJIS、ISO、IECのような公的な標準化機関によって制定された標準規格とのこと。EPUBはこれまで、IDPFという業界団体が制定した「フォーラム標準」という位置づけで、これをより認知度が高く、公的機関の文書、特に教科書での採用において必要となる「デジュール標準」へ格上げする道筋が整ったとのお話でした。

 デジュール標準化へ至る道には、標準化を希望する団体が複数存在したことや、フォーラムとデジュールの綱引き、EPUB3の基幹技術であるHTML5やCSS3がまだ完全には定まっていない不安定な状態であることなどさまざまな障害があったようですが、これらはほぼクリアの見通しが立ち、2013年中にはデジュール標準化へ向かうようです。

 これによって、今後は政府調達や教育市場でのEPUB採用が期待できるだろうとのことで、すでにデジタル教科書や問題集の標準化も始まっているとのことでした。

後半:Advanced/Hybrid Fixed Layoutsワークショップ報告

 後半はEPUB3固定レイアウトワークショップについての報告です。
 今回は「Advanced/Hybrid Fixed Layouts」とのことで、より高度で、紙のレイアウトを超えるような固定レイアウトに関してのお話でした。

 まず、EPUBのレイアウトの現状確認の中で、より複雑なページテンプレートを用いたリフローに関するお話がありました。これは、Adobeから提案があったものを仮実装したものがIDPFにはあるとのことだったのですが、まだEPUB3のコアモジュールと見なされてはいない状態で、今後どうなるかも不透明とのこと。

 本番のEPUB3固定レイアウトに関しては、まずは現状の各種固定レイアウト方式、固定レイアウト語彙の説明からだったのですが、これはいわば「おさらい」ですので、詳しくは述べません。こちらなどが参考になるかと思います。
 さて、本番セッションですが、

1. 村田真:Three Types of Digital Comics

 コミックの電子化には、
 ・紙→デジタル
 ・デジタル→紙
 ・デジタルのみ、紙を考えない
 この3つの分類があり、3番目のものではそもそもコンテンツとしての語法が大きく変わってくる、とのお話。ちなみに韓国ではすでにもう3番目のパターンがほとんどになっているとのこと。日本でも遠からずデジタル先行になっていくのでしょうか?

2. Aquafadas:Fixed Layout Reading Experience for Comics, Children Books, Table Books

 フランスのAquafadas社の発表内容の紹介で、レイヤによって日本語版のマンガに他社別売の英訳を電子書籍端末上で重ね合わせる、マンガへのアニメーション効果を重ねあわせるといったようなことや、シーンとショットを別レイヤで定義しておくことで、画面の小さな端末でも快適なコミック閲覧ができる、といったような内容でした。
 これは単に技術面のお話だけではなく、訳やエフェクトを他社が制作して読者が端末上で重ね合わせて読める、といったようにビジネスモデルにまで踏み込んでいるあたりがなかなか面白く感じられました。

3. 集英社:Introduction to the OMF format

 OMFとは「Open Manga Format」とのことなのですが、集英社の作成したEPUBの仕様に乗っ取ったマンガ配信フォーマットということのようです。JPEGを並べただけのBasic.opfの他に、Javascriptですべてを記述したAdvanced.opfという仕様があるとのこと。Basic.opfが電子ペーパー端末用、Advanced.opfがiPadのような液晶タブレット用といったような位置づけでしょうか。同一パッケージ内に双方の文書を格納し、デバイス毎にどちらかを選択して読むというような仕様とのこと。

4. Barnes & Noble:Rendition Mapping

 イメージ画像とHTMLによるリフローを使い分けて表示する方式とのことで、イメージの中に対応するHTMLへの情報を埋め込む方式が「Rendition Mapping」とのこと。これはすでにB&Nの端末で使われている方式のようです。ちょっとモリサワの「MCMagazine」に近い印象を受けました。もちろん「MCMagazine」はEPUBではないわけですが。

5. ソニー:EPUB 3 Rendition selection

 ひとつのEPUB文書の中に複数のパッケージ文書を入れ込む仕様のお話でした。EPUBでは複数のパッケージを同一文書に入れ込むことができるとのことなのですが、これにCSSのメディアクエリを組み合わせることで、サイズの異なる端末用に複数のパッケージを入れておき、自動的に切り替えて表示するといったようなことが可能になるようです。これが実現すれば、iPhoneとiPadの双方に同一パッケージで対応できる固定レイアウトEPUB文書が制作できるようになってくるわけで、なかなか期待感があります。もっともその分制作サイドは大変になりそうですが。

6. 富士フイルム:Rendition Mapping for Manga – Fujifilm Proposal

 マンガにおけるRendition Mappingの実際における発表だったようです。見開きのページはひとつの画面として扱わないと表示が破綻してしまうとのこと。確かにページをまたいだ書き文字などを見ると、そのあたりは想像がつきます。

 といったような説明がありました。
 また、論点として、Javascriptを積極的に使ってEPUB3固定レイアウトの記述をすべきかどうか、HTMLやCSSといったWeb技術を表示に多用するとバッテリー消費が激しくなるため、表示には画像を利用するべきではないか(B&N)、規格策定の優先順位をどうすべきかといったことが上がってきたようです。
 今後、年末までに何らかの成果を出すべく規格策定の動きが始まるとのことで、引き続き要注目です。

JEPA第11回セミナー「~EPUB3と文字~」

 IVS技術促進協議会とJEPAの共同開催という形で行われたセミナーでした。IVS(異体字セレクタ)は電子書籍で使用できるテキスト上で人名漢字などで用いられるような漢字の異体字字形を再現するために期待されているテキストの拡張仕様で、今は電子書籍の立ち上がり時期にあたるだけに関心も高く、結局150人を超える参加者が来場されていたようです。

国語施策と漢字コード:小林龍生

 まずはユニコードコンソーシアムのディレクターで、IDPFの理事でもあるIVS技術促進協議会の小林龍生さんから、JIS、ユニコードなどの変遷と今後の問題点についての基本的な説明がありました。
 最初に、字種/字体/字形の説明から。「学」と「學」は同じ字種だが異なる字体で、さらにその下に細かな字形の差異があるとのお話がありました。情報交換の観点から見た場合、符号化は字種のレベルにとどめるのが理想だが、実際には字体レベルでの包摂/統合は不可避で、ただ字形のレベルにまで踏み込むと本当にきりがないとのこと。
 また、そもそもの字形の揺れ問題の発端は、78JISと83JISの改訂に端を発するのではないかという意見を述べておられ、これは現場サイドとしても良くわかるお話です。

 さらに、表外漢字字体表と印刷標準字体の話の絡みで、策定時期の関係でJIS2000の例示字形には表外漢字字体表が反映されなかった経緯についての説明がありました。これにより、JIS2004で168文字の例示字形変更が必要になったとのことです。この168文字の変更には微細なデザイン差の変更も含むとのことで、字体レベルでの変更は100の符号位置に留まるとのこと。この100符号位置の字形をテキスト上で変えるにはIVSが必要になってくるようです。

 ただ、そうした区別が本当に必要かどうかは、検索の利便性などの観点から、利用者は良く考え、最低限に止めるべきなのではないかとのご意見を述べておられ、これは外字の画像化にも通じる論点ですのでとても共感できます。あまりも多様な漢字の字形差全てを電子書籍上で再現しようとすることは、制作コストにも直結してくる大きな問題と思います。

マイクロソフトが実現する新たな文字の世界:田丸健三郎

 マイクロソフトの田丸さんからの、第一世代Shift_JISからJIS2004対応に至るOSの文字コード対応の歴史次期Windows、OfficeでのIVS対応についてのお話でした。
 さらに基本文字+IVSシーケンスで異体字を表現するIVSの基本的な仕組みや、フォントやアプリケーションがIVSに非対応であっても基本文字は表示されることが期待できるために、完全な文字化けと言ったようなことにはならないIVS技術の特色などに関してもひととおりのご説明がありました。
 また、ユニコードの符号化方式(UTF-8/UTF-16)と符号化文字集合(Unicode 6.0 etc)の関係に関しても説明があり、基本的な部分ですがきちんと押さえておく必要はありますのでなかなか面白く聞かせていただきました。

 マイクロソフトのOSにおける日本語文字コードの変遷は、1982年のMS-DOS2.0におけるShift_JISの採用に始まり、Windows3.1でのマイクロソフト標準キャラクタセット(cp932)採用Windows98以降でのユニコード対応へと進み、Windows Vista以降でサロゲートペアを含むJIS2004に対応したという流れとのこと。

 マイクロソフトは次期WindowsではIVS文字の入力にOSレベルで対応するとのことです。デフォルトでIVSが入力できる状態ではなく、チェックボックスをオンにする必要はあるとのことですが、いずれにせよ外部からデータを受け入れる可能性のある印刷会社/制作会社は、今後IVSが使用された原稿の受け入れ体制を整える必要がありそうです。
 また、Officeでの対応に関しては、次期Office製品でIVSに正式対応するだけでなく、Office2007/2010でもデータ互換のためにOffice IVS Add-inによる移行パスが提供されるとのこと。

 今後電子書籍の時代には、編集者・校正者・作業者が同一の文字環境で作業するような環境を構築し、OSやフォントに起因する字形の揺れをあらかじめ抑止することが、スムーズな作業の流れのために最低限必要となってくるように思います。

DTPデータから電子書籍を制作する際の「外字」問題:田嶋 淳

 田丸さんのあとが私のセッションでした。内容的にはこちらのブログに掲載したものと重複する点が多くありますので詳述はしませんが、InDesignのデータからテキストを抜き出した際に起きる字形変化の理由および、どういったパターンの字形変化が存在するのか、今後電子書籍・印刷データ双方の制作環境はどういった方向性を目指すべきかといった点に関していささか拙いながら述べさせていただきました。

 当日配付させていただいた資料を以下からダウンロードいただけますので興味をお持ちの方はご覧いただければ幸いです。また、epubcafeのページにYoutube動画へのリンクもありますので、あわせてご覧下さい。

 なお、この内容に関連して、小形克宏さんの制作された技術者・ソフトウェア開発者向けのより詳細な資料が、出版デジタル機構ホームページ内「技術部だより」より、近日中にダウンロード可能になります。

 この外字の問題につきましては、「では現状どうすればよいのか」というご質問を何度かいただいたのですが、ソフトウェアを用いて完全に対処することが難しい以上、最後は目視での校正作業に頼らざるを得ないのが現状です。こうした作業を少しでも軽減するために、InDesignの「代替字形」チェックボックスの活用や、スクリプトを用いて内部文字をチェックすることで対処が必要な文字をある程度洗い出すことは可能ですが、いずれにせよ最終的にきちんとした品質を確保するには全文の目視校正作業が不可欠と思われます。

IVSとのつきあい方:狩野宏樹

 株式会社イワタの狩野宏樹さんのセッションで、現状でのIVS対応フォントの状況OSの対応状況IVSを使用する上での基本的な注意点についてのお話でした。

 IVS対応フォントは、小塚明朝Pr6N小塚ゴシックPr6NがInDesign CS4にバンドル提供されたのを皮切りに、2011年1月にイワタから発売された52書体游明朝体Pr6/Pr6N R筑紫明朝Pr6/Pr6NイワタUDゴシック/イワタUD丸ゴシックなど、現状100フォント以上が利用可能になっているとのことです。

 OSとしてはWindowsは7以降で異体字が表示され、Vistaでは異体字は表示できないもののIVSシーケンスが無視されて基本文字が表示されるため、読み取り自体は可能とのこと。XPではIVSの文字自体が文字化けして表示されてしまうようです。Mac OSは10.6以上で表示に対応、10.7以上ではバンドルフォントのヒラギノProNがIVSに対応しているとのことです。

 また、アプリとしてはInDesignはCS4でIVSに対応していますが、IVS文字を親文字とは別々に選択できてしまう仕様のため、IVS文字だけが残ってしまう危険がある点を指摘されていました。また、IVS文字にルビをかけた場合、直前の文字にルビが存在しない場合、IVS文字が化けてしまうバグが現状で存在するようです。直前の文字に全角スペースのルビを振ることで対処療法として回避は可能ですが、将来的に改善を期待したいところです。

 さらに、IVSは漢字のみにしか使えないものであること、IVSが必要な文字がどれなのか直感的な区別が難しいこと、IVSのコレクションにはAdobe-Japan1以外にHanyo Denshiがあり、双方で異体字の重複があること、IVSでは異体字が表示されない場合でも基本字形は表示され、特に文字化けの警告等は表示されないため、InDesign等で文字変化を発見しにくい危険があることなども指摘されており、このあたりは今後の課題として十分な注意が必要そうです。
 加えて、フォント側として全てのIVS仕様文字への対応が求められるわけではないため、フォントが目的の異体字に対応していなければ基本字形に変化してしまうといった状況が起こり得るとのこと。

 さらには、IVSとGSUBを併用することは避けるべきで、IVSならIVSで統一すべき、とのお話もあり、本格的な運用までにはまだ若干の課題が残っているようです。

(2012.7.31)

先頭文字/行/正規表現スタイルの処理を考える

2012/07/09

正規表現スタイル

正規表現スタイル

 InDesignには、「段落スタイル」設定内の「ドロップキャップと先頭文字スタイル」から設定できる「先頭文字スタイル」および「行スタイル」、同じく「段落スタイル」設定内で使用できる「正規表現スタイル」といった便利な機能があります。これらは全て、段落スタイルの適用されている行内の文字のうち、設定した特定の条件に適合する文字に自動的に指定した文字スタイルを適用する機能です。例えば「先頭文字スタイル」であれば、文中の数字だけを自動的に斜体にする、「行スタイル」であれば1行目だけを太字にするといったような、通常長時間の反復処理が必要になる作業を段落スタイルの設定のみで処理できます。「正規表現スタイル」はさらに自由度が高く、正規表現を用いて適合する文字列を指定できます。例えば「A」「B」「C」だけを太字にする、いったような処理も簡単に行うことができます。ここでは正規表現そのものについては触れませんのでこちらをご参照ください。
 これら特殊スタイルはInDesign内では「段落スタイル」のみが適用されており、文字スタイルは「なし」になっているように見えるため、電子書籍制作時にきちんとした処理がされるのかどうかちょっと気になるところです。

 そこで、実際の電子書籍制作時の流れの中で、これら特殊スタイル類がどのように処理されるのか試してみました。

「スタイルをタグにマップ」で正常にタグが付加されないパターンがある

行スタイルのタグに問題が出る

行スタイルのタグに問題が出る

 最初に、私がこちらのブログ内で紹介しているあらかじめ各文字に段落スタイル・文字スタイルを適用しておき、「タグ」パレットの「スタイルをタグにマップ」でタグを付加してXML書き出しを行う方法をテストしました。

 まずはシンプルに「先頭文字スタイル」「行スタイル」「正規表現スタイル」を単体で適用してみます。「先頭文字スタイル」および「正規表現スタイル」についてはきちんとタグが付加されているようですが、「行スタイル」に関しては、最後の一文字に正常なタグ付加がされていないようです。

重ねがけで正常にタグが付加されない

重ねがけで正常にタグが付加されない

 次にこれら特殊スタイル類の重ねがけを試してみます。「行スタイル」を含んだ段落のタグが全て1文字ずつずれて適用されている他、「先頭文字スタイル」と「正規表現スタイル」との重ねがけに関しても、「先頭文字スタイル」のみがタグ付加され、「正規表現スタイル」の部分にはタグが付加されていません。これではちょっと危なくてタグの自動付加はできません
 なお、「行スタイル」の最後の1文字にタグが付加されないのは、バグの類ではないかと思われます。

IDMLには文字スタイルが書き出されない

XMDFビルダーに文字スタイルが取り込まれない

文字スタイルが取り込まれない

 次にIDML(InDesign Markup Language)形式でデータを書き出し、XMDFビルダーに取り込んでみます。これは緊デジのXMDF制作ガイドラインで想定されている制作方法です。

 どうやら、特殊文字スタイル類は完全に無視され、段落スタイルのみが取り込まれるようです。つまり、XMDFビルダー内で全ての文字スタイルを再割り当てすることになってしまいます。これはちょっと作業量的に避けたい流れです。

文字カラーを変更し、検索置換パレットを使用して文字スタイルを再適用する

 さて、結局どちらにしても文字スタイルの再適用は避けられそうにありませんので、出来るだけ楽をしてスタイル再適用の作業を行いたいところです。とりあえず以下のようなワークフローを考案してみました。なお、このワークフローを使用したことに伴うトラブルに関して、私として一切の責任は負いかねますので、こちらの作業を行う前には必ず元データをバックアップしておき、コピーしたデータで作業を行うことをおすすめします。

1 文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

 まず、先頭文字/先頭行/正規表現スタイル内で使用されている文字スタイルの「文字カラー」を変更します。多色刷りなどのデータの場合には、登録済みのスウォッチカラーがドキュメント内のいずれかの箇所に使われている可能性を考慮し、トラブルを避けるためにもスウォッチを新規作成して割り当てることをおすすめします。

2 先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭文字/正規表現スタイルを手動処理

 先頭行スタイルと先頭文字/正規表現スタイルが混在している場合は、まず先頭行スタイル内の先頭文字/正規表現スタイルに手動で通常の文字スタイルを再適用します。これは、3の検索置換処理で先頭行スタイル内の先頭文字/正規表現スタイルが検索にヒットしないためです。

3 パラメータを設定し、検索置換を実行

検索置換パラメータを設定

検索置換パラメータを設定

 検索置換パレットの「検索形式」に1で設定したカラーを、「置換形式」に1で文字カラーを変更した文字スタイルをそれぞれ指定し、ドキュメント全体に対して置換を実行します。全ての文字スタイルに関して同様の置換を実行します。

 これでとりあえず文字スタイルの再適用はできます。「行スタイル」内の先頭文字/正規表現スタイルを手動処理しなければならない問題はありますが、幸い「行スタイル」はそれほど頻繁に使用されているわけではないように思えますので、実作業的にそこまでの問題はないかと思います。
 また、「タグ」パレットの「スタイルをタグにマップ」でタグを付加する際のトラブルを防ぐため、文字スタイルの再適用を行った後に「スタイルをタグにマップ」を使用する場合には、全ての特殊スタイル類をあらかじめ削除しておいた方が良いでしょう。

 なお、「正規表現スタイル」の通常文字スタイルへの置換に関しましては、市川せうぞーさんが「正規表現スタイル由来の文字スタイルをリアル文字スタイルとして適用する」というエントリーで自動処理スクリプトを発表されておられますので、そちらを利用されるのも良いかと思います。

(2012.7.9)

市川せうぞーさんより、「正規表現スタイル」2つ以上を重ねがけしている場合でも「スタイルをタグにマップ」で正常にタグが付加されないとの情報をいただきました。例え「正規表現スタイル」だけしか使われていない場合でも、文字スタイルの再適用が必須になると考えておいた方がよさそうです。

(2012.7.9追記)

国際電子出版EXPO行ってきました

2012/07/06

 ビッグサイトで開催中の第16回国際電子出版EXPOに行ってきましたので、今回はプチレポートです。私が行った水曜の午前中には国際講演が行われ、それももちろん聞いてきたのですが、すでに新聞やニュースで大きく取り上げられており、個人ブログで改めて書いても仕方がありませんので、会場で見てきて個人的に面白いと感じた製品をいくつかレポートしてみたいと思います。

FUJIFILM 「GT-Layout」

 FUJIFILMさんがコミックの電子化等の製品開発にかなり前から取り組んでおり、画像処理の自動化まわりなどで精力的に製品発表をされていたのは知っていたのですが、私の所属している会社のような文章物の制作をメイン業務にしている会社にとってはこれまで今一つ直接的なニーズのありそうな製品はありませんでした。
 ただ、今回展示されていた「GT-Layout」という技術は、スキャンして1ページまるごと1画像になっている文書を、自動処理で1文字ずつバラバラの外字にして並べ替えることで疑似的にリフローを実現するというもので、完全に「こっちの領域」の技術です。発想にちょっと目から鱗が落ちました。技術的にはOCR技術を自動テキスト化処理ではなく、画像内の文字位置の特定に使っているとのこと。力技ですが確かにそれなら文字化けはなさそうです。

 この技術は今のところまだクラウドサービス「Dropbox」内に放り込んだ画像ファイルや各種オフィス文書を、Androidスマートフォン上で快適に読むためのアプリ「GT-Document Lite for Dropbox」内でのみ使用できるようなのですが、もしこれがEPUB制作アプリ等と連携して使えるようになれば、例えば緊デジで制作されたフィックス型の電子書籍のうちかなりのものを、比較的簡単に疑似リフロー型にコンバートすることが可能になってきます。

 また、印刷会社が保有している製版フィルム等のスキャン画像から、全文校正の手間なしにリフロー型電子書籍を制作することも視野に入ってきます。私の所属している会社に保存してある製版フィルムには、活版印刷の時代に組版されたものをフィルム化して保存してあるものなども多数含まれるのですが、これらはそもそもテキストデータが存在しないため、リフロー型電子書籍にするためには、本来全文の再テキスト入力・校正が必要になってきます。これがコスト面の壁になって電子書籍化できないコンテンツはおそらく多数あります。「GT-Layout」の技術によってこれらのフィルム類も手軽に疑似リフロー型電子書籍にコンバートでき、スマートフォン等で快適に読めるようになるとすれば、「長期休眠コンテンツの価値再発見」にもつながってくる福音になり得ます。

「GT-Document Lite for Dropbox」画面

「GT-Document Lite for Dropbox」画面

 ちょっと現時点でどこまでのことが可能なのか気になったので、軽くテストをしてみました。新書横組みを想定した文書をInDesignで制作し、PDFで書き出したものをDropboxに放り込んで「GT-Document Lite for Dropbox」で開いてみます。なるほど、ちゃんとリフローしているようです。アルファベットが単語の途中で切れてしまっていることや字詰めなど気になる部分はあるものの、バックグラウンドでやっていることを考えるとすでにかなり完成度が高いと言えそうです。縦書き単行本のスキャン画像はエラーが出てリフローできなかったのですが、これはちょっと処理する文字量が多すぎたのかも知れません。「GT-Document Lite for Dropbox」自体はオフィス文書のビューアであることを考えれば致し方ないところです。電子出版EXPO会場では縦書きのデモサンプルがすでにあったことを付記しておきます。FUJIFILMの方にお聞きした話ですとまだルビまわりの処理などが完全ではないとのことだったのですが、正直かなり有望な技術だと思えるので、是非今後に期待したいところです。なんでも当面は「虫眼鏡のようなツール」としてユーザーの自己責任で使ってもらう方向を考えているとのことです。個人的には早くiPhone版が見たいです(笑)。

モリサワ 「MCBook」

 モリサワさんの電子書籍制作ソリューション「MCBook」は私も使ったことがあり、いくつかデモサンプルを作成しているのですが、もともと成果物の完成度という点ではピカイチだと感じていました。組版エンジンの柔軟さからくる画像の回り込み処理、キーワードをタップすることで呼び出せる注釈ウィンドウ、それになんといってもモリサワフォントの綺麗さが際立っていました。ただ、当初iOS用のアプリ型としてスタートした経緯からくるAppleとの契約の煩雑さや、独自タグ形式だったことが災いして、今一つメジャーにならなかった感があります。正直「このビューアでEPUB3見られたらなあ」とは思っていました。

 今回は、前バージョンで対応していたMCBookからのEPUB3書き出しに加え、ショップ向けソリューション「MCBook EPUB ビューアライブラリ」と連携することで書き出したEPUB3をストアで取り扱えるようになったことで、ほぼ「EPUB3対応」を謳える形になったようです。フォントやDRM対応を組み込み、専用ビューアを提供することで組版レイアウトの品質を保証する統合型サービスとして魅力的な存在になってきたと言えます。

 ただし、MCBookそのものからはDRMを含まないEPUB3のデータを書き出せるものの、「MCBook EPUB ビューアライブラリ」で扱えるEPUB3に関してはDRM組み込みがセットになっているようです。そのため成果物のEPUB3ファイルそのものの後修正は基本的に不可能で、修正の際にMCBookの書き出しもとファイルが必要になります。数年後に修正指示が入った場合、手元にMCBookのファイルが残っていなければ修正不可能になってしまうわけで、EPUB3の魅力のひとつであるプロプライエタリなフォーマットに依存しないオープン性をスポイルしているとは言えそうです。ただ、そこは統合型サービスならではの品質の高さの保証とのトレードオフになるのかなとも思います。そのあたりを割り切って使う「売り切り型贅沢コンテンツ向き」といった位置づけになるのではないでしょうか。

ボイジャー 「BinB」

 電子書籍の老舗、ボイジャーさんが昨年12月にスタートさせたWebブラウザだけで利用できる電子書籍配信サービス「BinB」がだいぶブラッシュアップされてきていました。当初はいまいち速度的に遅くイライラ感があり、いまひとつ魅力が伝わりにくい状態だったのですが、WebフォントのダウンロードでWindows XPなどの旧環境でもかなり綺麗な文字で読めるようになっており、電子出版EXPO直前に家でチェックした時には「これなら十分読めるな」と感じました。正直無線環境の整った場所でiPad等で読む分にはもうアプリ型電子書籍と大差ないのではないかと思います。だいぶ「Web閲覧環境があってIDとパスワードを覚えていさえすればどこでも読める」というBinBサービスのメリットが感じられるようになってきたのではないでしょうか。あとはラインナップですが、本家BinBストアにリイド社のコミックが入った他、「Yahoo!ブックストア」BinBのエンジンが採用されたとのニュースもあり、どうやらコミック分野でかなりの存在感を持ってきそうです。

 もともとBinBの「Webブラウザを利用してクラウド上のコンテンツを閲覧させる」というモデルは、読者の手元にパッケージがダウンロードされないため重DRMに頼らなくても違法コンテンツの流通を抑制しやすい側面があり、コミックなどのライトコンテンツには合っているのではないかと思っていました。ここにきて予測が当たった形で、少し嬉しく思います。

 といったところです。1日だけでしたので、興味はあっても回りきれなかったブースがたくさんあります。土曜日にブックフェアには行く予定なのですが、国際電子出版EXPOは金曜日閉幕・・・。まあ楽天koboの実機が触れそうなので楽しみではあります。今回はとにかく全体としてかなりの熱気を感じました。これが電子書籍の普及にストレートに繋がることを心から祈りたいです。

(2012.7.6)

※当初MCBookからはDRM付きのEPUB3しか書き出せないといった記述をしてしまったのですが、MCBookそのものからはDRMの含まれていない汎用のEPUB3も出力できるとのことです。失礼いたしました。謹んで修正させていただきます。

(2012.7.6追記)

プロフィール
Jun Tajima

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

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