2016/7/28の第2回電書ラボ公開セミナーの発表資料です

1. 電書ラボEPUB制作仕様について
三陽社メディア開発室 田嶋 淳
『電書魂』http://densyodamasii.com/

2. http://densyodamasii.com/

3. 電書ラボEPUB制作仕様とは？
電書協EPUB制作ガイドのサブセット
「紙の本のデータを電子化する」ためのもの
「発注側の電子化担当者が制作会社のシステム構築担当者に制
作仕様として提示する」ことを想定
電書協EPUB制作ガイドで広く定義してある部分をより詳細に
定義
ビューアの実装状況を鑑み、より踏み込んだ部分も

6. 電書協EPUB制作ガイドって？

7. 日本電子書籍出版社協会の策定した
EPUB制作ガイドライン
http://ebpaj.jp/counsel/guide

8. 日本電子書籍出版社協会（電書協）
大手出版社の作っている業界団体

9. 電書協EPUB制作ガイド
商業出版をベースに、電子取次などを通して流通する
EPUB制作のデファクトスタンダード
強い力を持つ出版社がバックであり、各RS開発会社
、ストアにこのガイドラインに沿って作られたEPUB
の表示についての要望が行っている
各RSのサポート範囲を実態調査し、「ここまでなら
問題なく使える」範囲を定めた最小公倍数的な仕様

10. 電書協EPUB制作ガイド
「主として組み方向の混在や段組などのないシンプルな体裁の
書籍を、リフロー型の電子書籍として記述するための指針 」
電書協EPUB制作ガイドからはみ出たEPUBを作っても特に罰
則はないが、ビューアの表示検証などは独自に行う必要が生じ
る。現状EPUBの仕様にあってもRSの実装状況が追いついてい
ない例はゴロゴロある。電書協EPUB制作ガイドは「ここだけ
は道が整備されたメインストリート」。
一応固定型EPUBについての定義もあるが、デジコミ協の規定
そのまま

11. 電書協EPUB制作ガイド
「RSによる対応を想定するHTML要素とCSSプロパティ」として、各
RSにサポートを期待する範囲（CSSプロパティなど）を明示
「本ガイドでは、RSによる対応を想定しないHTML要素とCSSプロパテ
ィ」として、ガイド内でサポートを期待しないものに関しても明示
付録のテンプレート内に記述済みテンプレートを収録。3000行ほどの記
述があり、基本的に制作者はこの定義済みのCSSを選んで使えばよい
あえて「構造と表示を分離しない」形でCSSを定義してある。構造化文
書としての階層は浅い。おそらく印刷データを元に短時間でEPUB化す
る必要があるため。

12. 電書協EPUB制作ガイドの問題点
定義範囲が曖昧で広い
構造と表示の分離がされていない
ちょっと金科玉条化しかけている懸念も

13. 電書ラボEPUB制作仕様で目指したこと
制作会社がどこまでの対応をすればよいのか、線引きをはっきりさせる
工数が増え、オプション対応が必要になる要素に関してはっきり謳う
現状技術的に再現が難しいものについて「やらなくてよい」と明示する
「何ができて、何ができないのか」を発注者が明確にわかるようにする
「髙」「⑴⑵⑶」など、DTPでは普通に使え、フォント対応的には多く
のRSがサポート済みの文字に関して安心して使えるように電書協EPUB
制作ガイドの規定を一部拡張（AJ 1-6独自サポート文字のカバー）

14. 電書ラボEPUB制作仕様の見方
項目分類
「基本仕様」「文字・字形」「組版表現（文字）」
「組版表現（段落）」「組版表現（ページ）」
「組版表現（注・索引・コラム）」「画像」
「外字画像」「目次」「検証・校正」「書誌情報」
「CSSの記述方針」「納品データの仕様」
の各項目に分けて詳細を記述

