News Letter Vol.008　電子出版セミナー

『国際標準規格EPUB3.0と印刷メディア市場』

2012年05月30日 13:30-15:30
日本教育会館８階　第２会議室

『EPUB3.0の現状報告』
　発表　電流協・EPUB研究会

(1)EPUB3.0　コンテンツの再現検証と課題について

　加藤好計(豊国印刷)、苣木 実（ちさき みのる）(大日本印刷)、遠藤亮正(凸版印刷)

　2012年３月時点のEPUB対応ビューアにおける、EPUB3で新たに追加された機能の表現について制作者側の視点から調査と課題の抽出を行ってきました。
　対象としたビューアは、次の通りです。
　・Adobe Digital Editions 1.8 Preview（ver. 1.8.2）
　・Kinoppy（ver. 1.1.0 Build 7788）
　・ACCESS（ver. 1.4.9）
　検証項目は、新たに加わった仕様のうち優先度が高いもの12項目を選定して調査を行いました。
　【EPUB3の表示：メタデータにversion="3.0"と記述したコンテンツの表示】
　すべてのビューアで正しく開くことができました。
　【フォントの埋め込み：コンテンツ内に含めたフォントの表示】
　Adobe・ACCESSは正しく表示されました。
　Kinoppyはビューアのフォントが優先され、表示されませんでした。
　【縦書き：CSSのプロパティwriting-mode: vertical-rl;をbodyタグに指定】
　すべてのビューアで正しく表示されました。
　【右開き：メタデータにpage-progression-direction="rtl"を記述】
　すべてのビューアで開き方向は正しく表現されました。
　Adobeだけカーソルキー操作と開き方向が逆になりました。
　【均等割：CSSのプロパティtext-align:justifyをpタグに指定】
　行末の禁則を行って文芸書のように上下が揃った表示をします。すべてのビューアで、正しく禁則処理が行われました。
　Kinoppyは、行の調整処理が適切でなく行末が空いてしまう部分が見受けられました。
　また、長い英単語がある場合、間隔が大きく空いてしまうことがありました。
　【縦中横：CSSのプロパティtext-combine: horizontal;をspanタグに指定】
　Kinoppyでは、表示されない・隣の行と重なるなどが起こりました。
　ACCESSは、画面の端にあると画面外に出た部分が見えない
　【圏点：CSSのプロパティtext-emphasis-styleをspanタグに指定】
　Kinoppyでは任意の文字の圏点は表示されず。
　Adobeは任意の文字の圏点の部分でビューアが強制終了してしまいました。
　【ルビ：ruby及びrtタグ】
　Adobeでは、熟語ルビのような形（<ruby>Ｅ<rt>い</rt>Ｐ<rt>ー</rt>Ｕ<rt>ぱ</rt>Ｂ<rt>ぶ</rt></ruby>）で、モノルビを記述すると、一文字目しか表示されません。
　肩付き・均等割りの指定は、EPUBの仕様では定められていないため、ビューアに依存します。
　【画像回り込み：CSSプロパティfloat: rightをimgタグに指定】
　Kinoppyは少し文字が重なってしまいました。
　【SVG：imgタグによりSVG画像の表示】
　Adobeは、文字が小さいものの正しく表示されました。
　Kinoppyは、一部要素が表示されませんでした。
　ACCESSは、テキスト要素が表示されませんでした。
　【外字：画像外字（SVG及びPNG）をインライン画像として用意】
　すべてのビューアで、少しベースラインのずれや文字の大きさが異なって表示されました。
　【文字装飾：文字の色や上付下付・下線等の表示】
　縦書きでの下線の解釈がAdobeと他の二つで異なり、Adobeは左側、他は右側に表示されました。Adobeは、イタリックやボールドが表現出来ません。
　以上の検証結果から課題として、同じ記述でも、ビューア毎に表示や解釈が異なり、現状でEPUBを作成するのであれば、表示上の問題が少なくなるようにある程度機能を抑えて記述するか、どれかのビューアに特化して作る必要があります。
　ただし、今後ビューアは進化していきますので、一つのコンテンツがすべてのビューアで同じように見えるようになる日も近いのではないかと思っています。

(2)EPUB3.0　の「標準化」に向けた活動について

　福浦一広（ふくうら かずひろ）　(EPUB研究会委員 インプレスR&D)

