弊舎のように古いテキストをEPUB化していると、どうしても避けて通れないのが外字。EPUBはユニコードに拠っていて扱える文字はShift_JISのように貧弱ではありませんが、それでもしばしばリーディングシステム上で豆腐（〼）になってしまうだろう文字に出食わすのは、仕方のないところです。

　多くの場合、作成段階で略字・書換字・異体字といったものに置き換えることで事前に対処可能ですが、そもそも文字そのものがユニコードや、ユニコード内の文字であってもリーディングシステム内に存在しないこともたまに（素材によってはしばしば）あり、その場合は文字画像を用意して文中にはめ込むことになります。

　で、当初から頼っているのが、グリフウィキ(GlyphWiki)なのですが、その利用が余りに簡便なので、まだ御存じないEPUB本作者のために簡単にご紹介しておきます。

　グリフウィキは大東文化大学の上地先生が管理されているグリフ（漢字字形）収集サイトで、wikiベースなのでブラウザー上で誰でも自由にグリフを作成・追加することができます。といっても、我々のような漢字の非専門家が安易に手を出すのは迷惑のもと。あくまで本体の編集には手を触れずに、そのシステムと成果を利用させていただくというスタンスでいいのではないかと思います。

　具体的には、捜す漢字がすでにグリフウィキ内に存在する場合は実に簡単。SVG画像として表示し、ファイルメニューから保存するだけ。後はそれをEPUBのイメージフォルダなどにコピーし、HTMLとCSSで文中に挿入します。その際、グリフウィキの文字は少し小さめのようですので、イメージの widthとheightは1.1emで指定しています。グリフウィキのフォントは細めの花園明朝ですが、SVG画像ですので文字を拡大縮小してもなめらかに表示され、一般的な明朝の本文表示のなかではほとんど違和感なく見ることができます。もちろん、リーディングシステムをゴシック表示に設定していたり、EPUB上でゴシック指定した場合は、その文字だけ明朝のままになりますが、それは現状では致し方のないところ。今のEPUBとリーディングシステムにおいて、外字を明朝・ゴシック双方で表示することは可能なのでしょうか。

　万一グリフウィキに目当ての漢字が見つからない・見つけられない場合は、作字ということになりますが、そのための専用のグリフエディタも用意されています。既存の文字の部品を組み合わせて作字することも、ゼロから手書きで作ることも可能。その辺のチュートリアルはヘルプメニューの「どうやって使うのか」に丁寧に説明されていますので、こちらもハードルはかなり低めです。ただ、我々非専門家はsandboxという練習用の文字升を使って作字し、それをSVG画像で表示して保存、利用すればいいでしょう。sandboxは作字の履歴が完全に残るようですから、もし必要なら管理者の方がコレクションに登録してくれるかもしれません。

　なんだか何も貢献せずいいとこ取りの利用法で申し訳ないような気もしますが、それも許容してくれているのがグリフウィキというシステム。おかげで実にスムーズに外字に対応できています。
　

　既刊の斎藤拙堂の紀行文『南游志』は、江戸末に熊野古道をほぼ忠実にたどりつつ紀伊半島を一周した旅の記録で、地図と突き合わせつつ読むといっそう興味が深まります。で、文中の主要な地名には外部リンクを施して国土地理院の地図に飛ぶようにしているのですが、個々の地点は把握できても旅全体の流れが地図上で確かめられないのがもどかしいところ。かといって、すべての宿泊地をポイントした付録地図では大雑把過ぎるでしょう。

　そこでGoogleのマイマップを利用して拡大縮小自在な南游志地図を作ってみたのですが、さて問題はこれをEPUBにどう組み込むか。Googleマイマップにはサイト埋め込み機能があって、〈iframe〉タグに囲まれた埋め込み用の文が書き出されます。一般のウェブページではこれをコピーペーストするだけで独自情報を盛り込んだ地図がサイトに表示できるというわけですが、EPUBに書き込んで見ると残念ながら空白ページになるかフリーズするかという結果に。

　結局、文中の地名リンク同様、既存の概略地図の下に外部リンクを置いて、ブラウザーでGoogleマイマップを表示することにしました。右のように、マップには宿泊地・経由地がポイントされ、地名一覧をタップすると各地点の説明や写真が表示されます（これはアンドロイドの場合、iOSのGoogle Mapsアプリでは少し表示が変わるようです）。写真はまだわずかですが、今後追加していく予定。もちろんリーディングシステム内に直接マップが表示できればよかったのですが、タブレットのブラウザーにもマイマップの操作はけっこう負担が大きいようですので（専用端末では推して知るべし）、さすがに読書アプリには無理な注文でしょうね。むしろ、ブラウザーと連携した電子書籍の外部リンクの可能性をもっと考えるべきかもしれません。

　先日出版した『南游志』でこれまで制作したEPUB本は12冊になりました。2012年春に読書アプリではKinoppy、端末ではソニーReaderがEPUB3に対応したのと前後して始めた電子本作り。それから２年半ほどしか経っていないわけですが、思い返すとけっこうな紆余曲折があって今に至っています。

　もうほとんど忘れていますが、そのドタバタを簡単に振り返ってみると、最初はAdobe InDesign CS5.5 がいち早く対応していたEPUB3書き出し機能だけを頼りにスタート。それ以前にPDF本として作った鏡花の短編選（のInDesignファイル）をとりあえずEPUBに書き出し、確かiPod touch だったかのKinoppyに読ませて、初めて縦書き・ルビ打ちで表示された時は感激したものです。

