電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。


9月11日に電書協EPUB3制作ガイドのV1.0が公開された[1]。以下は、個人的に気になった点をリストしておきます。まだ他にも一杯あると思いますのでだんだん追加します。ここに書いたのは単なる個人的感想ですから、ご参考まで。

全体としては不必要な規制が多いという印象を受けます。こうした不必要な規制は標準のEPUB/XMLツールでは検証できないのですが、できあがったEPUBがガイド準拠であることをどうやって保証するのだろうか?まさか目視?それはないよね。

1.フォルダー構造とファイル名
[ガイドの記述](p.20)
・素材を格納するフォルダの名前が指定されています。
・itemフォルダにすべての素材を含める。その下の、image、style、xhtmlの3つのフォルダにそれぞれ画像、CSS、xhtmlの3つのファイルを収めています。
・opfファイル名(standard.opf)、ナビゲーションファイル名(navigation-document.xhtml)が指定されています。

[コメント]
・EPUBの仕様ではファイル名やフォルダー名は特に指定されていません。すべてのリソースはopfファイルの中に記述し、またファイルの読む順序はspineで指定するなどOPFには必要十分な規定があります。それなのにガイドでさらに枠をはめているのは無用です。
・このために電書協専用の出力メニューを用意する必要があります。
・これを守らないとどうなるのでしょうか?
・準拠しているかどうかを検証するツールがないと判定できないと思います。

2.idの重複を避ける
[ガイドの記述](p.67)
・idは、本来、各ページ(XHTMLファイル)ごとにユニークであれば構わないものですが、複数ファイルからなるEPUBデータの構成を鑑みて、ひとつの作品を通じてユニークな値であるものとします。

[コメント]
・ひとつの作品を通じてユニークな値にしなければいけない理由が理解できません。
・作品が多数のファイルから構成される場合、idが作品内でユニークかどうかをどうやって検証するんでしょう。検証ツールがあるのでしょうか?XML標準ではそんなツールはないと思います。

3. 文字コード
[ガイドの記述](p.9)、(p.45)
・p.9では、少なくとも、以下の文字集合をサポートするものとする:JIS X0213:2004
・p.45には、JIS X0213:2004にない文字は外字画像化。

[コメント]
・p.9の記述とp.45の記述は一貫していません。しかし、将来の発展性とか表現の自由度を考えるとむしろ、外字のフォント埋め込み、あるいは、missing glyphを読者に伝える仕組みを用意する という選択もあると思います。
・[2012/9/13追記]これは、結局、フォント埋め込み以外に解決策がないように思います。フォント埋め込みは技術的には簡単なのでRSがサポートしないはずはないですが、むしろ、ライセンス許諾の問題です。

4.ソースの整形
[ガイドの記述](p.22)
・divなどのブロックレベル的な要素では、必ず開始タグと閉じタグの直前直後にそれぞれ改行コードを入れるようにします。但し、p,h1~h6タグについては、開始タグの直後、閉じタグの直前には改行コードを入れないようにします。
・aの場合は、aがブロックレベル的要素かimgを囲むのでないかぎり、改行コードを入れないようにします。

[コメント]
・ソースの整形を厳密に規定しても、これを遵守するのは難しいと思います。遵守するメリットもないような。
・インラインタグの内部では改行が空白になってしまうので、不用意に改行を入れてはいけないと書くだけで良いのではないだろうか。
・いづれにせよこれを遵守しようとすると手作業では無理で専用のツールが必要でしょう。
・サンプルをみると、大よそその通りの整形がなされています。エライ!でもそんな必要ないんです。
・[9/12 10:03 追記]他の整形例にはこんなのもあります[3]。XMLオーサリングでエラーになるのは多くの場合タグのネスト関係。結局、タグの階層構造が問題になるので、階層をチェックする整形方法の方が有効だと思います。
・[9/12 11:50 追記]XMLのドキュメントが正しいかどうかをチェックするのはXMLパーサーを使います。EPUBCheckも内部にはXMLパーサー。改行によるテキストレベルの整形は、RSで見たとき空白が挿入される危険性を避ける注意事項以外にはあまり意味がないと思うのですが。
・[9/14 追記]XML文書を整形すると確かにソースのヒューマン・リーダビリティは高まります。しかし、このガイドで記述するような整形基準はみたことがない。そもそもXMLはプログラムで処理するものだし、リーダもプログラムなのでCSSで規定する以外の整形基準はリーダには影響を与えないのです。なのでソースのヒューマン・リーダビリティは、人間がソースをエディタで修正するときしか意味がありません。管理が簡単になることはないと思うのだけどね。

