昨年発売した本が電子書籍に（EPUBで）

昨年発売した本が電子書籍になりました。
EPUBで！

「IAシンキング」坂本貴史著　DRMフリー PDF・EPUB同梱版
http://www.wgn.co.jp/store/dat/7001/

著者の前向きなこだわりと希望、版元のチャレンジ精神などさまざまなものが揃って今回実現しましたが、作業が遅れてご迷惑をかけました。なんとか発売できてよかった！！PDF、EPUB、mobiで出しました。

ここでは本の内容とは一切関係なく、制作についてのいくつかを書いておこうと思います。

また、中のデータについては、つっこみどころありそうですが、「こうしないと読者として困る」「こういうふうにしたらいいよ」ということがあったらぜひご意見お待ちしてます。

EPUB３ではない

EPUB3の解説本を作りながら制作を進めていたのですが、EPUBの汎用性を考えて、またもっともシェアの大きそうなリーディングシステムであるiBooksがその時期（昨年からつい先日まで）にまだEPUB3に正式対応していなかったこともあり（途中からファイルは解釈してたんですが）、「EPUB2的なモノ」にしようと決めました（「的なモノ」は心の中で） 。

iBooks以外の理由としては、EPUB3データにすると読者の愛用のソフトが使えない可能性があるのが一点。もうひとつは、本書が横組みの本だからことさらこだわる必要がなかった、ということでした。

もし時間があれば、NCXファイルをEPUB3用に書き換える…みたいなチュートリアル的なこともやってみたい（余暇として）と思いますが、目次を手作業で作るのが目下非効率なため、EPUB3作成対応の適当なMacプラットフォーム向けのアプリが早くでないかな･･･と首を長くしています。

データ的なことでは、技術評論社で出しているEPUBのように、または団体などで提案されているように、セマンティックなEPUBタグを盛り込んでいくべき（といってもそれはEPUB3向）だったかもですが、まあひとまずはこまかくこだわらなくてもOKかな…と思ったり。今であれば注釈がポップアップ表示になったので、あれは対応できるとそれなりによかったかも。

汎用というのは難しい

EPUBはオープンフォーマットが売りですが、やっぱり汎用というのは難しい。紙の書籍には印刷と製本、PDFにはAcrobat、FlashにはFlash Playerと、これらのコンテンツに対しては基準といえる入れ物があるのですが、EPUBの場合は公式の入れ物はまだちゃんとありません。Readiumがあるけれど、もともと作る予定はなかったわけで基本、どのリーダーもサードパーティ的なものです。CDに対するCDプレーヤーと考えれば、低音がちょっと弱いプレーヤーってだけならまだしも、10曲目が聴けないとか、頭出しできないとか、そんな状態かもしれません。

本書の購入読者は、半分以上がPCで読む（結果としてPDFを読む）と考えていて、その次にiBooks（iPadのEPUBリーダー）が重要と想定しています。iBooksではPDFも読めるけれど、もとの本で11Qですから、レティナでもちょっと厳しいのではないかと。なのでEPUBはiPadを中心に読まれると考えてアプリをiBooksをターゲットにしてiBooksの現在での表現領域を想定して将来酷いことにならないように（考えかつ祈りつつ）仕様を決めました。行間からしてアプリごとに違うんですよね。文字だけだと「それぞれ良きに計らったつもり」で通るけれど、たとえば下線のデザインや背景に色のある段落があったら、行間変わるとけっこうみっともなくて、こまりますねー。あと一部だけCSSがきかないリーダーで文字読めるか？とか、画像をタップで拡大はしないリーダーが多数であることとか（iBooksの使用感ではそこが売り、というのが困りました。使いたいけど他と齟齬がでる）。

読者の方がどんなリーダーでどういうふうに感じたか知りたいですが、DL ReaderはAdobe SDKが使われており、今後使われるリーダーソフトウェアも多そうなのでターゲットにしたのですが、Kobo（見出しがセンター揃え）や、Himawari Reader（いわゆる無理なページめくりがないWebとの中間的な見栄えになるリーダー）もけっこう見た目はいいです。書体がきれいということでは、書体搭載のアプリもいいと思います（暗に日本語を読むという点でDL Readerはちょっとな。と思っているということです）。

EPUBにデザインは不要なのか？

EPUBでコンテンツを書籍化するとき、つくりが（それなりに最低限）セマンティックであることが、まず一番重要だと思います。視覚的な位置・サイズ・色だけに頼るデザインというのは、難しいかもしれない（それはWebと同じかも）。じゃあWebみたいな本でもよかったんですが、CSSはできるかぎり紙のグラフィックデザインのテイストを活かしたものにしてみました。まあもう、本当にいろいろ、見るひと１人１人に感想があって、賛否両論？だったのですが、本当になにがベストかは手探り。むしろ今回は作り手の主観です。

手作り（人間がマークアップから行う）で作るならこれくらいじゃない？ってレベルで、DTP風に言うと「オーバーライドが多い（+マークの段落がいっぱいあるってこと）作業」にはなってます。

電子書籍は自動で作るべきなのか

デジタルボーンの電子書籍に関しては、コストはさておき、自動化を進めていくことはやりやすいのではないかと思う。書くときから仕様ありきで。

一方で、紙の書籍はタグでマークアップするのではなく、「位置や大小や色でマークアップ」されていることが多いので（完璧にマークアップされているデータもあるかもしれないけど）、これをタグに置き換え、順番を入れ替え、画像サイズを再検討するという作業は自動化には多少困難で、何らかの中間データを持っているか（いわゆるワンソースマルチユース的な考え）、誰かが考えて再変換するかが必要。ずっと言われてるけど実現しないのは、紙業界の人が紙の自由度と熟練度がマークアップ言語の不自由さに慣れないかだと思うんだけれど、最低限リフロー電子書籍をやりたいかどうかによって紙の設計も考えないといけないと思う（DTPは極力自動化されているところとそうでないところの差が激しいです）

ちなみにIAシンキングは、もともと線型のレイアウト構造でかなりマークアップはしやすい本にはなっていました。とはいえ、節の見出しひとつとっても、テキストボックスは細切れになっているので、再変換作業はあります。あと一番悩んだのがh3レベルあたりの意味的な割り振り？　AとBとCの意味の違うフォーマット上のh3をそれぞれどう区別して考える？みたいなことを自分でいろいろ命名分類する作業というのが大変でした（当てはまってなかったりするので）。なのでもともとのマークアップ用語として「column」とか「note」とかあると、やっぱり楽なのかな、、、（「作業」なので決め打ちできて共通化できるほうがいい）。かといって「excercise」とかってマークアップしてリーディングシステムによって表示が変わるとなるとまた、悩ましいだろうけれど。

関連するかも
プリントファーストな電子書籍を考える？
http://livedoor.blogcms.jp/blog/sdfg158-dbungutecho/article/edit?id=1716060

とりあえず発売日に向けて書いてるので、また思い出したことがあれば書きます。