KINDORU出版:外伝9 ~目次とか付けとくといいらしいよ~
さて飽きるほど自分の本の中身を読み替えし、自分で出来上がったと思ったら、次は目次について考えていきたい。
その前に表紙や中の挿絵など考えてもいいのだが、表紙の挿入自体はSigilにほぼ行ってもらえるうえ、挿絵も以前に述べたように、どうすればいいという正解は見つけづらい。
リフロー型の本では閲覧するアプリやリーダー機器ごとに、違ったアスペクト比の表示空間があり、通常、画像はその縦横のいずれかの制限に収まる大きさにリサイズされて表示される。
特に、多くの人が利用しているであろうスマートフォンは縦に長く、Kindleが表紙として指定しているサイズ(想定的な本の一ページの大きさ)1:1.6では、ほぼ横の幅で合わされ縦の長さが足りなくなる。
だから言えることとしては、挿絵としてかなり長めにとった縦長の画像を用意しておけば、縦書き文章の間に収まり自然っぽくなる、という程度だろうか。
では、そうした諸々をのぞいてなぜ目次を最後に回したかというと、目次もほぼSigilの機能をつかって自動でつくれ、その作業は最後に一括で行った方が効率がいいからである。
具体的にどのように作っていくかというと、目次からハイパー・リンクを通じて飛びたい場所に、「<h~>(~は1~6半角数字)」の見出しを用意しておき、Sigilの機能によってその場所へのリンクを並べた目次用のXhtmlファイルを作ってもらう。
基本的には、以上である。
ただし、現在のEPUB3というバージョンにおいては、さらにこの本の内容としての目次ページを弄るために、すこし工夫が必要かもしれない。
というのも、この以前のバージョンであるEPUB2まででは、アプリやリーダー機器の機能として目次のハイパー卍リンクを置いておく論理目次と、実際の本の内部にページ内容としてハイパー☆リンクを置いておく、html目次と呼ばれる部分は明確に分かれていた。
このどちらの目次もSigilによって自動で書き出すことが出来、そうした意味で別段不便はなかった。
電子書籍の作り方を調べているとき古い記事を読んでいて、SigilはEPUB2までしか対応していないという以前の情報をなぜか今もそうだと信じ切って自著をEPUB2でつくっていた自分にとって、Kindleで本を出すのに二つの目次が必要だということはそれほど混乱しなかったし、html目次のほうを何も気にせず弄れたという意味では有難かった。
(改めて調べると、EPUB2とEPUB3の違いは日本語的な縦読み右→左表記、ルビ対応、段組等々……となっているが、なぜか自分は結局EPUB2形式でこれらを概ね備えた本を表現できてしまっているし、段組などはEPUB3の形式でもやり方はよくわからなかった。)
しかし、それらの二つの目次が統合されてしまっているEPUB3の形式では、下手に目次用のXhtmlを弄ってしまうと、KindlePreviewerで読み込み時にエラーが発生してしまう。
機器側に正確に内容を伝える論理目次の機能と、読者側に視覚的に目次部分を見せたいhtml目次では、内容の折り合いがつけづらいのである。
そうした問題の解消方法として、一つは目次用Xhtmlファイルの論理記述部分「<nav>」タグ内をなるべく弄らず簡易に目次を表記する方法と、思い切って論理目次の部分を切り離し、読者側に表示される目次のXhtmlファイル、論理目次用の書籍内容に表示されないXhtmlファイルを用意する、という二通りの方法がなんかあるらしい。
さて、EPUB3形式で目次用にSigil様がおつくりになられたXhtmlの中身を見てみると、以下のとおりである。
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" lang="en" xml:lang="en">
<head>
<title>ePub NAV</title>
<meta charset="utf-8" />
<link href="../Styles/sgc-nav.css" rel="stylesheet" type="text/css"/>
</head>
<body epub:type="frontmatter">
<nav epub:type="toc" id="toc" role="doc-toc">
<h1>目次</h1>
<ol>
<li>
<a href="Section0001.xhtml">開始</a>
</li>
</ol>
</nav>
<nav epub:type="landmarks" id="landmarks" hidden="">
<h2>ランドマーク</h2>
<ol>
<li>
<a epub:type="toc" href="#toc">目次</a>
</li>
</ol>
</nav>
</body>
</html>
お約束の文書やヘッダーでのcssファイルとのリンクが書かれている以下、「<body>」部に「frontmatter」なるepub:typeをあたえられ、また同じくにそれぞれ「toc」、「landmarks」なるepub:typeを指定された「<nav>」という要素があることが分かる。
そしてこれを含み、本文ファイルを一つだけ持つEPUBファイルをKindlePreviewerに読み込ませたものがこれ。
見てわかるとおり、ページ内の目次(html目次)とメニューにある目次(論理目次)とがあり、現在はどちらにも「目次」という見出しと「開始」というリンク部分しかない。
しかし、これらがどのように動作しているのかというと、まあ実際にはよくわからないのだが、どちらにも上のXhtmlにおける「toc」とタイプ付けされた「<nav>」タグの方の内容が反映されているのが分かる。論理目次にもhtml目次にも「目次」という見出しと「開始」というリンク部分を持っている。
この左下の「開始」をクリックしても、紙面プレビュー画面でのhtml目次の「開始」のリンクをクリックしても、このEPUBの開始地点である「aaa」と書いてあるページに飛ぶことが出来る。
そしてその「aaa」が書かれているXhtmlファイルへの†ハイパー・リンク†( href="Section0001.xhtml")は、上の「<nav>」タグのリスト構造に囲まれた
<nav epub:type="toc" id="toc" role="doc-toc">
<h1>目次</h1>
<ol>
<li>
<a href="Section0001.xhtml">開始</a>
</li>
</ol>
</nav>
という部分に書かれている。
思うに、下の「hidden」属性(ユーザーに見えないようにする処置)をほどこされた「<nav>」タグ内の記述によって、「toc」というepub:typeやidを渡されたほうの「<nav>」タグの中身が、アプリやリーダー側の論理目次に渡されているのだと思う。
この上下の「<nav>」タグは必ず中に「 <ol> <li><a href="~~"></a><li>~</ol>」のリストとその中のリンク構造を持ち、この構造が壊れてしまったり中に余計な要素を入れてしまうと、アプリや機器側へのデータ受け渡しが上手くいかない=KindlePreviewerからエラーが出るのではないだろうか。
逆に言えば、この「<nav>」タグ内の構造自体を保持した状態(以下、自作の次に出そうとしている電子書籍の目次部)ならば、ある程度論理目次とhtml目次の体裁を維持した表記が可能である。
<body class="body0" epub:type="frontmatter">
<div style="margin-top: 15%;">
<nav epub:type="toc" id="toc" role="doc-toc">
<h4>レンフィールド・シンドローム</h4>
<ol>
<li>
<a href="section0001.xhtml">1.始まり</a>
</li>
<li>
<a href="section0001.xhtml#sigil_toc_id_1">2.彼女について</a>
</li>
<li>
<a href="section0001.xhtml#sigil_toc_id_2">3.私の趣味</a>
</li>
~~~
~~~
</ol>
</nav>
この場合では、まず「<body>」部にクラスで縦書きのスタイルを適用し、通常この「<body>」要素直下に先の「<nav>」タグリスト構造を持っているはずのものを一段「<div>」タグによって構造化し、その「<div>」要素に上部マージンを取らせることで、目次の表示部を画面中央へ少し寄せている。
この場合では「<nav>」タグ以下のリスト自体には手を加えていないため、その構造をHyperLinkで指定して下部「<nav>」タグから機械側へ指定しているであろう、論理目次のデータ構造を破壊していないというような気がする。
逆に、この画面上での目次表記をまず整えようとして、「<nav>」下に「<div>」要素を入れて目次リストを囲んでしまった場合では、KindlePreviewerに読み込ませてもエラーが出てしまった。
結局、この「<nav>」タグ内に他の要素を加え、html目次の見た目を弄ることはできないようである。いっそのこと、EPUB2のときのように論理目次とhtml目次は分けてしまった方がやりやすいのではないだろうか。
しかしそれを書くにはこのページの余白があまりに少ないため、一旦ここで次の記事へ分けようと思う。
その10へ。