EPUB18田嶋pdf 最近の更新履歴 epubcafé

電書協 EPUB3 制作ガイド／

緊デジ仕様の EPUB3 を作る

（株）三陽社　メディア開発室

田嶋　淳

電書魂 ─グーテンベルクの遙か彼方へ─

http://densyodamasii.com

電書協 EPUB3 制作ガイド／緊デジ仕様 EPUB3 の概要

・電書協 EPUB3 制作ガイドとは

一般社団法人　日本電子書籍出版社協会（EBPAJ）の公開した EPUB3 制 作ガイドラインです。現在のバージョンは 1.1.2 になります。

　

http://www.ebpaj.jp/guide.html

・緊デジ版 EPUB 3 テンプレート

コンテンツ緊急電子化事業特設サイト「緊デジ .jp」で公開されている制 作者向けテンプレートです。電書協 EPUB 3 制作ガイドの基本的な仕様 を採用しています。

　

http://www.kindigi.jp/download/

　基本的には「EPUB 3 という広い枠組みの中で、特定の会社に納品するための制作方法を規定するための「納品仕様」」 だと思っております。

　現状まだ、電書協 EPUB 3 制作ガイド／緊デジ仕様の EPUB 3 を完全に再現できるビューアは存在しませんが、各ス トア運営会社にできるだけ同一の表示を実現するための要請が行っているため、将来的には多くのビューアでほぼ同じ 表示を期待できます。今、比較的破綻のない表示が得られるビューアとしては、Readium Chromium（電書協ガイドリ ファレンスビューア）、kobo（Android 版アプリ／電子ペーパー）、iBooks3（iOS6 以上）、kinoppy（iOS ／ Android

／ Mac ／ Windows）などが上げられます。

　Web コンテンツの制作で過去に多く見られたように、各ビューアごとに別々のコンテンツを用意しなければならない 状況は制作会社側の負荷が大きいため、将来的に 1 つのコンテンツで（ほぼ）全てのストアに対応できる（あるいは一 括変換が期待できる）ようになることには大きな期待感を持っています。

内容的な特徴としては・・・

　電書協 EPUB 3 制作ガイドは基本的には印刷物から EPUB 3 への変換、あるいは XMDF ／ .book といったレガシー フォーマットから EPUB 3 への変換を考えて作られていると思われます。

　また、XHTML や CSS の対応想定範囲は比較的狭い範囲に留めており、できるだけ多くのビューアで近い将来に同一 の表示を実現するための「最大公約数」的な仕様と言えそうです。

　主なポイントをを箇条書きにしてみますと、

・構造化の概念が希薄（section 要素などは現状対応想定外）

・テーブル要素、本文内でのリスト要素等は現状対応想定外

・動画、スクリプト等のインタラクティブな要素も現状対応想定外

・表現と構造の分離はされていない（あえてしていない） 　といったような点が上げられます。

　以上の特徴から、デジタルネイティブで EPUB3 を制作するにはおそらく向かない（あえて準拠するメリットが少ない） と言えそうです。一方で印刷物やレガシーフォーマットの電子書籍ファイルなど、既存のコンテンツからのスムーズな 変換を考えた場合には、作業者の負荷を減らす一定の効果は期待できそうです。

制作に必要なファイル類

　一般的にリフロー型 EPUB 3 の制作には、以下のようなファイルが必要になります。

・本文用 XHTML ファイル

・CSS スタイルシート

・挿入用画像（カバー・挿絵・写真 etc）

・外字画像

・ナビゲーション用 XHTML ファイル 　（+.ncx ファイルが要ることも）

・本文内目次用 XHTML ファイル 　（仕様として必須ではない）

・OPF パッケージドキュメントファイル 　・・・など

　電書協 EPUB3 制作ガイド／緊デジ仕様の EPUB3 制作では・・・

・本文用 XHTML ファイル

　→　規定に合わせて作ります。クラス名等は基本的にあらかじめ決められたものを指定します。

・CSS スタイルシート

　→　基本的に準備されたものをそのまま使います。カスタマイズする場合も数値を変える程度です。

・挿入用画像（カバー・挿絵・写真 etc）

　→　規定に合わせて作ります。解像度は指定があります（長辺 1536 ピクセル）。 　　　底本奥付・カバーのファイル名は指定があります。

・外字画像ファイル

　→　 規定に合わせて作ります。Adobe Japan 1 にグリフの存在する Unicode 外字に関しては、規定されたファイ ル名を付けます（cid-00000.png etc）。