　ただ、そのままでは本としての完成度は低いので手を入れる必要があります。InDesignのEPUB3書き出しファイルの悩ましさは相当なものですから。で、ネットでEPUBエディターのSigilを知り、これでInDesignが吐き出したEPUBを何とか望む姿に近づけようとします。といっても、当時はEPUBの知識はおろか、tableレイアウト一点張りの古いホームページ作者の通弊で、CSSの知識も皆無だったので、作りながら勉強するというトライアル＆エラーの繰り返し。ただ、その際、DropboxにEPUBを置いて、Sigilも読書アプリも端末もDropboxをハブにして書き出し・読み込みをするようにしたのは正解だったと思います。そうでないと、まどろっこしくて試行錯誤なんてやっていられません。

　もっともSigilにも問題があって、本来はEPUB2までしか対応していないため、EPUB3書籍を作るのには少々無理がありました。記述がある程度自動化されているため、EPUB3に必要な記述を勝手に書き換えられていたりといったことも頻繁に起こります。ただ、それでもしばらくSigilを使い続けていたのは、EPUBの書き出しが便利で、簡便にトライ＆エラーができたからですが、書き出しの際に書き替えも起こるので痛し痒しです。

　ついにはSigilを放棄する決心をして、ここは一度きちんと勉強しなくてはと、当時出版され始めたEPUB3の参考書（左サイドバー下部に置いている３冊）を読んでみました。で、はっきりしたのは、EPUBというのはウェブページと同じく、HTMLとCSSにより記述されたもので、しかもその限定機能版なのでそんなに複雑なものではないということです。ただ、それらを本として統御するための幾つかのEPUB独自のファイルを用意する必要があるのがウェブとは違う所ですが、これらもEPUBエディターならほぼ自動で制作してくれます。そして、Sigilに代わりEPUB3に対応したエディターとしてFUSEeβという日本製Windowsソフトがあることを教えられました。

　以後、FUSEeβは今に至るまでEPUB本制作の重要なツールの一つになっています。（ただし、その名の通りFUSEeβは無料のベータ版で、現在はもう公開が停止されていて、有料版のFUSEeしか入手できません。）ただ、完全にこのソフトに任せきっているかというとそうでもなくて、仕上げの段階ではFUSEeβを離れて、直接ファイルを編集する必要も生じます。前置きが長くなってしまいましたが、以下、簡単に現在ほぼ固まった晩霞舎流の制作手順をご紹介します。

手順１．まずはエディターでテキスト入力
　本づくりの作業の大半を占めるのは実は入力。既にテキストデータがある場合は別にして、当サイトがめざすような発掘的出版の場合は、ゼロからのテキスト入力に多くの時間を費やすことになります。この場合、入力のツールとして適しているのがテキストエディター。プレーンテキストさえ残ればいいのですから、重いワープロソフトやましてDTPソフトなどは不要。UTF-8で保存でき、バックアップ機能がしっかりしていて、縦書き表示が可能な、定番の秀丸エディタを使っています。もちろん素材柄、漢和辞典と文字検索ソフトの今昔文字鏡、そしてウェブ上の和漢のサイトによる文字・語句・書籍などの検索も欠かせません。本文と注釈はエディター上でほぼ入力します。ルビタグや気が向けば<p><br />タグなども一応この段階で入れておきます。

手順２．FUSEeβで電子書籍に組み上げる
　テキストデータが揃ったら、コピーペーストでFUSEeβに移して、電子書籍として組み上げていきます。ここからは、根気勝負の入力も終わり、いろいろ体裁を工夫しつつ本を作る、楽しい工作の要素が大きくなります。少しずつ本としての形が整っていくのを、時々、リーディングシステムに読み込んで確認するのも楽しいものです。ほぼパターンの決まった表紙や目次、扉、奥付などのページは、以前の本のものを流用して中身を入れ換えるだけで手間なくできます。 CSSも大部分は書籍共通ですから、これまでのものを流用して、一部に手を加えるだけで済みます。FUSEeβはビューワモードにすると、ページの体裁が確認でき、HTMLに誤りがあればその旨指摘してくれますので、作っては確認の作業もほぼFUSEeβ上で行うことができます。
　ここでFUSEeβを使う際の注意点として、幾つか気がついたものを上げておきます。たぶん有料版のFUSEeにも共通するものもあると思います。
●まず環境設定を
　作業を開始する前には、ファイルメニューから環境設定のダイヤログボックスを開いて、自分なりの作業環境を整えておきます。必ず変更するのは「コード編集」「カバー・目次」「ページ」で後はデフォルトのままにしています。「コード編集」では各ページの編集の際の表示を設定。特に「ウィンドウの右端で折り返す」は必須です。「カバー・目次」では特にシステム目次ファイルの自動生成についての設定が重要。ここは、各ページの<head>タグ内のタイトルが目次となるように設定しています。また「ページ」では各ページのHTMLコードの定型文を設定しておくことができます。ここでEPUB3に準拠した設定をしておかないと、最後のEPUBチェックの際に手間が増えることになります。上のリンクで私の場合の環境設定を紹介しています。
●ビューワで頻繁にミスをチェック
　上に書いたように、FUSEeβはビューワモードにすることで、HTMLの記述ミスを確認することができます。ただ、訂正は自力でしなければならず、広範囲に多数のミスがある場合は、その個所を見つけるのにも苦労しますから、制作の途中途中で頻繁にビューワモードに切り換えて、ミスが発生していないかを確認することが大切です。
●EPUB特殊ファイルはあくまで自動生成で
　content.opf・toc.ncx・nav.xhtmlという３種類の重要なEPUBファイルを自動的に作ってくれるのが、FUSEeβを使う最大のメリット。逆に、この自動生成を切って、手動でこれらのファイルを編集しプロジェクトファイルに保存した場合、FUSEeβが再びプロジェクトファイルを読み込めなくなるという事態がけっこう発生します。だから、FUSEeβを使用している間は、上の３つのファイルはアンタッチャブルと考えた方が無難。３つのファイルを手動編集するのは、下の手順３のように、FUSEeβではなくテキストエディターで行います。

