「電子書籍制作仕様書 第一次素案」Web公開版(3/20)と配布資料の相違点

出版デジタル機構のWebページに公開されている「電子書籍制作仕様書 第一次素案」(2012年3月20日夜公開されたもの)と3月23日にフォーマット説明会場における配布資料(3月23日付け)を付き合わせるといくつか変更された点があります。

電子書籍制作仕様書 第一次素案

以下に気がついた変更点を列挙します。

B-1:リフロー型電子文書(DTPから制作する場合)
●アーカイブ用データ保存の項
Web)本ファイルを(2)アーカイブ用中間フォーマットファイルとして納品する
紙)本ファイルを(2)アーカイブ用中間交換フォーマットファイルとして納品する

●配信用電子書籍データ書き出し(パッケージング)の項
Web)校正は機構の用意する校正用仮配信サーバーを利用する。校正の方法や回数などの詳細は現在検討中
紙)*校正は機構の用意する校正用仮配信サーバーを利用し、1回のみ行なう。
(追加)
*出版社は仮配信サーバから電子書籍をダウンロードして校正する
*修正は中間交換フォーマットに戻って作業し、配信用データを再書き出しする

(注意)読点と長音は配布資料のまま

B-2:リフロー型電子文書(印刷底本からテキスト作成する場合)
●目次の項
Web)目次リンクを作成する。章・見出しなどの大項目は相互リンク、その下の小項目は片リンクとする
紙)目次リンクを作成する。詳細は別紙を参照

(注意)別紙は配布されていない

●校正の項
Web)校正はテキスト作成時(原稿校正)とパッケージング完了時(実記などによるレイアウト校正)の両方で行う
紙)校正はテキスト作成時(原稿校正)とパッケージング完了時(実記などによるレイアウト校正)の計2回のみ行う

注意)「実記」は配布資料のまま

Web)校正は機構の用意する校正用仮配信サーバーを利用する。校正の方法や回数などの詳細は現在検討中
紙)・パッケージング完了時の校正は機構の用意する校正用の仮配信サーバーを利用する
(追加)・出版社は仮配信サーバから電子書籍をダウンロードして校正する
(追加)・修正は中間交換フォーマットに戻って作業し、配信用データを再書き出しする

注意)「仮配信サーバ」は配布資料のまま

●アーカイブ用データ保存の項
Web)本ファイルを(2)アーカイブ用中間フォーマットファイルとして納品する
紙)本ファイルを(2)アーカイブ用中間交換フォーマットファイルとして納品する

電子書籍フォーマットポリシー第1次案への感想―市場の変化に備えるには

出版デジタル機構から16日「電子書籍フォーマットポリシー第1次案」が公開されましたので、ざっと読んでみました。

リンク:電子書籍フォーマットポリシー第1次案

最初に私の理解したところを整理しておきます。

1.方針概要

電子書籍の数を増やすことを最優先とする。

2.フィックス型とリフロー型

フィックス型を大量に作成して市場に投入し、市場ができるにつれてリフロー型の点数を増やす。

3.フィックス型フォーマット

本文画像を600dpi程度の高品質でスキャンして蓄積する。
まず、XMDFかドットブックを作成し、様子を見ながらEPUB3の作成に切り替える

4.リフロー型フォーマット

当初はXMDFとドットブックを作成する
納品されるファイルの仕様を厳密に規定する
中間交換フォーマットもアーカイブする

以上の1~4の方針となっています。以下は感想です。

この方針は基本的に同意できる部分が多いし、まず大勢が支持するものと思いますが、それだけに、現状ベースでありかなり保守的です。しかし、市場の変化に対応できないのではないかという不安があります。たとえば、強力な市場=販売チャネルが登場したときに、それに迅速に対応できないと、せっかくためたデジタルデータが宝の持ち腐れになります。具体的には、この方式を利用する出版社にとっての当面最大のリスクはAmazonに対応できない事態が生じる可能性でしょう。Amazonと機構でどういう話し合いがなされたかは知りませんが。そう思ってみますと、角川グループはAmazonと契約したと伝えられますが、機構の賛同出版社に入っていませんね。邪推しすぎかな?

出版デジタル機構(仮称)準備会・賛同出版社:239社(2012.3.13現在)

では、このようなリスクに備える対策はというと、電子書籍を作るためのデータをコンピュータで100%自動変換できる形で蓄えることでしょう。つまり新しい形式の電子書籍を作り出すときには変換を100%自動で行なうことができることを保証しなければなりません。この実現はそう簡単ではないですが、「完全な」自動変換ができれば低コスト・短時間で新しい形式にできます。もし、そうでないと1点毎に変換後の書籍を検品・校正する作業が発生することになり、この作業にコストと時間がかかり、二重投資かつ時間的なボトルネックとなります。

自動変換を妨げるものはいろいろあります。

まず、外字です。この点からドットブックでオリジナルコンテンツを作るのはあまり推奨できません。ドットブックはシフトJISのため表現できる文字数が不足しており、外字を画像で表しているケースが多いためです。XMDFは理論上はUnicodeを使えるはずですが、実際はシフトJISにすることが多いようです。シフトJISを使うときは外字を画像で表しますが、その文字のUnicodeのコードポイントをかならずどこかに保持しておく必要があります。このあたりの取り決めが必須です。

自動変換を妨げるものの2つめは構造です。本文の見出し、図表のキャプション、上付き文字、下付き文字、注など最低限の必要な項目を調べてこれらをきちんと構造化しておく必要があります。現在のXMDFやドットブックは、見栄え優先、すなわち、フォントの大きさなどで見出しを示すといったタグの使い方をしているものが多いのですが、こういうタグの使い方は変換の自動化にあたっての阻害要因になりますので禁止しなければなりません。タグ付けのガイドラインの整備と準拠が必須です。

既存のDTPデータもPDFデータは無論ですが、私が調べた範囲では、既存のリフロー型ドットブックとXMDFでさえもソースをほかの形式に自動変換することは困難です。すなわち再利用性があまり高くありません。完全自動化ができないと人手による処理加工作業、それにともない検品・校正が必要になり再利用するときに新たなコストと日数が加わります。今回、あらたにリフロー型ドットブックとXMDFを作るときはこうした事態を繰り返さないように相当な注意が必要です。EPUBも不用意につくると同じ問題が起きます。つまり、タグをつけたら再利用性があるというわけではないのです。

中間交換フォーマットをアーカイブするといっています。「中間交換フォーマットV1.1(2月13日版)仕様書をざっとみたところではまだ実用的に完成していないのではないかと思います。完成度を高めるには、もっと徹底的に使ってみる必要がありますし、オープンな変換実証実験の繰り返しが必要と思います。