5.クラス属性
[ガイドの記述](p.9)、(p.45)
・CSSのクラスの種類が大量に定義されています。
・[2012/9/13追記]XHTMLに規定されている要素であるsub、supをクラス属性で定義しています。

[コメント]
・要素の種類が少なくてもクラスの種類が山ほどあり、これを全部覚えて、オーサリングを手作業で行なうのは至難のように思います。
・結局、専用のツールが必要になるように思います。
・[2012/9/13追記]Web標準ではだめとされている手法というコメントがあった[4]。しかしなあ、というクラスが多い。クラス属性はEPUBCheckにかからないので、クラス属性をつかうと、XHTML構文に基づきながらも何でもありになってしまうのです。CAS-UBでも一部これを利用しているので、批判すると目くそが鼻くそを笑うという話になってしまいますが。

■感想
・村田真さんによりますと、ガイドラインには「ガイドラインには大きく分けると、考えて自分で決めなさいというガイドライン、この通りにやればできるから考えるなというガイドラインがある」[2]とのことですが、どうもこのガイドラインは「自分で考えずにこの通りやりなさい」というものになります。で、この方針で生産性を上げようとすると、「電書協EPUB3」専用のツール(CAS-UBでは、文書型、専用編集メニュー、出力形式・生成フィルターの追加)が必要になります。ガイドに記述されていることの多くは技術的に見るとやる必要のないことなので、システム開発にコストがかかる割には、それによってできること(効用)が少なすぎるなあ…「電書協」対応ブランドをつけることぐらいしかシステム対応の意味がない…
・需要があれば作りますが、なんというか、どうでも良い瑣末なことばかりだ。あまり開発モチベーションが沸かないなあ。どうしてこんなくだらないことばかり決めるのがまったく理解できない。

[1] 「電書協EPUB 3 制作ガイド ver.1.0」
[2] https://twitter.com/muratamakoto/status/245544497704996864
[3] http://twitpic.com/atnh9a
[4] https://twitter.com/MurakamiShinyu/status/245738412496265217

□■□■□■□■□■□■ご案内□■□■□■□■□■□■

CASオンラインショップでCAS-UBのユーザー登録することで、誰でも30日間だけ無償でご利用いただくことができます。
CAS-UB評価ライセンス

