EPUB3.2と日本の課題

2020/01/10
APL EPUB-WGリーダー／株式会社ブックウォーカー

高見 真也

Shinya Takami, Ph.D.
• Rakuten from 2007
• 「楽天技術研究所（RIT）」の初期メンバー• 「楽天kobo」（電子書籍）の立ち上げに参画• BOOKWALKER from 2013
• 「KADOKAWA-EPUB 制作仕様」を策定• 「dマガジン」（電子雑誌）の立ち上げに参画

Advanced Publishing Laboratory• EPUB仕様策定団体（IDPF）がW3Cに統合→ 大手出版社協力のもと慶應SFCにラボを設立• 「APL」の活動：
1) EPUB-WG: EPUB仕様に関する標準化活動への関与
2) A11Y-WG: 電子書籍向けアクセシビリティの標準化
3) JWT-WG: 日本語書記技術の機能論的検討
4) LCP-WG: LCP（オープンなDRM）の動向把握
5) 出版物の健全なネット取引環境整備研究WG

EPUB 3.2

「EPUB 3.x」の歴史• EPUB 3.0（2011）• IDPFにより策定された最初のバージョン「3」• 固定レイアウト向けは別仕様として追加策定• EPUB 3.0.1（2014：日本ではこれが中心）• 固定レイアウト向けの仕様を取り込み• EPUB 3.1（2017：IDPFによる最後の仕様）• アクセシビリティ向けの仕様を追加• 互換性を重視しなかったため普及せず

なぜ「EPUB 3.1」は普及せず？
• 「EPUB 3.0/3.0.1」との互換性を重視しなかった• 多くのビューワー環境でアップデートが必要だった• 互換性よりもWeb標準技術への移行を優先した• 「EPUBCheck」が「3.1」に対応していなかった• IDPFからのサポートがなくなり開発が停滞した• 日本市場が「EPUB 3.1」に移行しなかった（私見）• 「EPUB 3」が普及している日本にメリットがなかった• 日本で使用している属性を廃止予定の扱いにした

「IDPF」から「W3C」へ• 「EPUB」を策定した団体が「W3C」に統合• 2017年にIDPFはW3C（PUBLISHING@W3C）へ• EPUBの次期バージョン「EPUB 4」はW3Cで策定• 「EPUB」仕様策定機関の変更による影響• IDPFと比較してW3Cの会費は高額（売上規模連動）• 仕様策定に関わるW3C正規会員となる出版社は僅か

PUBLISHING@W3C
Publishing
Business
Group
運営機関（旧IDPF理事会）

XXX
CommunityGroup
正規会員

仕様策定

公開議論
（EPUB3のメンテ等）（WP/PWP/EPUB4）

BG会員

無料会員

Publishing
WorkingGroup

「EPUB 3.2」と「EPUB 4」• EPUB 3.2（2019）• 「Community Group」により策定された→ W3Cによる正式な仕様ではない• 「3.0.1」の後継仕様として互換性を重視• EPUB 4（Working Draft）• 「Working Group」による策定される• 「Web Publications (WP)」の一種

「EPUB 3」と「EPUB 4」
IDPF/W3C-CG

EPUB 3W3C-WGEPUB 4PWP

WP

なぜ「EPUB 3.2」は生まれた？
• 「EPUB」という仕様をオワコンにしないため• W3Cによる「EPUB 4」の策定には時間がかかる• W3Cによる「EPUB 3」のメンテナンスを実績化• アクセシビリティや「LCP」に対応させるため• アクセシビリティは「EPUB 3.1」で追加された• DAISYがアクセシビリティ機能の再追加を支援• 「EPUBCheck」を「DAISY」がサポート• 「EPUB 3.2」への対応に着手することができた

W3C勧告のプロセス
1. 草案（WD: Working Draft）
2. 勧告候補（CR: Candidate Recommendation）
3. 勧告案（PR: Proposed Recommendation）
4. W3C勧告（REC: Recommendation）

「EPUB 3.2」の仕様
https://www.w3.org/publishing/epub3/epub-spec.html

「EPUB 3.2」の仕様（日本語訳）
https://imagedrive.github.io/Submission/epub32/epub-spec.html

翻訳者:
Wataru Yoshimura「Web Publications」の仕様
https://www.w3.org/TR/wpub/