16. 電書ラボEPUB制作仕様の見方
レベル分類
■基本的な要素・方針（LV1）
■技術的には対応可能だが、追加コストが発生するた
めオプション対応とする要素・方針（LV2）
■特定のRSでのみ対応可能なため、リスクを理解した
上で利用すべき要素・方針（LV3）
の三段階に分類してオプション要素を定義。

18. 例えば2-4-1項目の説明文末尾に⇒LV2とあるが、
これはLV2にオプション定義内容があるという意味。（2-4-2）

20. 実際に使用する際には、
各発注者が自社の事情に合わせて
定義を選んで提示するイメージ

21. おまけ（現状での制作時の問題点
）
画像のサイズ指定の問題
現在一部のビューアが画像サイズの％指定をサポートしていないため、
サイズ指定をしても反映されない。
電書ラボEPUB制作仕様では「本来はこうあるべき」という観点から
LV1ではサイズ指定で対応することとしたが、サイズ措定をしても反映
されない状況がずっと続いているため、LV2で「背景の余白ごと画像化
して配置する」方法を定義した。
現状致し方ない回避策。この場合ビューア操作で画面背景を黒にした場
合余白領域がはっきり出てしまうが仕方がない。画像形式に透過GIFを
使えば余白が見えないようにはできるが、GIFの性質上ベタ塗り画像に
しか使えない手段。

22. 7-9 画像サイズ指定
Kindle Android
○
Kindle iOS
×
Kindle Paperwhite
○
iBooks
○
Kobo Android
△（横長画像の高さ指定で画像が変倍表示される／縦長画像の横幅指定で画像が変倍表示される）
Kobo iOS
×（縦書き時の縦長画像の高さ指定、横書き時の横長画像の横幅指定以外は全て画像が変倍表示されてしまう）
Kobo 電子ペーパー
△（横長画像の高さ指定で画像が変倍表示される／縦長画像の横幅指定で画像が変倍表示される）
Kinoppy Android
○（ページ内にその画像だけが表示されるとき、中央寄せになってしまう）
Kinoppy iOS
○（ページ内にその画像だけが表示されるとき、中央寄せになってしまう）
Kinoppy Windows
○（ページ内にその画像だけが表示されるとき、中央寄せになってしまう）
Kinoppy Windowsストア
○（ページ内にその画像だけが表示されるとき、中央寄せになってしまう）
Kinoppy Mac
○（ページ内にその画像だけが表示されるとき、中央寄せになってしまう）
honto iOS
○
BOOK☆WALKER Android
△（進行方向の%指定は×）
BOOK☆WALKER iOS
△（進行方向の%指定は×）
BOOK☆WALKER Windows
△（進行方向の%指定は×）
BOOK☆WALKER Mac
△（進行方向の%指定は×）

23. おまけ（現状での制作時の問題点
）
カコミケイ処理の問題
テキストの周囲にケイを置くカコミケイの表現を使用した
場合、現在一部のビューアで「その後に表示要素がない場
合に閉じケイが描画されない」問題が出る。
不本意だが現状での回避策としては「白ケイ（hr）を最後
に配置する」などの手段を取るしかない。なお、電書協ガ
イドの範囲外だが、テーブル要素でも同様の症状が出る。

24. Kindle iOS
後ろに描画要素がないと閉じケイが描画されない

25. おまけ（現状での制作時の問題点
）
カコミケイ内に画像を配置した場合の問題
カコミケイ内に画像を配置した場合、現在一部のビューアで横組
みで右側、縦組みで下側のパディング指定が無視されて画像が表
示されてしまう不具合が出る。
このため、無難に行くならカコミケイ表現をあきらめ、上下に罫
線（hr）を配置して代替するといった方法を取るしかない。画像
形式に透過GIFを使い、はみ出る側に透明の余白を付けておくと
いうTIPSもあるにはあるが、ベタ塗り画像にしか使えない。

26. Kindle iOS
パディング指定
が無視される

27. ご静聴ありがとうございました