　生路茂太（いくじ しげた）　(電通)
　仕様の細部から離れて、Webの全体的な技術動向から見たEPUBの今後の動向や周辺技術に注目してみました。
　EPUBとは電子書籍の1フォーマットですが、コンテンツの電子化トレンドの一つとして捉えることができます。電子化とは、流通のWeb化(IP化)と同義です。
　一人で複数の電子閲覧デバイスを持つ時代ですので、PCとスマートフォンで別々にものを買うのはナンセンスです。PCで買った本はiPadやテレビでも使いたい。また、デバイスの破損や買い換えの際に購入したデータをどう保全していくかという問題もあります。
　その潮流の一つで、「権利ロッカー」というDRMの仕組みをクラウドに持たせて権利を安全にクラウド上で管理する仕組みが出始めています。メディア・コンテンツの電子化という流れで見ると、今後は、書籍や雑誌もこの流れの影響を受けると考えられます。
　コンテンツの電子化による流通技術のトレンドは、アナログ・デジタル・クラウドという流れです。手紙がデジタル化して電子メールになりました。電子メールは、実体データをやりとりします。GmailのようなクラウドのWebメールでは、参照権に基づいて表示をするだけで、実体データはやりとりしません。本という物理媒体がEPUBという形で電子化し、クラウド化で権利処理を考える時期が来ると思います。電子雑誌の配信サービス「マガストア」では既に、国際標準化規格での権利許諾コード体系「DRPC」を利用して配信情報の管理を実現しています。
　直近の問題に目を向けますと、ビューアで整合性がとれない・表示が崩れてしまうという問題があります。これは、他のオープンな規格に基づく実装であるWebブラウザやAndroid端末にも見られる不可避な問題です。製品の実装仕様自体がベンダー各社の競争領域である以上、この解決できない動作差分との折り合い方が重要です。
　一つのアイデアとして、建築業界で発明され、ソフトウエア業界で発展した「パターン・ランゲージ」というノウハウを紹介します。これは、あるデザインを要素分解して、構成要因の共通言語を作るものです。成功要因を言語化したものを「デザインパターン」、逆に失敗要因を言語化したものを「アンチパターン」といいます。
　EPUBビューアの整合性問題を考えたとき、いろんな端末で起きた問題をアンチパターンとして報告してもらい、これらを共有することで段階的に制作ガイドラインとしてのデザインパターンが導くことができます。
　大切なのはコンテンツ側とビューア側で問題を共有して、一緒に改善していく仕組みです。デザインパターンの共有プロセスを業界で整備することで、独自EPUB仕様の乱立を防ぎ、市場全体を育てていくことができると考えています。

(3)EPUB3.0　コンテンツ制作フローモデルについて

　池田 実（いけだ　みのり）(フューズネットワーク)

　Adobe InDesign CS6から書き出したEPUBがRMSDK以外のビューアで見られないという問題があります。そこで、FUSEeで加工して作れないかということを考えました。
　画像がCMYKであった場合や、レイヤーを持ったままのPhotoshop・Illustratorデータ内にあるテキストをどうやって拾うのか、utf-8など文字コードの問題が予め懸念されていました。DTPでは、オブジェクトの順番を入れ替える作業がありますので、その際に正しい順番でデータがあるのかという問題などがあります。
　CS6から書き出した「我が輩は猫である」のEPUBのデータをお借りして検証しました。
　内容を見てみると、「本文.xhtml」、画像で「数式1_fmt.png」、「本文.css」という日本語のファイル名がありました。Webのテクノロジーに転用することを想定していないため、DTP制作ではリソースのファイル名を日本語のまま使います。
　日本語ファイル名が問題なのは、コンテンツの中ではURIエンコードされた状態で記述されています。しかし、実体のファイル名はエンコードされていないのでリンクが切れてしまいます。
　それ以外には、フォントのサブセットがいくつか含まれていました。そのフォントを使いたいのであれば、一度フォントを削除してサブセットを作り直すような作業をしなければいけません。実際に使われている書体しかグリフが含まれませんので、書体が適用されている箇所を編集する場合は、大いに注意が必要です。
　ありとあらゆる文字に<span>タグでclassが適用されています。ルビタグにも必ずスタイルが適用されています。スタイルを持ったままInDesignからデータを書き出すというのは、これが限界だと思います。この辺をスマートにしていただければ、EPUB制作者としては構造の把握や改変が楽になります。
　RMSDK以外のビューアで表示させるために、正規表現で不要なタグを除去し、ほとんどのタグを手で修正し、リソースへのリンクも修正しなければなりませんでした。これを行うのであれば、InDesignからコピー＆ペーストしたものをベースに制作を行ったほうが作業負担が少ないという状況です。現時点では制作のフローを作れると言い切ることは出来ません。
　スタイルを無視するとか、見出しの付け方などルールがあれば、整形のプラグインを作ることは可能ですが、制作のルールを決めて運用していた会社のInDesignデータであればという前提です。実際には、出版社・製作会社ごとに差異があると思います。
　この部分は、本来Adobeに頑張っていただけるのが理想です。

【講演終わり】