・ナビゲーション用 XHTML ファイル

　→　基本的に準備されたものをそのまま使います（navigation-documents.xhtml）。

・本文内目次用 XHTML ファイル

　→　規定に合わせて作ります（p-toc.xhtml）。

　　　※私の作ったツールで自動生成できます

・OPF パッケージドキュメントファイル

　→　規定に合わせて作ります（standard.opf）。

　　　※私の作ったツールで自動生成できます

　基本的な書籍制作に必要と思われる表現が、配布される CSS 内でほぼ網羅されているのがポイントです。

　これによるメリットとして制作者が CSS を定義していく必要があまりなく、個々の制作者による CSS 定義の揺れ／定 義ミス等を抑制できることが上げられますが、一方でデメリットとして使用しない CSS まで全て読み込むためにビュー ア側の負荷がどうしても大きくなり、冗長な（重い）EPUB3 データになってしまうことは指摘できそうです。

実際の制作にあたっての流れ

　制作の流れはおおむね以下のような形になります。

１ 本文用の XHTML ファイルを用意し、 ２ 同じく画像類を用意して、

３ テンプレートを参考に各ファイルを配置し、 ４ 目次ファイルと OPF ファイルを生成して、 ５ パッケージングし、

６ データ整合性チェック（バリデート）する

パッケージング〜データ整合性チェック

　EPUB データのパッケージングには以下のツールを利用できます。 ePub Packager

（Mac ／ https://itunes.apple.com/jp/app/epub-packager/id468997015?mt=12） epubPack

（Win ／ http://sourceforge.jp/projects/sfnet_epubpack/）

　ほか、コマンドライン（Win）／ターミナル（Mac）でコマンドを指定し、パッ ケージ化することも可能です。

　Mac の場合、パッケージングの前に不可視ファイル（.DS Store）を消す処 理が必要になります。以下のアプリが利用できます。他にも同種のアプリが存 在するようです。

Ds Store Remover

（http://veadardiary.blog29.fc2.com/blog-entry-3656.html） MacForkCleaner

（http://www.vector.co.jp/soft/mac/util/se485623.html）

　データ整合性チェック（バリデート）には、以下のツール・アプリを利用可 能です。

EpubCheck

（コマンドラインツール／ http://code.google.com/p/epubcheck/） IDPF EPUB Validator (beta)

（Webサービス ※10MB のファイルまで）／ http://validator.idpf.org） ePub Checker

（Mac ／ https://itunes.apple.com/jp/app/epub-checker/id453480324?mt=12） EPUB-Checker

（Win ／ http://www.pagina-online.de/software/epub-checker/#c1067）

　「最終的に紙に印刷したものが全て」の印刷とは異なり、電子書籍では「データとして整合性が取れていて、納品仕様 に沿っている」ことが要求されますので、データ整合性チェック（バリデーション）を通すことが必須になります。

ePub Packager

Ds Store Remover

ePub Checker

InDesign データから EPUB3 へ

　弊社の制作作業の流れを簡単にご説明します。なお、こちらのフローは、私のブログで過去に発表済みのエントリ 　「InDesign → EPUB3 用 XHTML 作成ワークフロー」（http://densyodamasii.com/indesign → epub3toxhtml 作成ワークフロー /） 　をベースに、電書協仕様の EPUB3 用にテンプレート／ Perl 変換スクリプトをカスタマイズしたものです。

１

元ドキュメントをチェックします

　EPUB に変換する InDesign の元ドキュメントのチェックをし、全体的な作業の流れを考えます。例えば以下の ような点をチェックします。

　・テキストボックスの配置方法（連結してあるか etc）

　・画像／表の配置方法（インラインになっていないか、表は InDesign 内で作られたものかどうか） 　・正規表現スタイル等の高度な機能が使われていないか

　このチェックを行った後、表や画像など後から挿入する要素は別途処理し、PNG もしくは JPG の画像として挿 入できるように準備しておきます。場合によって（図版内で使用されているフォントがない etc）は、底本から図 表をスキャンして準備します。その上で InDesign の元ドキュメントからは、画像類を取り除いてしまいます。

２

割り当てるスタイル／タグを一括インポートします

　「タグ」パレットのメニューから「スタイルをタグにマップ」を選 択し、「読み込み」ボタンをクリックして、あらかじめ用意してある テンプレートから段落／文字スタイル／タグ情報／スタイルとタグの 紐付け情報を一括でインポートします。

３

