8 29 slide_tajima

印刷用DTPデータからの電子書籍制作

（株）三陽社メディア開発室　テクニカルエキスパート

田嶋　淳

「電書魂」http://densyodamasii.com/

「EPUB3」とは

楽天koboが日本でのストアオープン時に「EPUB3のみの受け入れ」

という方針にしたことで一気に普及

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

リフローとフィックス

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

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

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

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

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

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

InDesign の段落インデント機能で字下げ処理

改行＋全角スペース挿入で字下げ処理

どちらの方法でインデント処理を行っていても、成果物としては「同じデータ」

極論すればDTPでは目的とする紙面の状態を得られるのであれば、

どんな作り方をしても構わない

DTPの最終成果物はあくまで「印刷物」

データは中間生成物に過ぎない

電子書籍ではデータそのものが「成果物」

規定した書式にきちんと沿って作られているかを発注者によってチェックされる

制作会社窓口担当者 出版社検収担当者 各書籍担当編集者

制作仕様の提示各作品ごとの制作指示

データ納品

紙版と変える部分の打ち合わせなど

出版社が規定するEPUB3の制作基準の

デファクトスタンダードになっているのが「電書協ガイド」

http://ebpaj.jp/counsel/guide

電書協ガイドの向こう側にある各ストアの制作ガイドライン文書

Kindle パブリッシングガイドラインiBooksAssetGuide

楽天 Kobo コンテンツ制作ガイドetc...

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

制作コスト、管理コストの壁↓

電書協ガイドに沿ってワンソースで

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

InDesignから書き出したEPUBのソースコードと

電書協ガイド基準で販売されている書籍のソースコードを比べてみる

InDesignから書き出したEPUB内のXHTMLのコード

電書協ガイドに沿ってコーディングしたEPUB内のXHTMLのコード

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

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

弊社の場合はInDesignのXML書き出し機能を使って

タグ付けしたXMLを書き出しそれをPerl で変換して

EPUB3の元となるXHTMLファイルを作成

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

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

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

出版社からの詳細な制作規定の例

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

etc...　　

画像解像度の規定

A社　画像ピクセル数最大で長辺 2000pxB 社　画像ピクセル数最大で長辺 1536px

A社用のスクリプトとB社用の変換スクリプトを作り、そこの使い分けだけを確実にしてもらう

A 社制作基準挿入画像は長辺最大 2000px

B社制作基準挿入画像は長辺最大 1536px

A 社用変換スクリプト

B社用変換スクリプト

長辺最大2000pxの画像群

長辺最大1536pxの画像群

もと画像（PDF）

字形の置換対応（エキスパート字形）

「澗」→「㵎」／「侠」→「俠」／「剥」→「剝」／「唖」→「啞」「嘘」→「噓」／「噛」→「嚙」／「嚢」→「囊」／「填」→「塡」「屏」→「屛」／「屡」→「屢」／「掻」→「搔」／「掴」→「摑」「攅」→「攢」／「柵」→「栅」／「溌」→「潑」／「涜」→「瀆」「焔」→「焰」／「祷」→「禱」／「箪」→「簞」／「繍」→「繡」「繋」→「繫」／「莱」→「萊」／「蒋」→「蔣」／「蝉」→「蟬」「蝋」→「蠟」／「醤」→「醬」／「醗」→「醱」／「頬」→「頰」「顛」→「顚」／「騨」→「驒」／「鴎」→「鷗」／「鹸」→「鹼」

「麹」→「麴」／「麺」→「麵」

Unicodeに双方のコードポイントがある文字のみ1対1の置換を行う

基本字形がJIS2004基準のNフォントになった時点でほぼ正字対応的な話は解決しているはず漢字の字形に関しては人名地名以外は

「きちんと説明をしてあげれば解決する問題」

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

http://lostandfound.github.io/epubcheckmsg-ja/

epubcheckのエラーメッセージ日本語訳

ソースコードを直に編集してエラー修正できなければ

EPUB3作成の仕事はできない

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

http://densholab.jp/lab/RScheck/result.html

各ビューアの表示能力の差異

もしエラーを含んだドキュメントがそのままストアに行ってしまったら

電子版の発売が大幅に遅れることになりかねない

まとめ

電子書籍の最終成果物は「データ」そのもの受注には会社としての仕組み作りが必要

機械的なデータチェックは必須

おまけ

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

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

もとがDTPデータである限り一番知っておかなければならないのは

「InDesignなどDTPデータの制作に関する知識」

CSSは電書協ガイドの「RS による対応を想定する HTML 要素と CSS プロパティ」

の内容をしっかり覚える

基礎的な正規表現の知識は必須仕組みを作る側に回るなら

Perl や Rubyなどの知識も必要に

おまけ2

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

http://idpf.org/

http://blog.imagedrive.jp/

http://ebpaj.jp/

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

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

http://densho.hatenablog.com/

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

http://densholab.jp/

http://densyodamasii.com/

FaceBookで参加しておくとよいグループ

epubcafeepubcrea

電書ラボ・意見交換グループ

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

のが大事

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