手順３．チェック後の訂正は再びエディターで
　EPUB本作りの最終段階は二つのチェック、EPUBのコーディングのチェックと、文章の文字校正です。EPUBのチェックにはpagina EPUB-Checkerというフリーウェアを使っています。公式のepubcheckツールに準拠しながらも、コマンドプロンプト無しでチェックができるお勧めのツールです。もちろんチェックの対象はEPUBファイルですから、FUSEeβでの編集が完了したら、ファイルメニューからEPUBを書き出して、それをEPUB-Checkerに通します。すると、FUSEeβが自動生成したcontent.opfやtoc.ncxファイルには意外に多くのエラーが見つかります。EPUBとしてちゃんと動作しているファイルですから、「厳密に言うと間違い」といったレベルのエラーでしょうが、もちろん修正してエラーゼロにするに越したことはありません。また、一般のページのコードミスも指摘されますが、これはFUSEeβでもチェックできるものです。
　さて、上に書いたように、content.opfやtoc.ncxの手動訂正にはFUSEeβを使わないのが吉。そこで、EPUBの圧縮を解いて、素のフォルダーとファイルの集まりに戻した上で、必要ファイルを編集します。手順は、EPUBファイルの拡張子を.zipに変更して解凍。OEBPSフォルダーの中のエラーが見つかったファイルをそれぞれテキストエディターで開いて編集。そしてまたEPUBにパッキング。パッキングにはePubPackというフリーウェアを使っています。パックするEPUBソースのルートディレクトリにあるmimetypeファイルを指定し、出力先とフォルダ名を設定すれば、ワンクリックでEPUBがアウトプットできます。実に簡単なので、EPUB本の最新版は素のファイル・フォルダー群で保存しておいて、訂正があればエディターで行い、ePubPackで出力という具合にEPUB本を管理しています。
　もう一つのチェック、文字校正は端末上で行います。ごちゃごちゃとタグの付いたソースファイルではとても中身に集中できないからです。そして、じっくり落ち着いて読み込むには、電子ペーパーの専用端末がベター。まず原典と突き合わせながら、次は本単独で、本作りには付き物の誤植を洗い出します。また、目次や注釈などに施したリンクジャンプが正しく働くかも一つ一つチェックする必要があります。見つけた間違いは端末のマーク機能で印をつけておき、後ほど一気に訂正。手順はコードミス訂正の時と同様です。

手順４．端末別対応は最後に
　コードチェックと校正が済んだらめでたく出版と言いたい所ですが、最後にやっておきたいことがあります。それは端末別の対応。具体的にはKobo touchを始めとする楽天の専用端末の場合、ファイル名の.epubの拡張子の前に.kepubを付けないとEPUB3として読んでくれないだけでなく、そのままではしおりやメモが残らないという迷惑な仕様になっています。これを改善するには、文章の小さな単位ごとにIDを振る必要があります。さすがにセンテンスごとや段落ごとはつらいし、ファイルも無駄にふくらむので、晩霞舎の電子書籍ではもう少し大まかな単位にしていますが、このkoboID付きEPUBを別に用意するのを、最後の作業にしています。あるいは、Kindle出版も併用する場合は、さらにKindle用の変更を加えたファイルが必要になるかもしれません（最新のKindle出版の情報を把握していないので、この辺は曖昧です）。ともあれ、ここでEPUBファイルは２つあるいは３つに分化しますので、コードチェックや文章校正はその前にしっかりやっておかないと、その後では訂正の手間が２倍３倍に増えるということになります。

　現在の晩霞舎流のEPUB本作法はこんな感じですが、最近はEPUBをかなりの程度まで自動作成してくれるソフトやウェブサービスも登場していて、それらに比べれば非効率な作り方でしょう。ただ、本の内容に従ってある程度柔軟にページの体裁をコントロールするためには、手作業の部分を残しておくことも必要で、それがまた個人的には電子本作りの楽しみの一つにもなっています。

　Kindleの固定レイアウトのサンプルを見ていたら、ダブルタップでテキストを画像上にポップアップできる機能があることを知り、それを利用して写文集を作ってみました。

　サンプルはこのページにある「Graphic Novel example」というリンクからダウンロードできる「ComicSample」という圧縮ファイルの中にある「The Absurd ABC」というmobiファイル。圧縮ファイルの中には他にmobiのソースファイルも入っています。

　「The Absurd ABC」というサンプル本には、Kindleの「領域拡大（Region Magnification）」の実例がたくさん入っていますが、今回目を引いたのは、最初の「copyright」のページの、画像による文字ページをダブルタップすると、テキストがポップアップされる機能です。最初はポップアップも画像かと思ったのですが、よく見るとテキストのよう。ソースのcopyright.htmlをエディターで開いてみると、確かにテキストがbody要素に書き込まれています。

　☞☞　

