ビルド職人本の裏話
書く書く詐欺だったビルド職人本の裏話をやっと書きます。今回は入稿してからの話。入稿はHTMLで行いました。SphinxのHTMLｰｰｰmake htmlで生成するアレを入稿。それをGDPの中の人がEPUB形式に変換して、お互い微調整を行うという流れ。
Sphinxが出力したHTMLのマークアップをGDPのEPUBのマークアップに変換していくのですが、GDP側のマークアップが意味的に細かいので、結構修正が多いです。正直、HTMLで入稿して（GDPの中の人が）楽だったのかな？と思えるくらい。
例えば、"code"なんてのはSphinx側では"``code``"だけなんですが、GDPのEPUBはcode, var, kbd, sampを使い分けてる。「EPUB3用XHTML作成ガイド」にもそう書いてるんですが、いくらなんでもやり過ぎやろー！？と思ってたら、ホントにそうやってる。
Sphinxで原稿書いてるときは気にもしなかった章番号や脚注番号もEPUBでは振りなおしです。EPUBそのものを直接編集してるから、そうゆうのも手作業です。ハイ。ほぼ全ての参照要素にIDが振ってあるので、IntelliJさんがID重複やらIDの参照ミスを見つけてくれるので、ついついデバッグをしてしまったり...。
「マジかよ」と思ったのが、pタグにまでID振ってある事。これって中の人が地道にポチポチ振ってったのかなー？ってそうなんだろな。ID振ってあるので外からリンク貼るのに便利なんだけど、改訂とかで構成変わったらどうするんだろ？と余計な事を考えてしまった。
sectionやpのIDは仕方ないかなと思いますが、脚注については "noteref3-1" なんて味気ない名前付けるより、もちっと意味的な名前付けたほうが構成変更したときの負担が減るかと思います（脚注番号の振り直しは残りますが...。
EPUBいじるんだから仕方ないよなーと思いましたが、'<'や'>'を実体参照文字にすんのもEPUB版ではこっちの仕事になります。なので、ソースコードの修正とかあると、ちょっと悲しい事件になりますね。
ソースコードといえば、Sphinxがせっかくシンタックス・ハイライトしてくれてるんですが、EPUBには反映されてません。この辺は、SphinxのマークアップとGDPのEPUBとで折り合い付かなかったんだろうなと推測してます。
ハイライト繋がりで、ちょいと一言。いまんとこ mark タグ使って特定箇所をハイライトするしかないので、コードのマークについては、もちょっと種類があるといいと思います。といっても、Sphinx側もソースコードの（意味的な）ハイライトは苦手なんですけどね。
ある意味、EPUB的だなーと思ったのが、URLの扱い。たとえば、
Antのホームページ（http://ant.apache.org/）
なんてのは、
としてます。なんでま、紙に出したらわかんないよね。
EPUBの修正してて思ったのが、HTML文書って論理行が長いのでdiffで差分みてもどこが修正されたか分かりづらいのよね（大抵のdiffツールは行指向なので）。
一応、IntelliJはword単位で差分取ってくれるんですが、それは英文に限った話で、日本語のように語の区切りがないとお話になりませんでした。一応、JetBrainsには改善要望出しておきました。
GDPもまだ黎明期なのでしょうけど、EPUBを直接編集するのは中の人の負担が多きすぎやしないかと余計な心配をしてしまいます。Advent Calendar 2011のEPUBみたら相変わらずの精度で「GDPの中の人はバケモノか！？」と思ってみたり。:-)
でも、せっかくのEPUB/eBookなので、はやいとこEPUBを生成する中間フォーマットを開発するなり、お手頃のオーサリングツールが登場するなりして欲しいですね。技評さんとこには名だたるエンジニアが縁があるので、その人ら集めて開発してもらったらいいんじゃないだろか。
個人的にはEPUB/eBookは廃れて欲しくないので、GDPさんにはガンバって欲しいところです。
もしくは、これやってたのが去年の11月の話なので今となっては笑い話になっていると良いなと願いつつ。