元データのスタイルをテンプレート内のスタイルに置換します 　元データの段落スタイル・文字スタイルをひとつずつ選択し、「段 落スタイル」／「文字スタイル」メニューから「スタイルを削除」を 選択してテンプレート内のスタイルに置換していきます。

　もともとのスタイルの当たっている箇所を確認しながら作業を進め たい場合は、検索置換機能を活用して置換していきます。最終的に元 データの段落スタイル・文字スタイルを全て置き換えます。

４

InDesign 内で文字スタイルを使用せずに付加された文字装飾要素にも全て文字スタイルを付加します 　スタイル（最終的には XML タグ）が当たっていませんと、InDesign

内で例えば圏点が付いていても XML タグとしては書き出されません。 従って、全ての文字装飾要素にスタイルを付加する必要があります。

　ただし、例えば「太字部分内の縦中横」といったように、XHTML でインライン要素の入れ子（ネスト）にあたる部分は、InDesign 内で 文字スタイルを当てる方法では処理できません。これは、文字スタイ ルの二重がけが不可能という InDesign の仕様によるものです。これ に関しては、次のステップで処理します。

５

インライン要素の入れ子部分の処理のための仮テキストタグを付加します 　インライン要素の入れ子（ネスト）部分のタグ付けのために、定義 したテキストタグを付加します。このテキストタグを後処理で XML タグに置換します。例えば太字部分内の縦中横であれば

　「今年は〓太字〓平成〓縦横〓 25 〓／縦横〓年〓／太字〓です」

　というような感じで付加しています。直後に XML タグに置換する ための仮タグなので、可読性はあまり気にしていません。

６

画像の挿入のために、画像名を拡張子込みで記入しスタイルを当てます 　底本で画像が挿入されていた箇所の近傍の段落の後に、画像名を拡 張子込みで記入し、画像用のスタイルを当ててやります。これを XML 書き出し後のスクリプト処理で画像リンクに変換します。

　1 ページ大の画像はファイルを分割することになるため、分割時に すぐ分かるように「〓〓〓〓〓 1 ページ画像入る〓〓〓〓〓」などと 入れておきます。こちらは現状では XHTML 書き出し後に手動で分割 していますが、将来的には自動分割処理を検討しています。

７

^{外字をチェックします}

　外字画像として処理する必要のある文字をピックアップします。印 刷で使用できる文字（グリフ）の数は電子書籍で使用できる文字の数 よりもかなり多く、書き出し処理の際に特に警告なしで字形が変化し てしまいますので、InDesign 内でチェックし、必要であれば外字画像 化しておく必要があります。

　自作スクリプトや InDesign の「代替字形」チェックボックスでチェッ クします。特に人名や地名は要チェックです。外字の探し方に関しま しては、私のブログ「電書魂」の過去エントリ等をご参照ください。

８

外字画像を書き出します

　外字画像化が必要な文字を InDesign 内で選択し、新規 InDesign ファ イルにコピーした上で PDF として書き出し、PDF を Photoshop で開 いて 128px×128px の png 外字画像として最終書き出し処理します。 この手順であれば Unicode 外字をそのまま外字画像化できます。弊社 ではこの手順をスクリプトで自動処理しています。

９

段落スタイル及び文字スタイルに XML タグを自動で割り当てます 　「タグ」パレットメニューから「スタイルをタグにマップ」を選択し、 全ての段落スタイル及び文字スタイルに自動でタグを割り当てます。 テンプレートにはあらかじめ各スタイルに適応するタグが登録されて おり、各タグとスタイルの紐付けも済んでいるので、新たにスタイル 作成を行っていなければ、ここでは「OK」ボタンを押すだけで済み ます。新たにスタイル作成を行った場合はあらかじめ対応する XML タグをセットで作っておき、ここで割り当てます。

10

インライン要素の入れ子処理のために付加した仮タグを XML タグに変換します 　InDesign の正規表現置換機能をスクリプトで連続実行し、5で付加

したテキストタグを XML タグに変換します。文中のルビを保持する ために最初に XML タグを付加し、その後でテキストタグの部分を消 去する形で処理しています。

11

タグ名を確認し、必要であれば XML 属性を付加します

　タグ名をざっと確認し、必要であれば XML 属性を付加します。ただし、変換後にテキストエディタで処理した 方が効率的な場合が多々ありますので、適宜判断して処理します。

12

XML ファイルを書き出し、XHTML ファイルに変換します。 　InDesign から XML ファイルを書き出し、書き出した XML ファイ ルを Perl で EPUB3 用の XHTML データに変換します。

13

