8/29 Osaka

1. 印刷用 DTP データからの電子書籍制作
（株）三陽社
メディア開発室 テクニカルエキスパート
田嶋 淳
「電書魂」
http://densyodamasii.com/

2. 「EPUB3」とは

3. 楽天 kobo が日本でのストアオープン時に
「EPUB3 のみの受け入れ」
という方針にしたことで一気に普及

4. 従来のフォーマットとの大きな違い
「オープンフォーマットであること」

5. リフローとフィックス

6. リフロー：読み物用のテキストが生きているもの

7. フィックス：コミックなどに使われる固定版面型

8. http://densyodamasii.com/?p=2399

9. http://wakufactory.jp/densho/tools/mkepub.html

10. DTP データからの「リフロー型」EPUB3 作成

11. InDesign では画面上で見えているものが
そのまま成果物として紙面になる

12. InDesign の段落インデント機能で字下げ処理
改行＋全角スペース挿入で字下げ処理
どちらの方法でインデント処理を行っていても、
成果物としては「同じデータ」

13. 極論すれば
DTP では目的とする紙面の状態を得られるのであれば、
どんな作り方をしても構わない

14. DTP の最終成果物はあくまで
「印刷物」
データは中間生成物に過ぎない

15. 電子書籍ではデータそのものが
「成果物」
規定した書式にきちんと沿って作られているかを
発注者によってチェックされる

16. 制作会社窓口担当者 出版社検収担当者 各書籍担当編集者
制作仕様の提示
各作品ごとの制作指示
データ納品
紙版と変える部分の
打ち合わせなど

17. 出版社が規定する
EPUB3 の制作基準の
デファクトスタンダードになっているのが
「電書協ガイド」

18. http://ebpaj.jp/counsel/guide

19. 電書協ガイドの向こう側にある
各ストアの制作ガイドライン文書
Kindle パブリッシングガイドライン
iBooksAssetGuide
楽天 Kobo コンテンツ制作ガイド
etc...

20. 各ストアそれぞれに最適化した
EPUB3 を作ればよいのでは？

21. 制作コスト、管理コストの壁
↓
電書協ガイドに沿ってワンソースで

22. つまり、電書協ガイドはいわば「最小公倍数」

23. InDesign から書き出した
EPUB のソースコードと
電書協ガイド基準で販売されている
書籍のソースコードを比べてみる

25. InDesign から書き出した EPUB 内の XHTML のコード
電書協ガイドに沿ってコーディングした EPUB 内の XHTML のコード

26. 世の中には酷い InDesign データも多々・・・

27. ちゃんと制作基準に沿った形で
EPUB3 が制作できるような仕組みを作り、
手作業を可能な限り減らす必要がある

28. 弊社の場合は
InDesign の XML 書き出し機能を使って
タグ付けした XML を書き出し
それを Perl で変換して
EPUB3 の元となる XHTML ファイルを作成

29. まだ DTP における InDesign のような
プロ向けの定番の EPUB3 制作アプリはない

30. 今はまだ、社内で制作の仕組みを作らなければ
印刷データからの EPUB3 作成の仕事は受けられない

31. 同じ電書協ガイド準拠でも
出版社によって細かな差異が・・・

32. 出版社からの詳細な制作規定の例
画像ピクセル数最大で長辺 2000px
長辺 1536px
目次ページのリンクの色を黒にし、傍線を消す
カギが先頭に来た場合段落先頭にスペースを入れない
スペースを入れる
基本字形を印刷標準字形基準で
エキスパート字形基準で
etc...

33. 画像解像度の規定
A 社 画像ピクセル数最大で長辺 2000px
B 社 画像ピクセル数最大で長辺 1536px

34. A 社用のスクリプトと B 社用の変換スクリプトを作り、
そこの使い分けだけを確実にしてもらう
A 社制作基準
挿入画像は長辺最大 2000px
B 社制作基準
挿入画像は長辺最大 1536px
A 社用
変換スクリプト
B 社用
変換スクリプト
長辺最大
2000px
の画像群
長辺最大
1536px
の画像群
もと画像
（PDF）

35. 字形の置換対応
（エキスパート字形）
「澗」→「 」／「侠」→「俠」／「剥」→「剝」／「唖」→「啞」
「嘘」→「噓」／「噛」→「嚙」／「嚢」→「囊」／「填」→「塡」
「屏」→「屛」／「屡」→「屢」／「掻」→「搔」／「掴」→「摑」
「攅」→「攢」／「柵」→「栅」／「溌」→「潑」／「涜」→「瀆」
「焔」→「焰」／「祷」→「禱」／「箪」→「簞」／「繍」→「繡」
「繋」→「繫」／「莱」→「萊」／「蒋」→「蔣」／「蝉」→「蟬」
「蝋」→「蠟」／「醤」→「醬」／「醗」→「醱」／「頬」→「頰」
「顛」→「顚」／「騨」→「驒」／「鴎」→「鷗」／「鹸」→「鹼」
「麹」→「麴」／「麺」→「麵」
Unicode に双方のコードポイントがある文字のみ 1 対 1 の置換を行う

36. 基本字形が
JIS2004 基準の N フォントになった時点で
ほぼ正字対応的な話は解決しているはず
漢字の字形に関しては人名地名以外は
「きちんと説明をしてあげれば解決する問題」

37. チェッカーでの機械的なチェックはとても大事

38. http://lostandfound.github.io/epubcheckmsg-ja/
epubcheck のエラーメッセージ日本語訳

39. ソースコードを直に編集して
エラー修正できなければ
EPUB3 作成の仕事はできない

40. 手元の EPUB3 のビューアで表示して
きちんと見られたからと言ってそれで OK ではない

41. http://densholab.jp/lab/RScheck/result.html
各ビューアの表示能力の差異

42. もしエラーを含んだドキュメントが
そのままストアに行ってしまったら
電子版の発売が大幅に遅れることになりかねない

43. まとめ
電子書籍の最終成果物は「データ」そのもの
受注には会社としての仕組み作りが必要
機械的なデータチェックは必須

44. おまけ
DTP データからの EPUB3 制作に最低限必要なスキル

45. ・InDesign など DTP データの制作に関する知識
・XHTML・CSS の知識
・テキスト修正・変換の知識
（正規表現 /Perl/Ruby/PHP/xslt etc...）

46. もとが DTP データである限り
一番知っておかなければならないのは
「InDesign など DTP データの制作に関する知識」

47. CSS は電書協ガイドの
「RS による対応を想定する HTML 要素と CSS プロパティ」
の内容をしっかり覚える

48. 基礎的な正規表現の知識は必須
仕組みを作る側に回るなら
Perl や Ruby などの知識も必要に

49. おまけ 2
EPUB3 制作の世界にこれから入るなら、
まず参考にするべきページ

50. http://idpf.org/

51. http://blog.imagedrive.jp/

52. http://ebpaj.jp/

53. http://kadokawa-epub.bookwalker.co.jp/

54. http://www.jepa.or.jp/

55. http://densho.hatenablog.com/

56. http://www7b.biglobe.ne.jp/ yama88/index.html

57. http://densholab.jp/

58. http://densyodamasii.com/

59. FaceBook で参加しておくとよいグループ
epubcafe
epubcrea
電書ラボ・意見交換グループ

60. 継続的に新しい知識や技術を取り入れ
仕組み自体をアップデートしていく
のが大事

61. ということで、ご静聴ありがとうございました。