　で、思いついたのが、これを利用したら面白い写文集ができるのではないか、ということ。以前から撮り溜めた山の写真を素材に電子本を作ってみたかったのですが、素人写真を固定レイアウトでただ並べるだけでは芸がないので、文章も加えて色を着けてみたいところ。しかし、固定・リフロー混在にするにしても、固定オンリーで行くにしても、写真ページと文章ページが入り交じるというのは、少し冗長なような気がします。その点、写真をダブルタップして文章が表示できれば、無駄のない作りになります。

　copyright.htmlをのぞくと何やら幾つもdivタグが重ねられています。画像の配置に加えて、ダブルタップする領域やテキストをポップアップする領域が指定されているようです。IDが振られたものも３つほどあります。このサンプル本では複数のページのそれぞれ異なった場所で領域拡大がセットされていますので、それぞれにIDを振っているのでしょうが、今回の写文集ではポップアップの仕様は全ページ同一でオーケー。そこでややこしい構造に頭を悩ませながら、ID指定をCLASS指定に変更。

<div class=”fs”>
<div>
<img src=”../images/01.jpg” class=”singlePage” />
</div>
<div class=”bun”>
<a class=”app-amzn-magnify” data-app-amzn-magnify='{“targetId”:”bun-magTargetParent”, “ordinal”:1}’></a>
</div>
<div id=”bun-magTargetParent” class=”target-mag-parent”>
<div class=”target-mag-lb”></div>
<div class=”target-mag”></div>
<div class=”text”>
<p class=”part”>1.</p>
<p>
九十九折の登山道を、<br />
…

　真ん中あたりの「data-app-amzn-magnify」が領域拡大のスイッチで、その下のテキスト画面の設定は３層重ねになっているようです。もちろんCSSの方も、これに合わせて適宜書き換え、テキスト画面のサイズ・色・透明度なども変更しています。フォントの指定はserifだけではなぜかゴシックになってしまいますが、TBMinchoを直接指定すると明朝にできました。

　コーディングにはまったく自信がありませんが、これで何とか目的の文章ポップアップ型写文集が実現できています。作り方のせいなのか、環境の問題なのか、若干動作が不安定になる時もありますが、本を開き直せば戻りますので、大過はなさそう。動作の具合はKindleストアの無料サンプルで確認できます。また、DRMは設定していませんので、calibreというソフトを使ってKindle本をEPUBに変換して、ソースを流用することも可能だと思います。

　☟☟　

　先月出版した『花月新誌文集』は４冊目の柳北本です。最初はここまで成島柳北にこだわることになるとは思っていなかったのですが、知れば知るほど幕末・明治前期の文筆家としては抜群の存在であることが分かり、それに比して認知・評価が低いことが残念で（さすがに加藤周一の文学史にはかなりのスペースが割かれていますが）、そのギャップを埋めるべく微力を投じてみた次第です。

　とはいえ、素人の中途半端なアプローチではかえって柳北先生の真価を傷つけるのではないか、という心配もなきにしもあらず。確かに注釈面では、たとえば岩波文庫で今唯一読める柳北本『航西日乗』の綿密な注に比べれば、その至らざること甚だしいものがあります。ただ本文に関しては、あの句読点や段落もなく、ルビも最小限の片かな交じり文という原典を、なんとか読めるものに仕上げることができているのではないかという自負もあります。

　柳北本はこれにて打ち止め、と言いたい所ですが、実はまだ超大物が控えています。それは朝野新聞に10年間に渡って執筆した「雑録」で、これこそは明治以後の柳北の代表的な仕事といえるものです。ただ、その数は膨大で、しかもその数を確定することさえ難しいという難物です。というのも、朝野新聞に掲載した際に柳北の署名があるものはごくわずかだから。しかしその他の多くも柳北の手になるのではないかと思わせる証拠は多々あります。つまり「朝野新聞雑録集」の出版を志す人は、まず膨大な「雑録」一つ一つを吟味して柳北の筆触を見分けるという作業から始めなければならないのです。

　もしそれができたと仮定しても、その後は例の原典との格闘が延々と続くわけで、これはどう考えても一個人出版者の手に負えるものではないでしょう。とはいえ、これにせめて目を通しておかないと柳北を理解したとはいえないのも事実。元気のある時に、図書館にこもって朝野新聞縮刷版から柳北コラムを抽出する作業をやってみたいと考えています。本にするかどうかは、その先の問題。

　さて、「余話」といいつつさらに前置きが長くなってしまいましたが、今回の『花月新誌文集』ではこれまでの柳北本と作り方を変えたことが一つ。これまでは注をまとめて巻末に置いていたのを、今回は一編ごとに置くようにしました。というのも、本文からリンクで注記に飛び、また戻るという端末・アプリ上の操作がうまくいかない場合も少なくないのではないかと考えたからです。最悪の場合読み手は巻末に取り残されて、読んでいたページまで手探りで戻るという迷惑至極なことになります。その点、一編ごとの注では手作業で戻っても数ページで、許容範囲でしょう。また制作面でも、注に番号を振る場合、全巻通し番号の注では、追加や削除が出た時の番号の振り直しが面倒なのが回避できます。以後、できるだけ小さな単位で注をまとめるという原則でやっていきたいと考えています。