「EPUB 3.2」の特徴• 「後方互換性」の確保• バージョンを「3.0」に維持し、廃止機能を見直し• 「アクセシビリティ」機能のサポート• 「EPUBAccessibility」仕様の追加• 「外部」リソース対応の明確化• 動的に呼び出される外部要素への対応• その他の変更点• 「WOFF 2.0」への対応、「EPUBCFI」対応の任意化「互換性」について明記• 後方互換性（MUST）• ビューワーは、バージョンが「3.0」より下（過去のバージョン）でも処理を必須とする• 前方互換性（SHOULD）• ビューワーは、バージョンが「3.0」より上（将来のバージョン）でも処理を試みるべき• 「EPUB 3.1」ではバージョンが「3.1」だった

「EPUB 3.2」に移行すべき？
• コンテンツ制作側の状況• 「アクセシビリティ」に対応するなら「3.2」• 「3.2」に移行するための追加作業などは不要• コンテンツ配信側の状況• 「3.2」だと「EPUBCFI」への対応が不要

日本市場では「EPUB 3.2」へ移行可能

「EPUB 3」はこれで一段落？
• 「EPUB 3.2」は実質的な国際標準規格• W3Cとしては正式な仕様ではない→ 「ISO/IEC」での国際規格化を目指す検討も• 一部の仕様において制限緩和を求めたい• 目次（Navigation Document）関連• 画像（Content Documents）関連• ページ表示制御（linear=ʻnoʼ）関連→ W3Cの年次会議（TPAC2019）にて報告

「縦書き」が国際標準仕様に

「縦書き」ができるまで• 2010.12.02: 草案（WD）• 3年が過ぎ・・・• 2014.03.20: 勧告候補（CR）• 5年が過ぎ・・・• 2019.10.24: 勧告案（PR）• あともう少し・・・• 2019.12.10: W3C勧告（REC）

「EPUB-Tech ML」の開設について• 電子書籍技術に関する情報交換の場• 電子書籍・雑誌に関わる技術トピックを中心に情報交換を行うためのメーリングリスト• 業界関係者70名以上が参加（2020.01）• 出版社、取次、開発、ストア関係者など• ご興味のある方はURLまたは高見まで
https://groups.google.com/d/forum/apl-epub-tech

EPUBCheck 4.2

「EPUBCheck」を取り巻く状況• 「EPUBCheck」は広く普及している• 出版社は制作段階のチェックに使用• 取次やストアは納品のチェックに使用• 「警告」や「エラー」は認めない方針• 「4.2.0」で「EPUB 3.2」に対応した• 最新の「EPUB」仕様に準拠する方針→ 制作済データで「警告／エラー」が発生

「4.2.0 β版」での問題• 「EPUB 3.2」対応で問題が発生• 「display-seq」の使用で「警告」が出るように• 「display-seq」は「EPUB 3.2」で廃止予定• 日本の関係者からの働きかけ• 電書協仕様EPUBでは著者部分で使用→ 日本語EPUBで大量に「警告」が出てしまう• ボイジャー小池氏が問題提起、日本からもフォロー→ 「EPUB 3.2」仕様そのものの見直しへ「4.2.0 RC版」での問題• 「RC版」で初めて問題が顕在化• 「EPUB 3」の仕様では論理目次の並びを制限✴ 本文と目次の順序は同じにしないといけない• 「4.2.0」でエラーチェックが厳密になった• 「EPUB 3」が普及した日本では• 仕様に準拠せず制作されたEPUBデータが存在（例：テルマエ・ロマエ／KADOKAWA）

「テルマエ・ロマエ」の例

「目次問題」の経緯（1/5）• 「4.2.0 RC版」でエラーが発生（2019.03）• 「β版」での警告問題が改善しているか確認中、KADOKAWA内で目次エラーの発生に気付く• 「EPUBCheck」に挙動改善を依頼（2019.04）• 開発者向け「Github」に日本の状況を報告• 「EPUB 3」の仕様としていったん却下される• 「EPUBCheck」の挙動変更は困難（2019.04）• KADOKAWAとしては受け入れる方針となった• 「EPUBCheck 4.2.0」がリリース（2019.04）

