KINDORU出版：外伝２ ～なーほーね。りかい、りかい～
先の記事で述べているように、私はとにかくいろいろとゴチャゴチャとした問題にハマり、遠回りをしてまずはEPUB形式での編集を行い書籍の体裁を整える方法をとることにした。
まずLibreWriterにカクヨムに掲載してきた小説の文面を引っ張って来て、文章的なあらかたの形を整える。
カクヨム版では横書きでスクロールを前提とした、段落ごとに開業を挟む方式で行っていたものを縦書き小説風に行を詰め、また段落の長さも以前の段落をつなげ長めにした。また、細かい内容の変更やその時に発見した誤字脱字の訂正。Web連載形式で各話に区切り、その頭と尻の方に説明やちょっとしたオチを入れていた部分を切り取り、一冊の本として内容がスムーズに繋がるように書き換える。
そしてその内容をLibreWriterの機能によって簡易なEPUB形式にエクスポートし、SigilというEPUB編集ソフトに読み込ませ、体裁を整えていった。
またはじめの何回かは、編集ごとに執拗にKindlePreviewerに読み込ませて確認し、エラーが出ないかを確認した。この時はまだいろいろと疑心暗鬼になっていたのである。
ただし後々から考えてみると、この時の私のこの疑心暗鬼に駆られた執拗な確認作業は、全くの無意味だったといっていい。
なぜならそれまでKindlePreviewer上で出ていたエラーのほとんどは、書籍メタデータの無効な入力や、その他電子書籍を定義する重要な部分における非正規の情報が邪魔をしていただけである。
そして、それ以外の文書内容の記述エラー等。主にXHTML上で電子書籍に無効な書式の入力のなかでSigil上でもエラーが出ないような機微なものは、単にKindlePreviewerでは無視されるだけで、読み込みエラーにはつながらなかった。
つまりＥＰＵＢ編集ソフトで上手く言った内容のものならば、それがたとえ失敗しても単にKindlePreviewerのプレビューに反映されないだけで、特に問題はなかったからである。別段おかしなところを弄らなければ、通常のテキスト装飾に収まるような本文内容の編集ではエラーは出ないわけである。
それなりに調べた人には分かるはずだが、EPUBはXhtmlというインターネット上のWebサイトを表示するHTMLの拡張版的な書式法を採用し、電子端末上でのレイアウトを決めている。
このnoteもそうであるが、インターネット上のWebサイトは、現代ではPＣ以外にもスマートフォンやタブレット端末、時にゲーム機やそれを介したＴＶモニタ上でも表示でき、非常に幅広い環境で利用されている。
そのように電子書籍もPC・スマホ＆タブレット、そしていわゆるKindleというような電子書籍端末のような様々な場合を想定しているわけである。
そして両者はその根幹をhtmlという表記法で制御されており、イメージとしてはこうしたWebサイトの文字・画像情報の記述に特化させたものが、EPUBのような電子書籍フォーマットなのだと言える気がする。
そしてその特化の方法も、「電子書籍ならば○○が出来る」というような拡張的な考え方ではなく、「電子書籍では××の機能をオミットしている（ゆえに、その他の方法をスムーズに行える）」というような、考え方なのではないだろうか。
実際に、販売できる電子書籍の書き方を指南しているKindleパブリッシング・ガイドラインのページでは、Kindle端末・アプリケーションでサポートされているhtml・cssのタグ一覧が示されているが、掲載されている中のいくつかは対応されていないとも表記され、しかも、これらがhtmlやcssの要素の全てではないだろう。
しっかりと調べたわけではないが、基本的には文章・文字をなんかいい具合にレイアウトするためのもののような気がする。しかも、それらのレイアウトは様々な環境で文章・文字の可読性を確保するため、かなりシンプルなものに制限をかけられていると感じた。
さて私は始めの試行錯誤の段階で、挿絵の用意できない文字だけの本を出すなら、縦書き二段組の形式にしてみたらどうかと考えた。
こんな適当に作ったイメージを使用する必要はあるのか。
縦幅が長く改行の頻度が少ない紙面では、Web用に段落を細かく区切り箇所によっては台詞の多い自分の小説は、どうしてもページの中で下側の空白が増えてしまう。それに段落ごとのインデント頻度が低く、ページの上端でも凹凸が激しくなってしまうのも、なんとなく格好が悪い。
つまり上下の二段組にすることで、ページごとの文字密度が高くなり、段落も一見して長くすらすらと文が続いているように見える。
このことにより読んでいる読者が「よし、文字が多くて頭がよさそうなぶんしょうだな」と思えるだろうという、私の非常に頭脳的なアイデアである。
しかし、この私のニュートンがリンゴの木を見て思いついたような、クールでスマートなアイデアはすぐに頓挫してしまった。何故かスタイルやcssに書いた「column」のスタイル指定が、KindlePreviewerでのプレビュー画面では適用されなかったからである。
その書式を書いている途中、確かにSigilのプレビューでは問題なく二段に分かれていた。しかし、その出来上がったEPUBファイルをKindlePreviewerに読み込んでみると、エラーは出ないものの文章のレイアウトは一段組、つまり普通の縦長縦書きの構成になってしまう。しばらくあれこれと試してみたが、ダメであった。
では次に、画面上端に空間をとり小説タイトルやその章のタイトルを、下端にも少し空間を取りページ数を表示。一段の縦幅を少しでも少なくし、ページごとの文章を多く見せようと、これまた冷静で的確なアイデアをひらめいた。
とにかく行の幅を制限すれば、文字が詰まってなんかいい感じにらるんじゃないかな。
しかし、結論から言うとこれもダメ。あれこれと調べたものの、どうすればいいのかさえも見当がつかなかった。
というのも、このあたりからようやく気付き始めたが、自分があれこれと調べてやろうとしていた小説の＝文字主体の電子書籍の場合、ページ・頁という概念が、通常の本やWebサイトのものと全く違うものだったからである。
この文字主体の電子書籍の型、リフロー型と呼ばれる電子書籍の形式では、製作者がその本の頁を割り振ることも、そのページごとのレイアウトを決めることもできないようであった。
このリフロー型という形式の本では、Xhtmlというほぼhtmlの書式法でその内容を書くことになるが、その中のかなりの表現方法は無視されてしまう。そしてそればかりか、ヘッダーやフッターのような部分の表記的な記述は無視されてしまう。
この形式ではhtmlのボディ部に記述された大量の本文を、その電子書籍リーダによってユーザーが設定した文字の大きさ行間の幅によってその場でページに割り振ってしまい、必ずしも同じページ数で内容が一致しない等、紙の本とは紙面の扱いが違っている。
さらにヘッダーを見出しとしてボディに内容を、フッターの方に様々なリンクなどを置いておくというようなWebサイトにおけるページとも違い、ひたすらボディ部に書かれた本文を、画面に収まるよう細かく区切った断片がページとなる。電子書籍リーダーは、その本文の区切りやレイアウトを的確に行ってくれるが、その仮想のページごとにページ数を表示したり、その章のタイトルをどこかに置くとかは基本的にはしてくれない。
表紙、登場人物、目次や扉などが並んだあと、画面端の余白をもった本文がひたすら続いてゆく。パブリッシング・ガイドラインによると、文字の大きさや行の間隔はユーザーごとのリーダーの設定に任せ、本文にあまり凝ったレイアウトを指定することは推奨されていないようである。
私たちはただ、Kindleパブリッシング・ガイドラインに書いてある通りのいくつかの注意点を守り、とにかく本文の文字情報を正しく記述すればいい。そうすれば、あとは電子書籍リーダーがそのユーザーの読みやすい設定にしたがって、勝手にその中の頁を振ってくれるという訳である。
私はこのリフロー型の理解によって、いくらかは納得できなものを心に抱えはしたものの、結果的には非常に楽に本を出せたと言っていいだろう。
その３へ。