　ところで、毎回頭を悩ませるのが表紙のデザイン。内容と関係があって、絵的にも面白そうなものをと考えるのですが、もちろんプロが作るようにはいきません。ただ、最近の電子書籍の表紙の傾向として、親しみやすさを考えたためでしょうが、やたらと漫画チックなものが多いのは、ちょっとどうかと思います。吉川英治までが劇画調の表紙になってたのにはあきれました。まあ、電子書店はどうしてもカタログ的な表紙の一覧というスタイルになりますから、目を引いてスクロールの手を止めさせるという点で、表紙のインパクトは印刷本以上に重要です。そして、今のところ主な客層である若者は多くが漫画から電子書籍に入っているでしょうから、小説などの表紙も同じ雰囲気でということになるのかもしれません。しかし、本来、物語本の最大の強みは文章を通して読者の想像力を刺激し、自由にイメージを羽ばたかせることができる点。なのに表紙に登場人物などの具体的な絵を載せてしまうというのは、出版社自らがその機能を狭めたと言われても仕方のない悪手だと思います。たぶん著者にとっても迷惑千万でしょう。

　それはともかく、『花月新誌文集』の表紙はタイトルバックに小林清親の版画を使いました。この絵には花盛りの隅田堤と川遊びが描かれていて、この本で柳北が繰り返し讃えてやまない墨堤爛漫の楽しみにぴったりだったからです。実はこの絵に行き着くまでには、高橋由一の「墨堤桜花」でどうかと画集を買ってみたり、古い桜の名所の写真を探したり、結構右往左往しました。しかし、そんなことが個人出版の楽しみの一つだったりもします。小林清親の版画を見つけたのは「Ukiyo-e.org」というサイトのおかげですが、これがまたすばらしいデータベースで、蛇足ながら浮世絵に興味のある方にはお勧めです。　

　昨日EPUB出版した「新柳情譜」は実は予定になかった本です。成島柳北のコラムをぼちぼち入力しつつ、いろいろと資料を調べているうちに、森銑三がこの芸妓列伝を激賞していることを知り、しかも、以前に一度阪大の先生が「花月新誌」の掲載ページを集成して影印出版しただけで、まだ活字本としては手つかずなのに気づいて、急遽作ってみた次第です。

　底本は、高価なゆまに書房の「花月新誌」復刻版を買わなくても、Googleさんが慶応義塾図書館の蔵本を全号公開してくれています。実にありがたい時代になったものです。このGoogleブックスや早稲田の古典籍総合データベース、近デジをサルベージすれば、EPUB出版に値する本が山ほど眠っていそうです。

　分量的にさほど時間はかからないだろうと思ったのですが、注の方で意外に苦労しました。というのも、柳北先生がその有り余る教養を駆使して、漢詩や本文でも、中国古典のソースをばんばん使っているからで、それを一つ一つ裏取りしていくのはかなりの手間です。でもここでも、実にいい時代になったもので、ほとんどはネット検索で片がつきました。特にありがたかったのは中国の百度百科や漢典などの検索サイトで、簡体字ながら何とか意は汲めますし、絞り込んで日本語サイトにたどり着く糸口にもなります。もちろん有名古典に関しては、日本でよく勉強されている方のサイトが助け船になりました。

　といっても、実は注記を断念している箇所も一二あり、また背景に気づかずにいる語句もきっとあるだろうと思います。制作の過程でも注記を後から追加することたびたび。そんなこともあろうかと、今回は敢えて注記に番号を振らず、よって本文にもアスタリスク（＊）のみを付しています。一度振ってしまった番号を、注記の追加で更新するのは大変だからです。また、語句に注記へのリンクを張ると、リーディングシステムによってはいやおうなく文字に装飾がついてしまうので（CSSで止めているのに）、字面の美観と読みやすさからそれは避けたく、アスタリスクのみにリンクを施しています。小さなアスタリスクをタップして注にジャンプし、番号のない注記を探すのは面倒かもしれませんが、前者に関しては最近の端末は感度が改善されているので、慣れればさほど苦労はないはず、スマートデバイスではダブルタップで拡大すればよりタップしやすくなるし、という言い訳を用意しています。

　こうして、いざ公開となって迷ったのは、Amazonに出すべきかどうか、ということでした。前回の「茅野蕭々詩集」では購入ルートは新進決済サイトのGumroad（ガムロード）のみとしたのですが、みごとに前回の投稿で危惧した通りの経過を辿っています。別に落胆はしていないのですが、本の読者対象の超ニッチさに加えて、決済サイトへの不安もその理由の一つとなっていなくはないかもしれません。「茅野蕭々詩集」はそろそろAmazonに卸す方がいいのかもしれませんが、この本をいきなりAmazonに預けるのは面白くありません。

　なぜか、といわれると、感情的・感覚的にというしかないのですが、それを少し敷衍してみると。
１．せっかくEPUBというオープンで自由な規格があり、今や個人がそれぞれの場から自由に販売・流通できるシステムも整いつつあるのに、巨大な私企業に頼らなければならないのは残念だ。
２．しかも、Amazonのシステムには少し理不尽なものを感じる。特に例のKDPセレクトというもの。70％の印税欲しさにKDPセレクトに登録してしまうと、Amazon以外では売ることができなくなり、EPUBというオープン規格で本を作った意味がなくなる。
３．これを嫌ってKDPセレクトを避けると印税は35％になり、Amazonに半分以上持っていかれ、しかもそのままでは米国に税金も取られてしまう。35％だって従来の本の印税にくらべたら御の字だという人もいるが、それは企画・編集・デザイン・校正・印刷・製本・流通などの人的・物理的なコストが実際にかかっているからで、我がEPUB本などはそれを全部一人でやっていて、本の制作に関してはAmazonさんに一切手伝ってもらった覚えはない（まあ、Amazonのパブリッシングシステムを使って本を作った場合は、少し事情は違いますが、それでもA社の関与は限定的です）。なのに65％頂戴というのは、厚かましいにも程がある。
４．単純にKindleのフォントが嫌いだ。個人的にはあんな字面で本を読む気がしない。読んでほしくない。（これは八つ当たりか）
　といった所でしょうか。

