MarkdownでEPUBã‚’ä½œã‚‹å ´åˆã®å•é¡Œç‚¹

メモ。
結論から言うと、MarkdownとEPUB(のHTML)が密結合しすぎているのと、Markdownがシンプルすぎるのが問題になる、ような気がする。

例えばMarkdownで普通に画像を書くのは、

![画面キャプチャその１](capture1.jpg)

みたいな感じになるわけだけど、これを例えばdivで囲いたいとか、キャプションをつけたい、といったときに、Markdownではいきなり困った事態になる。

Markdownは結局のところHTMLの簡易記法であって、画像記法はimg要素の簡易記法であって、それ以上のものにはならない。そして、MarkdownそのものがサポートしているHTMLの要素はごくごく基本的なものに限られている。Markdownではリッチな表現ができない。

……というのはちょっと語弊があって、実はMarkdownは部分的にHTMLタグを記述できるので、Markdownの中に一所懸命divタグでもfigcaptionタグでも何でもいいんだけど、その辺りを書こうと思えばもりもり書ける。が、そんなことをやってるとメンテナンス性が落ちる。何のためにMarkdownというか簡易記法を使ってるのか分からない。まだHTMLを書くとか、いっそTextileとかHamlみたいなHTMLなら何でも書けますよ系の記法を使った方が、ValidなHTML(EPUB)を書くには便利じゃないかという気がする。

ある程度は「最後の手段」的にHTMLをごりごり書けるのは確かに役に立つというか、それができないとしんどいことが多いんだけど、ちょっと画像追加したいとか、ちょっとソースコードとターミナル出力を分けたいとかいうだけでもHTMLを書かないといけないのは、どうにも不親切すぎる。

というわけで、ある程度の限定された版面にするか、独自の拡張を施すとか（その場合にはMarkdown処理系を自分でごにょごにょする必要もある）、何かしら工夫する必要がある。そして後者の場合、Markdownとしてのポータビリティは損ねることになるので、そこまでして幸せになれるかどうかはよく分からない。

そう考えると、変に拡張するくらいなら、ポータビリティはすっぱりあきらめて独自記法に走ってもいいんじゃないか、と思う今日このごろです。

参考：

• EPUB電子書籍にも対応、関数プログラミング言語Haskellで書かれた万能ドキュメント変換コマンド「Pandoc」
• 出力フォーマットにReVIEWが指定できるfork版Pandoc(ちょっと古い)