「目次問題」の経緯（2/5）• 「電書魂ブログ」が問題を指摘（2019.05）• EPUBCheck4.2でのエラーについて
http://densyodamasii.com/?p=3726• 「電書協」でもこの問題が話題になる（2019.06）• 業界関係者が問題が拡大しないように動き始める• 「EPUBCheck」に再度改善を依頼（2019.06）• 改めて日本の状況について再議論と理解を求めた• 電書協／デジコミ協でも状況を報告（2019.06）• W3C出版系の共同議長である塩浜氏が説明

「目次問題」の経緯（3/5）• 「EPUBCheck」に具体例を提示（2019.06）• 「EPUB-Tech ML」を通して業界内から事例を収集• コラムなどの重要度の低いページは目次上後半にまとめる• 料理本などは素材別やジャンル別など複数の目次を用意する• 漫画雑誌は後半に目次があるが電子版では冒頭に置きたい• 雑誌の目次はレイアウト的に順序どおりには配置されない• 開発者向け「Github」に目次表現の具体例を報告→ 代替目次も含めた仕様そのものの見直し気運が高まる

「雑誌目次」の例

「目次問題」の経緯（4/5）• W3C関係者内で塩浜氏が理解を求める（2019.06）• 「Digital Publishing Summit 2019」開催中に塩浜氏を中心にW3C関係者が本問題について議論• PBG議長間では日本向けの緊急措置を実施する方向で合意• PBGの定例電話会議にて方向性を再確認（2019.07）• 日本向けにエラーを警告に変更する対応（短期的措置）と目次仕様そのものの見直しを議論する対応（中期的措置）をEPUB3-CG（仕様策定グループ）に働きかけることで合意

「目次問題」の経緯（5/5）• EPUB3-CGの定例電話会議でも理解（2019.07）• 一部では反対意見もあったが、EPUB3-CGとしては、「EPUBCheck」に警告への変更を求める方向で合意• 「EPUBCheck」側も修正作業に着手（2019.07）• 「EPUB 3.2」の仕様そのものは変更されないが、PBGおよびEPUB3-CGの意向を特別に受け入れ• 本問題に対する修正リクエストが受理される（7/17）→ 日本からの修正依頼を反映して「4.2.2」へ（7/19）

「修正内容」への懸念• 警告文言（INFO）内に「ERROR」が含まれていた• The previous rule is under review and may change toan 'ERROR' in a future release. See the discussion at …
→ 簡易な判定方法だとエラーと判定される危険性がある• OK: /^ERROR/ or /ERROR(.*):/• NG: /ERROR/• 「ERROR」文言を含めないように改善依頼• The previous rule is under review and its severity may
change in a future release. See the discussion at …

「目次問題」は解決した？
• 現在はあくまでも暫定措置である• 「EPUBバージョン」を区別することも検討→ 議論はあったが区別しない方針になった• 「警告／エラー」以外を追加することも検討→ 現状では開発方針として受入困難となった• 「EPUB 3」の目次仕様の再検討へ• EPUB仕様が現状のままだと再発するリスクも• Must navigation order match spine order?
https://github.com/w3c/publ-epub-revision/issues/1283

「相互運用性」の維持に向けて• 「EPUB」と「EPUBCheck」の動向• 「EPUBCheck」の挙動はEPUB仕様に従う→ 「EPUB 3.2」以降の改定にも関心を持つべき• 「EPUBCheck」の改修は日本にも大きな影響→ 日本からも何らかの形で開発をサポートすべき• 「EPUBCheck」には開発支援が必要• Phase.1：「EPUB 3.2」への対応（完了）• Phase.2：リファクタリング（今後の改修を効率化）→ 後者の実施にはまだ支援が足りていない模様

「EPUBCheck」への支援
https://www.w3.org/publishing/epubcheck_fundraising日本の電子書籍における課題

日本の電子書籍における課題★ メタデータの統一性★ コンテンツの永続性★ レイアウトの複雑性メタデータの統一性• 課題1：メタデータの形式が統一されていない• 流通向け書誌情報の形式はストアごとにバラバラ• 海外のONIXはXML形式で扱いづらく普及していない• ONIX形式は出版情報登録センター（JPRO）で採用• 課題2：商品を識別するIDが統一されていない• ISBNは手間と費用がかかるため電子書籍では敬遠される• 合本版や話売り、特典付きなどバリエーションが多い• 課題3：商品を分類するジャンルが統一されていない• 図書分類コードや海外のBISACコードはマンガの分類が少ないメタデータ標準化の試み