　要するにEPUBの可能性を信じるがゆえに、それを離れることはできないし、だからといってAmazonの暴利システムを甘受するのも釈然としないという判断保留状態なのですが、しばらくはこのままEPUBのみで行って、このオープン規格の流通の回路が開けるのを辛抱強く待つのも楽しいかもしれないと思ったりしています。

　春以来だらだらと作り続けてきた標記の電子書籍を、昨日ようやく出すことができました。

　今回は有料出版とし、それもKindle出版でもiBooks出版でもなく、Gumroadという決済サイトを利用した自前出版としました。そのうちアマゾンさんに頼ることになるかもしれませんが、こうした明治・大正のほとんど忘れられた詩人の詩集というような超ニッチな本の場合、マーケティング云々は無視して、そっとそこに置いておいて、探してたどりついた人が時たまポツリポツリと買っていくという在り方が、好ましいのではないかとも思っています。それが売れないとたちまち店頭から消えしまう、ということのない、電子書籍の長所でもあります。

　ただ、こういう詩人に興味を持つ人が、電子書籍を読める環境にある確率は、現在のところ極めて低く、もしそういう人がいたとしても、怪しげな個人サイトからよく分らない支払いサイトを使って買うというのもハードルが高いに違いありませんから、果して一冊でも売れるのかどうかと（一冊は自分で試し買いしてみましたが）、危ぶんでいるのが正直なところです。

　といっても、本自体は力を入れて作ったものですし、何よりも自分自身がこの詩人への関心に動かされて詩を集め、感想めいたものを綴りもしたものですから、それなりに満足感を感じています。もし東京へ行くことがあれば、雑司ケ谷の塋域を訪ねて、墓前に一冊、とはいかないので、ソニーReaderのページページを泉下の詩人に捧げても恥ずかしくはないものに、一応はなっていると思っています。詩人は眼を白黒させて、現れては消えるはかない蜃気楼のようになってしまった自分の詩の有り様を嘆くかもしれませんが…。

　さて、思えば盲蛇に怖じずで、電書工房などと称しながら、低スキルにも程がある素人工作の試行錯誤を一年半ほどに渡って書き残してきたこのサイトですが、一応はおもだった本作りの技術的課題にめどがつきましたし（その程度でか、と言われれば一言もありませんが）、出版物やウェブに確かな技術情報が揃ってきた今となっては、生かじりの発信はもはや有害とも思われますので、以後は電子書籍の技術問題よりも、個人出版をとりまくあれこれ、また本作りの過程で出会ったコンテンツ的な疑問点などについて、時折発信していければと思っています。

　とりあえず、次の出版目標は成島柳北のオリジナルなコラム集。これは素材が膨大なため、気の長い作業になりそうです。また、江戸の地元詩人を追慕する本なども楽しみつつ作ってみたいと考えています。

　先月末に初めて有料出版してみたKindle版の「航薇日記」。その後の販売数はもちろん微々たるものですが、それでも買ってくださる方がいることに胸おどる思いを味わっています。思うに、こういう、紙の本で出版・再版されることがほとんど期待できない本で（「航薇日記」は今度復刊された筑摩の「明治文学全集」に収録されていますが、注なし、句読点なし、ルビなしの底本そのままという形）、けれど読みたい人は少数ながら必ずいて、読まれる価値もあるというような本こそ、電子書籍の出番ではないでしょうか。今のところ、KDPを初めとする 電子書籍の自主出版は、書き手になりたい人に大歓迎され、そのデビューのハードルを一気に引き下げたことで注目されているようですが、一方で、こういった埋もれていた本やテキストに光を当てるという役割についても、もっと注目されていいのではないかと思います。そして、そうした本の発掘と書籍化にはパブリックドメインのテキストを流用するのとは格段の労力が必要ですから、KDPのような有料を前提とした出版・流通システムを活用することで労力への報酬がある程度期待できるようになれば、青空文庫とはまた違った電子化のムーブメントが始まるのではないかと期待しています。

　ところで、KDP本を買ってみてまず気になるのが、内容よりも校正漏れの多いことではないでしょうか。文字校正というのは、単純そうでいてかなりの手間と習熟が必要な作業で、本来プロが二度三度と行ってようやく校了となるものです。しかもそれで完璧だとは誰にも 保障保証できません。自主出版者がたった一人で完璧を期するのはどだい無理な話なのです。と、エラそうに書きましたが、それはもちろん当方にも当然あてはまり、「航薇日記」にも出版後に文字の誤りと機能不全がいくつか見つかりました。それも雨垂れ式に。

　前回書いたように、KDPでの本の訂正は簡単で、訂正したファイルを再度アップロードすればオーケー。訂正版でもその都度、アマゾンの審査を通過しなければならないらしく、差し替えられるまで少し時間がかかりますが（二度三度と訂正を繰り返しているうちに、それまで何事もなくパスしていたのに、著作権切れの根拠を示せというメールが来たのには驚きました）、それだけのことです。