電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。” への10件のコメント

  1. 2のidについてですが、注番号などの飛び先に使うことが多いので、ユニークなほうが間違いもなくデータとして扱いやすいということです。cssのidではありません。

    3の文字コードの記述のどこが一貫していないのか、わかりません。どこかで線を引かなければならないし、なるべく一つのファイルで使い回すことを考えると安全策を取るしかありません。枠をこえた部分は、たとえ文字をそのまま表示できるRSがあったとしても画像外字にして対応します。外字のフォントを埋め込むのは理想ですが、それができるRSはまだないという現状をふまえての処置です。

    4のソースの整形は当たり前のことです。この基準で作っています。専用ツールは必要ありません。置換ができれば簡単ですし、電子書籍を手作業で作るのは、ミスの元です。またきれいに作っておけば、管理がしやすいです。

    • >4のソースの整形は当たり前のことです。
       こういセンスは、信じられない。
       XMLは、インデントが意味をもつプログラミング言語とも違うし、人間が見るときはパージングしてインデントを付けてくれるビューアなりエディタなりで処理すればいいこと。
       いくら「ガイド」とはいえ、こういうお願いを入れるなんて、趣味がいいとは思えません。

      • XMLソースを人間が目でチェックして誤りを見つけることはあまり期待できません。このようにXMLのソース整形は、制作・管理という面で実質的なメリットはありません。

        ソース整形は制作上なんのメリットもない不必要な作業ですが、コストはかかります。

        従って、これをガイドに組み込むのであれば、その責任上、制作会社に対価としてソース整形費用を支払うべきでしょうね。

        以上により、発注者側に、ソース整形費用の支払い義務があることもガイドに入れないと不公平です。

  2. ピンバック: 電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。 | TIAOBooksの気にな

  3. コメントありがとうございます。

    >3の文字コードの記述のどこが一貫していないのか、わかりません。

    単純に論理的な問題ですが、「少なくともJIS X0213…」といった場合は、JIS X0213を包含する文字セットであれば問題ないということになります。ですので、「少なくとも」を削除しないといけないですね。あとの外字フォント埋め込みは実際に制作された例「論集文字」(2011年文字研究会発行)があり、これはiBooksで表示できます。

    >電子書籍を手作業で作るのはミスの元です

    まさかコンピュータでコンテンツを作るわけではないでしょうから、極端な言い方をしますと、XHTML部分の編集は常に手作業になります。それで疑問なのですが、このガイドは、全体としてどういう制作ワークフローを想定していらっしゃいますか?

    本文中でも書きましたが、制作されたEPUBが利用ガイドに準拠しているかどうかを検証する手段がないと、この利用ガイドは精神論になりかねませんが、これをどうするのでしょうか?少なくとも、汎用ツール(標準XMLパーサーなど)ではできないと思います。

  4. 水掛け論になりそうですが、「少なくとも」というのはこれは実装してくださいという気持ちの現れです。
    外字埋め込みフォントについてですが、勉強不足でした。ご指摘、ありがとうございます。しかし、ほとんどのRSが対応していない現状では、できないことには変わりありません。

    制作ワークフローに関しては、各社、それぞれ異なりますから、言及することはできませんし、名前からお分かりのようにあくまでも「ガイド」であり、強制的なものではありません。ただ、インデザインなど、既存のデータからの変換が多いと思います。その場合、変換テーブルなどを作って変換をかければ、手作業はほとんど要りません。

    このガイドに準拠して制作されているかどうかは、この仕様を使う各社判断に任されていると思っています。データについては、EPUBチェッカーでかなりひろってくれます。チェッカーで拾えない部分は、xhtmlに限ったものではないので、経験的に処理します。

  5. ピンバック: 電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。 | なりゆきス

  6. ピンバック: 電書協 EPUB 3 制作ガイド V1.0 2012/9/11 で気になったところ、いくつか。 | なりゆきス

  7. 電書協EPUB3制作ガイドの規定は、既存文芸書電子書籍からのコンバータのためのものとしてはそれなりに納得できますが、これを新規作成に使おうというのは無理だと思います。ほとんどのEPUB編集ツールが適用できなくなってしまうでしょう(フォルダ構成や改行など)。

    • XMDFからEPUBへのコンバータに使えるかなと思ってみたのですが、記事の種類でファイル名を変える箇所がありますね。

      p-cover.html
      p-fmatter-00n.html
      p-titlepage.html
      p-toc.html
      など

      例えば、XMDFは記事の種類でファイル名を変えるようになっていないので、XMDFからの変換で記事の種類(表紙、前付け、扉、目次を)自動的に認識できないかもしれないですね。

      すると、記事の対応表を手で編集するとか、少し工夫が必要になります。

      いずれにしてもコンバータを作る検討はしています。注文があれば作りますよ!

中村正三郎 にコメントする コメントをキャンセル

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA値として計算に合う値を入力してください。 *