ファイルの分割、目次用の ID 付加などを行います

　6で目印を付けた 1 ページ大の画像を挿入する箇所でファイルを分 割します。また、ファイルサイズが大き過ぎる場合もレスポンスに問 題が出ますのでファイルを分割します。ファイルサイズ 250KB が目 安です。

14

完成した XHTML ファイルを Safari ／ Chrome 等のブラウザで表示確認します 　最終的に EPUB 化する前に、XHTML ファイルを Chrome ／ Safari

等のブラウザでプレビューし、表示をチェックします。あらかじめ最 終的に EPUB 化するためのフォルダに XHTML ファイルをコピーして おくことで CSS スタイルシートへのパスが通り、実際に EPUB 化し た場合に近い形でプレビューすることができます。

15

OPF パッケージファイル、目次を生成する

　「OPF ファイル生成（緊デジ用）」（自作ツールです）を起動し、各 項目を入力して OPF パッケージファイルを生成します。目次用ファ イル（p-toc.xhtml）も同時生成できます。生成後、OPF パッケージ ドキュメント内のファイルの表示順／見開き指定、目次用ファイル内 のタイトル行などを修正し、各ファイルを完成させます。

16

EPUB パッケージを完成させる

　完成した各ファイルをフォルダに収納し、「Ds Store Remover」で不可視ファイルを除去してから「ePub Packager」でパッケージ化し、epub パッケージを最終的に完成させます。

　バリデートエラーが発生した場合は、「ePub Checker」でエラー箇所、内容を確認し、適宜ファイルを修正し、 再パッケージ化します。エラーが消えるまでこれを繰り返します。

CSS の追記について

　出版社の要望などにより CSS の追記が必要になった場合は、

　・電書協ガイドで規定されている範囲内の CSS 表現に留める必要がある 　・「book-style.css」の「作品別カスタマイズ領域」内に追記する

※電書協ガイドでは別に追加用の CSS ファイルを定義することも想定しているが、緊デジでは電書協ガイドの最も基本的な部分 に準拠するということで「book-style.css」の「作品別カスタマイズ領域」内のみに記述することを求めている。いずれにせよ 規定外の場所に CSS の追記をすることはできない。

　・既存の CSS を上書きするような場合には CSS の詳細度を利用する 　などの要件を守って CSS の追記を行います。

　詳細度を利用して CSS を上書きする方法は以下の通りです。 　例えば見出しを明朝体（serif）にする場合は、

/* --- * 作品別カスタマイズ領域

* --- */ /* 中見出し */

.hltr h3.naka-midashi { font-family: serif-ja, serif; }

.vrtl h3.naka-midashi {

font-family: serif-ja-v, serif-ja, serif; }

　のような形で CSS を追記してやります。

　適用範囲の指定が「.vrtl h3.naka-midashi」（クラス名「vrtl」のタグ内部にあるクラス名「naka-midashi」の「h3」タグ の意味）で、既存の見出しスタイルの適用範囲指定「.vrtl .naka-midashi 」（クラス名「vrtl」のタグ内部にあるクラス

名「naka-midashi」の「任意の」タグの意味）より詳細度が上になるため、こちらの指定が優先されて見出しが明朝体で

表示されます。

印刷会社や出版社が EPUB3 制作をするに当たって必要になると思われる条件

　以下は印刷会社や出版社が、これから EPUB3 など電子書籍の制作をするにあたって必要になってくると思われる条件 です。あくまで私見に過ぎませんが、ご参照いただければ幸いです。

・最低限一人、XHTML と CSS をある程度理解している人間は必要。いないと修正依頼に対応できない。

・出版社の担当者に「これはできません」と説明するためにも、EPUB や（緊デジなら）電書協ガイドの仕様を理 解しておく必要はある。

・できれば正規表現の理解はあった方が良い。大量のテキスト処理の世界なので、効率が大幅に違ってくる。

・「全く異なるもの」に変換する話なので、内部校正はきちんと考えないととても怖い。電子書籍の特性を理解した 上で校正のやり方を考え直す必要はある。

・印刷は「最終的に紙に印刷したものが全て」の世界だが、電子書籍では「データとして整合性が取れていて、納 品仕様に沿っている」ことが要求される。品質に対する考え方の切り替えも必要。「納品仕様を理解して、それに 合わせて作る」という感覚を身に付ける必要がある

緊デジ制作者同士の相互情報交換の場として「緊デジ wiki」を作りました

https://kindigi.wiki.zoho.com

基本的な情報共有／質問の場として活用して下さい