　ところが、出版直後に試しに自分で購入していた「航薇日記」を、端末から一旦削除して再ダウンロードしても、訂正が反映されていません。再出版途中でプレビューしたファイルはちゃんと訂正されているのに、どうしたことかと調べてみると、一度購入・ダウンロードされたファイルは、訂正があっても自動的に差し替えられるというわけではないようです。すでに購入された本の更新については、出版者がアマゾンにその旨申請する必要があるよう。そして、アマゾンが大きな修正だと判断した場合は、購入者にメールが行き、MyKindleから修正版がダウンロードできるようになりますが、小さな修正だと判断した場合は、修正版がダウンロードできるものの、メールは行かないということになっているようです。だから後者の場合は、修正・改版の通知は本の説明ページなどに入れておくしかなさそうですが、すでに購入した人がそれを読むことはあまり期待できず、苦しいところです。しかも、アマゾンが対応してくれるまで「４週間以内」とけっこう待たなければなりません。その間にまた訂正が見つかりそう…。→KDPヘルプ「更新に関してお客様に通知」

　もっと簡単にできないものかと思ってしまいますが、まあ、出版者にしっかり校正をやってから出版せよ、また安易に手を加えてしまいたくなるような煮詰めの甘い状態で出版するなと、警鐘を発する意味もあるのかもしれません。また、読者の立場に立てば、制作者のミスで再ダウンロードしなければならないのは迷惑な話だし、栞やメモなどを残していればそれが消えてしまうのを甘受しなければなりません。校正ひとつを取っても、既存出版社と電子書籍の自主出版者とのレベルの差は月とすっぽんで、多くの読者があらかじめ予想できる作者ならば、プロ校正者に依頼するといったことも可能でしょうが、それは例外的なケース。今後も誤植だらけの自主出版本という事態は容易に解消されないのではないかと思いますが、もちろん他人ごとではありません。有料・無料に関係なく、電子本のチェックは徹底してと胆に命じた次第です。（しかし自信ない…）

　先日アップした「航薇日記」には漢詩がけっこうな数含まれていて、その扱いがひとつの悩み所になりました。

　底本では柳北が旅中に作った漢詩は、一字下げの別段落で、句ごとに改行せず句点で区切り、日本独特の漢詩表記法である訓点・送り仮名を振って記されています。また、他の人が過去に作った漢詩などを引用する場合は、本文中に改段せずに流し、やはり句点で区切りつつ訓点・送り仮名を振って記されています。前者については、よくある古典出版での漢詩の記載法、句ごとに改行し、白文の（漢字だけの）漢詩を記し、その下に読み下し文を付けるという形をとることにしましたが、後者の引用詩についてはそれでは大げさなので、鍵括弧でくくって底本通りに文中に流し、訓点・送り仮名を施すことにしました。そこで問題になるのが、訓点・送り仮名をEPUBでどう再現するか。以前から気になっていたことですが、ようやく実作で直面することになりました。

　EPUB日本語基準研究グループの「EPUB3日本語ベーシック基準」をのぞいてみると、この点に触れて、「（CSSの上付き・下付きを利用して）漢文も、返り点または送り仮名のいずれか一方であれば、これを使って表現可能。しかし、現時点では、返り点と送り仮名の同時指定はできない。」と書かれています。上付き・下付き（縦書きでは右付き・左付きになる）が利用できるのは嬉しいですが、確かに訓点と送り仮名が同じマスに左右に並ぶケースは多いので、どちらか一方しかというのではまさに片手落ちです。

　で、思いついたのが「ルビ」を利用してはどうかということ。ルビは右付きですから、送り仮名の代用として使えるかもしれません。訓点はspanタグでくくって、CSSで下付き指定 vertical-align:sub をし、送り仮名はルビで送り仮名を振る漢字の右に付けます。そのままでは漢字の真横に付いてしまいますので、空白を一つ頭に入れてみました。こんな具合。
「<ruby>年<rt>　ニ</rt></ruby>採<span class=”sub”>㆓</span>江南牡蠣<ruby>兒<rt>　ヲ</rt></ruby><span class=”sub”>㆒</span>。春潮淺處<ruby>養<rt>　フ</rt></ruby><span class=”sub”>㆓</span>香<ruby>肌<rt>　ヲ</rt></ruby><span class=”sub”>㆒</span>。廣洲<ruby>已<rt>　ニ</rt></ruby><ruby>是<rt>　レ</rt></ruby><ruby>避<rt>　ク</rt></ruby><span class=”sub”>㆓</span>三<ruby>舎<rt>　ヲ</rt></ruby><span class=”sub”>㆒</span>。上國未<span class=”sub”>㆑</span><ruby>知<rt>　ラ</rt></ruby><span class=”sub”>㆓</span>風<ruby>味<rt>　ノ</rt></ruby><ruby>奇<rt>　ヲ</rt></ruby><span class=”sub”>㆒</span>。」

　恐る恐るEPUBに書き出して表示させてみると、おお、意外にうまくいっています。本来は訓点と送り仮名は同じマスにあるべきで、この方法では送り仮名は少し上めになってしまいますが、見たところ違和感はあまりありません。文中の漢詩では分りづらいので、別にサンプルを作って各端末に表示させてみたのが下の画像。上からソニーReader・kobo・Kindleです。上二つはそのままでオーケー。訓点とルビの左右のバランスが一番いいのはReaderで、koboは下付きにした訓点の位置が少し内寄り、というかフォントの左端に揃っています。左端をはみ出すReaderの下付きがイレギュラーということでしょうか。おっと、Kindleはどうしたわけか訓点がすべて横倒しです。訓点はユニコードの漢文用記号3190～319Fを使っていますが、Kindleではそれが半角英数と同じに解釈されて正立しない、ということでしょうか。仕方なくkindle用のEPUBを別途用意して、訓点に縦中横を適用するとうまく正立しました。訓点の位置はkoboと同じく文字の左端揃いになります。

