■ 序
物書きの諸氏、諸嬢は、自分の作品を電子書籍で販売したいと考えたことはないだろうか。
それも、既成の販売ルートであるネットモールなどではなく、もっと自分の利益率が高い有利な設定で、いや、いっそのこと、自分のサイトで自作を販売したい、と一度も考えたことはないだろうか。
筆者には、ある。あるだけではなく、何度となく、それに挑戦しては挫折してきた。
だが、どのように困難な長い道であれ、曲がり角はあるものだ。
そうして、いくつかの難問をクリアしてゆけば、いつかはゴールにたどり着けるはずである。
以下は、だから、そうした筆者の試行錯誤の記録でもあり、これから、電子書籍をやってみようと思っている物書きの人たちへの、道しるべでもある。
そうした同じ考えの人たちに、わずかでも資するところがあれば、望外の悦びである。
■ 産地直送テキスト作家のススメ
さて――、
作家が、自分の作品の原稿（ふつうは文字テキスト、業種によっては画像その他を含む）を、電子書籍として販売する場合、ネックとなるのは、その電子媒体の「フォーマット」と「課金方法」である。
課金に関しては、現在、一番、作家サイドに有利かつ将来性があるのは、Amazon の「Kindle（キンドル）」であろう。
電子媒体によるテキスト提供での条件で、だいたい７割の印税率（印税というのは、この場合、表現として不適切だが、他に丁度よい用語がないので、敷衍的にそう仮称しておく）だという。
これは実状を知っている人間には、おどろくべき数字である。
一般的に、現在の日本で、作家が自作品の電子書籍販売を大手の出版社の担当部局に依頼すると、その印税率は書籍と同等の1割か、1.5割超くらいが普通なのである。
あいだに（流通などの）中間マージンを必要としない電子書籍販売で、この率は不当だと思われるのに対し、Amazon は（その販路拡張政策の一環としても）、リーズナブルというより、破格な好条件を提示していると思われる。
Amazon は電子書籍＝コンテンツ販売は赤字覚悟で、ハードのKindleやその他の副次的講読費などで利潤を上げる方針のようで、7対3 の印税率も、そこから来ていると思しいが、作家側にとっては非常に有りがたい。
惜しむらくは、肝心のハードウェアの「Kindle」が2010年4月の現時点で、いまだに日本語に対応していない点であるが、これは、将来的には、いずれ解決される問題だと思われる（一部では、Kindleをハッキングして、無理矢理、日本語化しているヘビーユーザもいる由であるが、一般性があるとは、とても云いがたい）。
このHTML文書執筆時点で、Kindleが対応しているフォントは、英語とギリシャ語だけであり、それにフォーマットとしてPDF文書などである。それ以外は読めないのだ。
しかしながら、それ以前の問題として、現在、ほとんどの作家は、ごく一部の手書きの人をのぞいては、なんらかの形で、デジタルライティングで原稿を書いていると思われるが、実際には、その種類があまりにも多様すぎて、「統一したフォーマット」にするのが困難なことにある。
PCのシェアで9割をしめるＯＳである、Windows マシンでは、標準のワープロソフトとしては、「MS Word」があり、また、ＭＳ−ＤＯＳ時代からWindows 時代にかけての名機「一太郎」のユーザも多いだろう。また、筆者はMacユーザではないので、Mac上で標準のワープロソフトが何なのか、よく知らないが、一応、「Word」や「一太郎」はMac版も販売されているので、それを使っているMacユーザもいるかも知れない。
だが、一般に、PCのヘビーユーザは、もはやワープロソフトなどといった、かったるい書記ツールを使わずに、テキストエディタ（シェアウェアの「秀丸」、「QX Editor」その他や、市販では「WZ エディタ」など）でライティングしている人も、かなりの数、いると思われる。
以上は、Windowsのエディタだが、むろん、Mac版のそれも、「iText Express」や「Jedit」「YooEdit」など、いろいろあるでしょうが、どれが物書き用として優れているかは、Windowsユーザの筆者には、判らない。
あるいは、今や稀少な例かも知れないけれど、すでに製造も販売も中止となっているワープロ専用機種（文豪、OASYS、Rupoなど）を、いまだに使い続けている人も、全くいないではないと想像される。
要するに、出版社の編集部には、そうした多種多様なフォーマットの原稿が集まってきているのが現状であろう。
これを「入り口」とすれば、「入り口」の時点で、すでに多彩かつ多様なツールと、それに依存したフォーマットが乱立していることになる。各出版社での対応の苦慮ぶりが、伺えることではある。
だが、それだけではない。「入り口」があれば、当然、「出口」もある。
すなわち、出版社は、それぞれの印刷所と契約しており、そこでの「入稿フォーマット」がある。しかし、これとて、最終の「出口」ではないのだ。
物書きに限らず、出版社においても、すべて印刷所にお任せにしている場合もあるだろうが、経費節減のため、編集部内で、ある程度、印刷所のフォーマットに近い電子媒体に加工・整形して、渡す、ということも最近では多いと思われる（知り合いの編集さんに聞いた話では、編集部で、全ての書籍に対して、そうした工夫をすれば、1点の書籍を作るに際し、平均して、約20万円ほど節約できるとの試算がでた由である）。
これを逆に把えれば、作家ごとに異なるフォーマットである限り、「Kindle」であれ、一般の電子書籍であれ、そこに手渡す電子媒体は、なんらかの工夫なしには、有利な条件での取り引き対象外となる可能性が高い。
Kindle の仕様はよく判らないが、「iPad」などを始めとする大半の電子書籍端末では、「EPUB」というXML互換のフォーマットを採用している。
だから、作家サイドとしては、「EPUB」とも互換性のあるフォーマットで、あらかじめ電子テキストを作成しておけば、ＯＫだと思われる。
できるだけ、汎用性の高いフォーマットで渡せば、それだけ作家側に有利な条件での契約を結ぶことが可能だろうが、そうでない場合は、あえて不利な条件をのまざるをえないことが考えられる。
事前に不利と判っていることを、わざわざやる必要はあるまい。
しかしながら、作家サイドで、そうした面倒な工夫をするのは、PCのスキルや印刷関係の知識の点から見ても、大変であることは、云うをまたない。実際、印刷所で日常的にやっている作業は、「職人的」なものであり、ふつうは、一般の出版社の編集でさえ、その詳しい内容は把握していないことが多い（現実的には、本の原価計算などに反映するので、編集でも基本的な知識はあったほうがいいと思うのだが、デジタルデバイドその他の壁は、思っている以上に高く、そして厚いのである）。
さらに、物書きは、原稿を書くことが仕事なのだから、そうした畑違いのことにまで神経を使うのは、本来の仕事ではない、というのも一理あるだろう。
だが、しかし、現況は厳しい出版不況下で、そうも云っていられないし、工夫の仕方によれば、それほど個々の作家さんが、印刷所の詳細なDTP（デスクトップパブリッシング）の方法にまで熟達している必要もないのである。
筆者が、あれこれ試行錯誤してきた、その結論だけ云えば――、
Adobe 社のDTPソフト「InDesign」を使って、統一フォーマットを作る。
これだけである。
なぜ、「InDesign（インデザイン）」を使うのか、というと、現在、日本では、ほとんどの印刷所がMac版の「QuarkXPress（クォークエクスプレス）」というDTPソフトを使っており、「InDesign」は、それと互換性があるのだ。
そして、ここが肝心なのだが、「InDesign」では、「タグ付きテキスト」というインポート方法があり、プレーンなテキストファイルで作成したタグ付きのテキストを、「鋳型」である書籍フォーマットに「流し込む」ことが出来る。
「タグ付きテキスト」は、メモ帳で開けるテキストファイルなので、誰にでも作成可能だし、要件を満たせば、そのまま、「InDesign」にインポート可能なのである。
つまり、「InDesign」に対応する「タグ付きテキスト」を作れば、よい、ということになる。
ワープロソフトに慣れたPCユーザは、テキストファイルや、テキストエディタなどが苦手かも知れないが、心配は要らない。
さすがにワープロ専用機種では、メディアコンバートの必要があったりする（たとえば、ちょっと、もういないとは思うが、未だに5インチのフロッピーディスクで原稿が保存されていたりすると、そのままでは使えない＝3.5インチのFDに変換しないとＰＣでの作業が出来ない）し、そこで作成されたルビなどが、PC上で再現できるかどうか不明なので、ひと手間かかるが、ふつうのワープロソフトないしエディタで書いている人は、ほとんど、自分では何もする必要がない。
筆者が構想し、友人各位（その中には、印刷関係にも詳しい編集さんなどもいるし、また、Adobe InDesign の達人もいる）に協力を仰いでいる、このプロジェクトでは、作家サイドの労力をできるかぎり減らして、あとは、PC上で自動的に作業が完結するような方法である。
くわしく云うと、まず、ワープロソフトの「Word」と「一太郎」で書いている人は、問題ない。
それぞれマクロ言語があるので、マクロを使って、テキスト化する。
（マクロというのは、決まり切ったルーティンワークを、マシンに自動的・機械的にやらせるスクリプト言語である。実際に最初から書こうとすると難しいが、秀丸のように著名なエディタになると、すでにマクロ師と称される人たちが作成したものがあるので、それを少しだけ書き換えることで、応用が利くのである）
また、最初からテキストエディタで書いている人も、ほぼ問題はない。
自分なりのタグで、ルビや圏点、ゴシック体指定などをしていると思われるので、その方式を明かして貰えば、簡単に「InDesign」に対応した「タグ付きテキスト」に変換できる。
こうして、汎用性の高い「統一フォーマット」を用意し、例えば、キンドルが提示する条件としての電子媒体にそれが適合していれば、あなたも、明日から、「産地直送テキスト作家」になれるわけである。
むろん、そこに至るまでには、いくつもの関門はあるだろう。だが、それらは、解決可能な問題だ。
中間マージンを、ほとんど取られないで、書いた分の７割が自分の稼ぎになる生活は、物書きにとっては、夢物語だったかも知れないが、そうした未来が、すぐそこまで来ているかも知れないのである。
どうだろうか。少しは、気持ちがそそられないだろうか。
では、以下に、どのようにして、作家の電子ファイルを、テキスト化するのか、そして、そのためには、何を知っておかねばならないのか、を少し詳しく述べてゆくことにする。
■ 日本語の表記の特殊性
ここで、英語と日本語の差について言及しておく。
たとえば、現行の「Kindle」英語版で、表示される英語（アルファベット）と日本語では、いったい何が違うのか。
横書きと縦書きの差。むろん、それもある。
だが、最大の差は、アルファベットは1バイト（8bit）ですむが、日本語（漢字、ひらがな、カタカナ、その他の全角記号）は、2バイト（16bit)必要だ、ということである（日本語でも、半角カタカナ文字は1バイト）。
換言すれば、１文字分の情報量が倍、違うのだ。
これは、大きい。そして決定的な差である。
別な云い方をすると、英語を表すには、基本的にキーボードに表示されている26文字のアルファベット文字＋記号だけでよい。
だが、日本語を表すには、それを変換して、厖大な数の2バイト文字＝全角文字が必要なのだ。
また、日本語には、独自の文化として「ルビ」や「圏点（傍点など）」がある。
さらに云えば、英語は（英語圏内の表現ならば）アルファベットだけですむが、日本語は、上記の文字すべてを混在することが出来るし、そうした表現が一般的に行われていることが、ごく普通にある。
これは日本の印刷技術が高度である原因ともなっているが、ディスプレイ上の表示上でも、同じ工夫が必要なので、いわゆるＤＯＳ／Ｖ機（正確には、PC/AT互換機）上で、しかるべきフォントを使って、日本語を表示するのも、同様の工夫が（裏で）なされている。
それは目に見えない工夫だから、日常、ＰＣを使っているわれわれには、関係ない話だが、電子書籍化する、というようなことになると、印刷所と同じ創意工夫が必要となってくる。
一番、わかりやすい例は、「ルビ」だろう。
およそ平明な文章を心がけて書いている作家さんでも、ルビが1個もない文章で小説を書いている、という人は稀だと思われる。とくに簡単平易を心がけるべき、ライトノベルでも、読者層が低年齢の場合を想定して、むしろルビは多用されているはずである。
だから、結果的に、現在、よっぽど偏屈な書き手でないかぎり、ルビが全くない作品は、非常に特殊で稀有な存在だと思われる。
しかし、世界中の言語（書き言葉）を見わたしても、ルビというのは非常に珍しい表記法なのだ。
筆者が聞いた範囲では、古代マヤの文字に、日本語での「漢字」と「ふりがな」の関係に似た表意文字と表音文字の混在した用法がある、という話くらいだ。
ラテン語がなまった「ロマンス語（フランス、イタリア、スペイン語等）」圏では、アルファベットだけでは収まらず、アクセント記号や特殊な文字もある。
だが、現存する言語で、「ルビ」文化は日本だけである。
むろん、これによって、多様で多彩な日本語の駆使が、作家には可能になっている。
たとえば、漢字に外来語のルビを振って、たとえば「拡張現実」と書いて「オーグ」と読ませ、「拡張現実」の英語表記「Augmented Reality」の略語としての「Aug（オーグ）」を表しうる。場合によっては、「拡現」という略語に「オーグ」とルビを振ることで、サイバーパンク風な世界を描写できるのだ（これは、亡き伊藤計劃氏の作品例）。
あるいは、特殊な、または難解な漢字の訓みとして、人名があるが、たとえば「本海宥現」と書いて、（もとみひろみ）と読ませるには、やはりルビが必須だろう（これは、神林長平氏の例）。
ルビを丸カッコに入れて表現する方法もあるが、きちんとした文芸書では、ルビが一番、しっくりくる。
われわれは、物心ついた時から、その伝統文化に慣れ親しんでいるのだ。
日本語の表現を豊かにしてくれる、このルビの発明には、古代日本の、中国から漢字文化を輸入して、それを「やまとことば」で表記しようとした先達の工夫に、いくら感謝しても足りない。
だが、それは、テキストファイルで表そうとした時に、思わぬ桎梏となって、われわれを苦労させもするのだ。
テキストエディタで作品を書いている多くの作家さんは、たぶん、自分なりの独自タグを開発して、それを使って、ルビやゴシック文字の指定をしていると思われる。
たとえば、「ルビ」ならば、ルビの親文字を＜ ＞で囲み、ルビを｛ ｝で囲んでいれる、とか。ゴシック文字は、● ●で囲むとか、要は、その作品テキスト内で使われない一意的な記号で明示すれば、それでよい。
あとは、編集（と印刷所）との間で、「約束事」として、その独自タグを決めておけば、あとは、編集が（その出版社独自かつ共通の）適切なタグに直すなり、印刷所へ指示をするなりして、出来上がりは、真っ当なルビを付した日本語の文章になっている、という次第である。
だが、それは、あくまでも「ローカルルール」だ、ということが問題である。
当たり前のことながら、ローカルルールは、けっしてグローバルなルールたりえない。
だが、方法さえ掴めば、つまり工夫しだいでは、グローバルルールにローカルルールを適合させることは、可能である。
■ 青空文庫のルビ
実際に、類似の方法で「ルビ」の表示に成功している例として「青空文庫」がある。
本当は、ルビには、「モノルビ」と「集合ルビ」とがあり、「青空文庫」では、それを同一にあつかっているのだが、判りやすいので、初歩的な事例としては、これで、よいだろう。
（ちなみに、モノルビとは、「紅」という１文字に「あか」とルビ文字を振るようなものであり、集合ルビとは、「拡現」という２文字（以上）の親文字に「オーグ」といったルビを振るものだ）
というか、筆者が、試行錯誤している間に、「中間ファイル」として、青空文庫方式に、一度、変換してから、InDesignのタグ付きテキストに再変換した、という経緯があるので、それで言及する次第である。
青空文庫のルビは、きわめて簡単だ。
ここでは、青空文庫サイトから落としてきた、太宰治の「走れメロス」を事例にあげる。
かの有名な冒頭の１行は、次のようになっている。
メロスは激怒した。必ず、かの邪智暴虐《じゃちぼうぎゃく》の王を除かなければならぬと決意した。
親文字の「邪智暴虐」のルビとして、《じゃちぼうぎゃく》が指定されている。
本来ならば、ここは1文字の親文字に対して、ルビが振られるモノルビなので――、
メロスは激怒した。必ず、かの邪《じゃ》智《ち》暴《ぼう》虐《ぎゃく》の王を除かなければならぬと決意した。
――となるところだが、まあ、野暮は云うまい。
（さらに云えば、ルビ文字は、本当は、撥音や拗音がなく、正確には邪《じや》……虐《ぎやく》となるのであるが、ここでは、措く）
青空文庫では、モノルビと集合ルビの区別がない代わりに、漢字が連続した文脈中の、どこからがルビの親文字であるかを示す「区切り記号」として「｜」がある。凡例の次のような場合だ。
（例）疲労｜困憊《こんぱい》
これで、「彼は疲労困憊した」とある文章で、「こんぱい」の親文字が「困憊」であることが判る（というか、ビューアでの指定がなされる）。
青空文庫のルビ指定は、これだけである。実に簡単だが、それで充分なのだ。
青空文庫が、ビューアでどう見えるかは、拙サイトのWZ Editor の操作説明ページで紹介している。
筆者は、エディタはWZ 派なので、そのマクロを使って、ビューアとしているが、画面上は、次のようになる。
（青空文庫のファイルをルビも含め縦書きで表示可能にするビューアとしては、フリーソフトの「ArisuViewer」などがあり、Vectorや窓の杜サイトでダウンロード可能である）
最終的に、InDesignでのタグ付きテキストに変換した場合、テキストは、次のようなものだ。
<pstyle:> メロスは激怒した。必ず、かの<cr:1><crstr:じゃちぼうぎゃく><cmojir:0>邪智暴虐<cr:><crstr:><cmojir:>の王を除かなければならぬと決意した。
単純明快な青空文庫のルビタグを、このような（順番も逆転した）複雑なタグに変換するのは、面倒だと思われるかも知れないが、まさに、そのためにこそ、マクロというものがあるのだ。
残念ながら、筆者の力量では、WZ Editor で、このマクロを書く（というか移植する）ことが出来なかったので、ここだけは、秀丸エディタを使っている。WZ のマクロは、ほとんど C言語であり、プログラミングの心得のない筆者には、イチから書くのは、荷が重いのだ。
秀丸は、縦書き表示にデフォルトで対応していない。筆者も普段は使わないのだが、正規ユーザではある。
おそらく、シェアウェアでは、日本で最もユーザ数が多いエディタである。
むろん、そのマクロも多く、公開されている。
青空文庫のルビタグをInDesignのタグ付きテキストにする、秀丸でのマクロは、次のようなものだ。
（なお、一部のＯＳやブラウザの環境によっては、バックスラッシュが「円」マークではなく、「／」の逆向き記号になるが、適宜、読み替えてもらいたい）
replaceallfast "[亜-腕弌-熙々]+?\\f《\\f.+?\\f》",
"<cr:1><crstr:\\2><cmojir:0>\\0<cr:><crstr:><cmojir:>", regular ;
秀丸のマクロ本は、市販マニュアルが多数でているので、それを応用させてもらった。
なにやら意味不明の文字列が並んで見えるかも知れないが、これは、「正規表現」というものを使って、文字列の逆転を実現させている。ここでは、理解できなくても、よい。筆者も、本当のところは、よく理解していない(笑)。
ただ、マクロは流用できるので、使わせてもらっている。
とにかく、このようなマクロを使えば、誰でも簡単に変換できるのだ。
それが最も重要であり、変換作業自体は簡単なのである。そのことを理解してもらいたい。
なお、WZ Editor でのマクロは、コンパイルする必要があるが、秀丸では、テキストファイルで書かれたマクロを、秀丸の実行ファイルがある同じフォルダに置くだけで、動作する。
ものは試し。実際にやってみよう。
まず秀丸を起動させ、青空文庫サイトからダウンロードしてきた「走れメロス」を例に、そのテキストを開いておく。
（青空文庫の、冒頭の凡例などは、作業の都合上、削除している）
あらかじめ、秀丸のフォルダには、上述した「InDesignのタグ付きテキスト」に変換するマクロを格納してある。
（もう一つ、別に、HTML文書にする際、IE にしか適用できないが、ルビを表示させるマクロも格納している）
下図のように、メニューバーの「マクロ」からドロップダウンメニューの「ルビInDesign変換マクロ」を指定して、動作させる。
実に、驚くほどの速度で、変換は終了する。
筆者は、自作の1000枚を越える「伯林星列」でも、これを試したが、数秒とかからなかった。
結果は、次のようになる。
青空文庫のルビが、InDesignのタグ付きテキストに変換されているのが判るだろう。
マクロを使えば、このように、誰にでも、簡単に、テキストの変換が可能なのである。
ついでながら、上述した、青空文庫のルビタグをHTMLのタグに変換するマクロも紹介しておく。ただし、これはInternet Explorer が独自開発したタグなので、FireFoxなどでは使えない（丸括弧に囲まれた表示になる）。
以下のようなものである。
replaceallfast "[亜-腕弌-熙々]+?\\f《\\f.+?\\f》",
"<ruby><rb>\\0</rb><rt>\\2</rt></ruby>", regular ;
このマクロを使えば、青空文庫方式で記述したルビタグが、（IEだけだが）ウェブ上でルビとして表示される。
興味があって、ご自分でHTMLを書いている人は、お試しあれ。
■ InDesign でのテキストの流し込み
こうして作成した「タグ付きテキスト」を、次に、（多少、加工・整形した後）、いよいよ、InDesignに読み込ませる。
実際の作業は、まず、InDesignで、雛形となる「ブック」を作成し、そこに流し込む。
「ブック」は、実在の書籍を参考に、上下二段組で、見開きで、奇数頁開始にした。
筆者の構想では、雛形は、3種類ほど、作っておき、それは参照例にすればいいと思う。
３種類とは、「文庫」「新書」「単行本」である。イラストなどが入ることもあるだろうが、ここでは考えていない。
実際には、そうした具体的な作業は、印刷所がやってくれるので、作家個人が、そこまでする必要はないからである。
ただ、どのような工程か、判ってもらうために、InDesign での雛形を作成した。
では――、
途中のプロセスは省いて、今度は、このタグ付きテキストを、あらかじめ作成したInDesignの雛形に「流し込む」作業を行う。
少し細かいので見づらいが、きちんと、上下二段組で、見開き2頁の書籍のフォーマットに、「走れメロス」のテキストが流し込まれているのが判るだろう。
ここでは、表示がデフォルトなので、メニューバーの「表示」から「オーバープリントプレビュー」に切り替えてやる。
すると、次のような（印刷された時の）表示画面に換わる。
ルビが、適切な位置に振られているのが判るだろう。
この原本であるタグ付きテキストは、→「このようなもの」である。
Webの表示の便宜上、改行しているが、本来は、ずっと文字列が連なっている。
なお、Mac のソフトである「QuarkXPress」では、Windows で標準のフォントである、True Type Font が使用できない。
たいていは、ヒラギノやモリサワの Open Type Font が使われる。
上記のテキストの冒頭部分にあるのは、そのフォント指定などである。
「走れメロス」の標題箇所だけ、ゴシック体にするため、「小塚ゴシック」というフォント指定をしているのに留意されたい。
次は、少しフォーマットを換えた、1段組の例である。
筆者が地元の古書店の業界誌に依頼されて書いた拙文の冒頭だが、1行目の部分に「圏点（傍点）」を付してあるのが判るだろう。
このように、InDesign では、「タグ付きテキスト」を流し込む「ブック」と呼ばれる「雛形」は、ユーザが自由に設計できる。
段組やフォントの指定も自由であり、同人誌作家の方などは、好みのフォントなり版組なりを設計可能なのである。一般的に、１ページあたりの行数と字数を指定し、フォントやそのサイズを指定すれば、本としての体裁は整う。
大事なことは、雛形である「ブック」などではなく、流し込む「タグ付きテキスト」そのものなのだ。
いや、最終的に「タグ付きテキスト」になるならば、その手前の段階でもよいのである。
だから、最終的にPDFファイルにするにせよ、あるいは、この「タグ付きテキスト」から、（Amazon などが指定した場合）、さらに別なタグのフォーマットに変換するにせよ、作家サイドとしては、なんらかの原則に従って、ルビなり圏点なりを一意的（ワンアンドオンリー）で判別可能な体裁で用意しておけば、それでよい、ということになる。
なにも、InDesign のタグ付きテキストにする必要もない。
個人的には、汎用性の高い青空文庫フォーマットで充分だと考えている。
むろん、青空文庫のフォーマットの指定は、ルビに関してのみで、圏点やフォント指定などは出来ないが、普通の作品なら、ルビにだけ拘れば、それでＯＫだと思われるので、それ以外の作品で、どうしても圏点やフォント指定が必要ならば、「青空文庫フォーマット拡張版」といった追加タグを付したものを準備すれば、よいだろう。
先述したように、すでに有志が、Wordや一太郎でのマクロを作成し、そこから、ルビ、圏点などを抽出し、タグを付す試みを行っている。
だから、作家側としては、それを利用して、独自のテキストを作るか、または、Wordや一太郎ファイルをそのまま用意するだけでもよい。
秀丸でタグを変換したり、InDesignで作成した雛形に流し込むといった作業は、代行する人間がいても、それほど負担にはならないと思われるし、その作業報酬の対価として、それなりの料金を支払い、作家側に、原本と、その副次的生産物としてのタグ付きテキストが渡されれば、どちらも文句はないだろう。
筆者の提案は、だいたい、以上のようなことを踏まえて、次のようなものだ。
作家は、そのテキストを産直で販売することを念頭において、自分の「取り分（＝印税率）」を有利にするために、統一したフォーマットの仕様に同意する。
その上で、自作品が、現在、どのような形態であろうと、それを、InDesign が読み込み可能な「タグ付きテキスト」にするか、もしくは、それを全体としたフォーマットのファイルを用意する。ワープロソフトのファイルであれ、エディタで書かれた自分独自のタグ付きテキストであっても、それは構わない。
そこまで整えば、後は、その道のエキスパートが用意したマクロなどを使って、「タグ付きテキスト」なり、InDesign に流し込んでPDFファイルにするなりが可能となる。
最終的に、どのような形態で、自分の作品を販売するかは、作家の自由である。
Amazon のキンドルが市場を制覇するなら、それに合わしてもよい。または、iPad などが、「EPUB」を求めれば、それに変換するのも、わりあい簡単だと思われる。
要は、その手前のテキストを確保することだ。
そうすれば、市場に対して、作家は優位な立場に立てるのである。
中間マージンのない電子書籍で、１割という間尺に合わない印税率に甘んじることも、もうなくなる。
――と、そう思っていたのだが、筆者は、ここで驚くべき意見に出会った。
上に記した、ほとんど全てのことが、チャラになるような、それは驚天動地の事実だった。
筆者の基本的な考え方は、別に間違ってはいない。
だが、出版の現実を知る、筆者の知人の編集に、この件について相談したところ、筆者の考えが、きわめて甘く、現実的ではないことを知らされたのである。
その詳細は、ページを改めて、記したい。
以下、次号(笑)。