メタデータが標準化されると• 電子書籍の流通を効率よく行える• 出版社・取次は一つのデータを用意すればよい• 効率化により予約やサイマル配信が容易になる• 購入履歴の統廃合が容易にできる• 複数で買った本の連携や統合が実現しやすい• 買った本が読めなくなる問題が解決しやすいコンテンツの永続性• 課題1：利用可能な文字が統一されていない• 文字の再現性は環境の組み合わせに依存• 特殊な文字表示への対応ができていない• 課題2：日本語のテキストは検索しにくい• 「ルビ」ありテキストの検索性が低い• 「画像」メタデータの検索性が低い

利用可能な文字が統一されていない• 文字の再現性は環境の組み合わせに依存• 電書協ガイドにある「JIS X 0213:2004」の範囲にない「髙（はしごだか）」などは、頻度が高く文字にしたい• 端末搭載フォントの文字数が足りず目次機能で文字が出ない• 特殊な文字表示への対応ができていない• Unicode-IVS（異体字）：対応されている環境が少ない• CJK互換漢字：文字を正規化（置換）してしまう環境がある• UAX(UTR)#50：縦書き時の文字の向きが環境によって違う

UAX #50
http://www.unicode.org/reports/tr50/

日本語のテキストは検索しにくい• 「ルビ」ありテキストの検索性が低い• ルビ要素を除去すれば親文字は検索できるが、ラノベなどではルビ部分も検索対象としたい• ルビを反映して音声読み上げを行うのも難しい• 「画像」メタデータの検索性が低い• マンガ作品：吹き出しをテキスト保持する仕様がない• 一般画像：ALT属性に含めたテキストが検索されない• 外字画像：文字列として検索対象にするのが難しい日本語の処理が改善されると• 外字画像の使用を減らすことができる• 外字画像が混ざった文字列は検索できない→ 日本語も英語も同じように検索できる• 日本語データの価値を残すことができる• ルビや外字が混ざった文字列は扱いにくい→ グローバル環境で日本語が存続できるレイアウトの複雑性• 課題1：日本の雑誌はWeb技術で再現困難• 縦組・横組混在で、字間・行間の設定が高度• 商用フォントをWeb上で使うのが難しい• 課題2：日本の漫画はWeb技術で再現困難• フキダシへの文字埋めが難しく、フォントも特殊• ひらがなは「明朝体」、漢字は「ゴシック体」

レプリカ型のEPUBデータが多い• 雑誌や漫画はレプリカ型でEPUBを制作• レイアウトが複雑なため版面を画像・PDF化→ 画像・PDFをページ要素としてEPUB化• 日本市場の8割以上が固定レイアウト型• 2016年の売上推計では86%が漫画と雑誌→ 日本ではレプリカ型の電子書籍が重要レプリカ型EPUBの標準構成
OPF

XHTML
spine

manifest

Navigation
Document

style

CSS

image

JPEG

SVG

Image-Map
電書協仕様

シンプルなレプリカ型EPUBの構成
XHTML & CSS is NOT mandatory

OPF
spine

JPEG

for Manga etc.

manifest

XTHML

for compatibility

PDF
Navigation
Document

Video

JPEG

fallback(thumbnail)JPEG

fallback(thumbnail)提案方式 in W3C-WS 2018

EPUBの仕様が緩和されると• レプリカ型EPUBの構造を単純化できる• ページ要素として直接「画像」を指定できない→ 「XHTML/CSS」なしで構成できる• コンテンツ配信側の処理が効率化できる• マンガ向けビューワーでは画像しか使わない→ 単純な構造だと変換処理が容易になる

まとめ

まとめ
• 「EPUB 3.2」と「EPUBCheck 4.2」
• 「EPUB 3.2」は「3.0.1」との互換性を重視• 「EPUBCheck 4.2.2」は日本でも使用可能• 日本の電子書籍における課題• メタデータの統一性：識別・分類の標準化• コンテンツの永続性：日本語の検索性改善• レイアウトの複雑性：レプリカ型を単純に

Thank You!
Shinya Takami, Ph.D.