　ちなみに訓点と送り仮名を下付き・上付きで指定した場合の仕上がりはこんな具合。どちらが上に来るかは指定の順番次第ですが、やはり少し苦しいですね。訓点と送り仮名で二マス分を取ることになり、かなり間延びします。一マスに上付き・下付きが同居できるようになるまでは（なるのか？）、訓点は下付きで、送り仮名はルビを流用して、というのが次善の策ではないかと思います。

　先日アップした「柳北奇文」には、さすがに著者が幕府奧儒者を勤めた大先生だけあって、一般的ではない漢語や中国の故事に基づく表現がたくさん見られます。当時の読者にはそうした表現もすぐに通じる漢文の教養が備わっていたのでしょうが、もちろん我々にはちんぷんかんぷん。ただ、有り難いことに今はインターネットという手軽に利用できるジャンルを問わない大事典があって、昔よりは格段に容易にそれらを読み解いていくことはできます。近くにパソコンがあればそれを使って、パソコンがなくても今時の読書端末には語句から辞書引きやネット検索ができる機能が備わっています。

　とはいえ、ネット検索にも習熟が必要ですし、まして読書端末からの細かなタップに苦労し、遅い端末の反応にイライラしながらの検索は、読書の興を妨げること甚だしく、まだとても常用できる作業とはいえません。特にこうした中国故事などといった面倒な材料の場合は、分からなければ検索システムでどうぞというわけにはいかず、結局旧来の「注」を施すことが電子本の場合も必要という状態がまだまだ続くのではないでしょうか。端末の検索システムが役立つのは、注を付すほどでもないちょっとした語義の確認や英単語などの場合に限られるのではないかと思います。オンライン化された読書システムには、こうした語句の検索だけでなく、ソーシャルメディアへの発信による感想の共有といったことももちろん機能的には可能で、それが注目されてもいますが、そうした周辺機能が読書の興を妨げるようでは本末転倒で、結局はカタログ機能だけで終わるということも十分に考えられます。

　という次第で、「柳北奇文」にも注を付けることにしたのですが、さてどんな注にするかにちょっと迷いました。注には大きく分けて、語句のすぐ近くに配置する頭注・脚注・傍注と、まとまった文の後や巻末に配置する後注がありますが、EPUBで今のところ実現可能なのは後者。で、後注を付けるとして、それは章末などの各項目ごとがいいのか、巻末にまとめるのがいいのか。項目ごとに注を付けるのは、読んでいる位置からすぐに見に行きやすいからで、古典やマニアックな著作など注が多数ある場合を除いては、紙の本ではこの方式が多いように思います。しかし読書システムの場合は、紙の本ほどページめくりが手軽ではなく、一方で文中リンクが効くため、注はページをめくって読みに行くものではなく、リンクでジャンプして読み、またジャンプして戻るもの、ということになり、項目ごとの注にはさしてメリットがないといえます。さらに言うと、項目ごとの注には整然とした紙面の美観を妨げるというデメリットも指摘できます。

　そんなわけで巻末にまとめて後注を配置することに決定。次に迷ったのが、注はリンクで飛んで戻ることを前提にするとして、どんな形でその語句にリンクを付けるかということです。できるだけ紙面を乱したくないので、CSSでリンクの装飾は無しにします。するとどれが注のある語句か分らないので、何らかの印が必要。アスタリスクを付けることも考えたのですが、より親切に語句の後に通し番号を振ることにしました。通し番号は小文字の上付きとし（縦書きでは右付きになる）、縦中横とともにCSSで指定。もちろん語句自体には後注内の各項目へのリンクを設定します。

　これを各デバイスで確認してみると、残念ながらkobo以外では、リンクの文字装飾無しの指定は無視されて、ソニーReaderでは網かけ、Kinoppy・bREADERでは色文字になってしまいます。タップすると、文中リンクの効かないbREADER以外は注の該当ページにちゃんとジャンプしてひと安心。koboの場合、いちいち「リンクを開きますか」というボックスが現れて鬱陶しいですが、タップでページ送りができるkoboとKinoppyでは、ページをめくるつもりが注のリンクをタップしていたということもあり、まあそれを事前にチェックできるという効用はあるかもしれません。ソニーReaderはスワイプでしかページめくりができませんので、間違ってリンクを踏むことはありません。注から元のページへ戻るのは、各デバイスで用意された戻るボタンで。このボタン、すぐに消えてしまい画面をタップしないと現れなかったり、隅に小さかったりで、使い勝手に改良の余地がありそうです。なお、koboでは例によって読書位置が記録されないため、戻るのは読んでいた項目の先頭へということになってしまいます。

　さて、こうして電子書籍の注を試してみると、意外に使いやすいということが分かってきました。紙の本の注はどうにも面倒くさく、すっ飛ばして後でまとめて目を通す、あるいは読まないということも多いのですが、２タップでジャンプして戻れるというのはこれ以上ない手軽さです。（いや、ジャンプよりもその場で注がポップアップするようになればさらに便利でしょうが、そしてiOSのiBooksではバージョンによってJavaScriptを利用した吹き出し状のポップアップが可能なようですが、規格ではJavaScriptをサポートしたとはいえEPUB3端末でそれが可能になったという話は聞きません）特に注釈が必須の古典の場合は、紙の本に対する電子書籍の大きなアドバンスポイントの一つということができそうです。