| Prep for SendDirectText Writer's Guild [2] |
さて、前章までで、筆者が目指しているのが、作者と読者の間に、出来るだけ「仲介者」を入れずに、「産地直送」で作品を届ける、という目的であること、そしてその趣旨については、ご理解をいただけたと思う。
そこで、こうした場合に、いつも良き助言者となってくれる、旧知の編集さんに、ある程度、まとまった成果に達した時点で、相談をもちかけた。
この方は、いわゆるサンデープログラマで、一太郎やWordのマクロなら自分で書ける。
筆者に、最初に、デジタルライティングのノウハウや問題点を教えてくれた人でもあり、いわば、商売抜きで付き合っている。一太郎ファイルからルビを取得するマクロを筆者にくれたのも、この人である。こうした問題に関しては、最もエッジな知識とスキルを有した人材でもある。
だから、というわけでもないが、筆者は、自分の「夢」を相談するに際して、その人にならば、賛同を得るだろう、との甘い目論みがあったのだ。
ところが、それが木っ端微塵に打ち砕かれた。
「甘い、現実の認識があまりにも甘い」、というのである。
そして、約2時間半にわたって語られた、その内容は、筆者をしても、「なるほど、そうなのか」と首肯せざるを得ないものであった。
筆者の「考え方」は間違っていない。
実際、その人が在籍していた版元では、筆者と同じ設計思想による、InDesignによるDTPを、その人が主体となった事業開発室において成し遂げているのである。
では、筆者の何が間違っていたのか。
それについて、以下に詳述しよう。
その前に、電子出版への道を、筆者に拓いてくれた書について、触れておきたい。
まず、未来社の西谷能英氏の著作がそれである（いずれも未来社刊）。
2001年に刊行された「出版のためのテキスト実践技法：執筆編」。
2002年に刊行された「出版のためのテキスト実践技法：編集編」。
2009年に刊行された「出版のためのテキスト実践技法：総集編」。
これらがなかったら、筆者の「夢」は「夢」のままに終わっていたことだろう。
それまでにも、筆者は、テキストファイル至上主義者として自己を確立する間に、さまざまなテキストファイルに関する本を読んできた。SED やGREP に関する本、正規表現のマニュアル本、また、PCでデジタルライティングするに際して、エディタのマニュアルやマクロに関する本などなど、あまたの参考書を渉猟してきた。
だが、しかし、自分の作品が、編集者にわたった後、いかに「純粋なテキストファイルとして」、それが「処理」され、そして「印刷」に回されるか、ということを、ここまで明確に、かつ詳細に記した本を、筆者は、他に知らない。
それは、まさに、テキスト至上主義である筆者にとって、自分の考えをより先鋭化させる、いわば、その思想を裏打ちしてくれる天啓の書であった。
西谷氏は、プロの編集者である。
そのプロが、編集段階では、テキストが最重要なのだ、と説いているのだ。だったら、最初から作家側も、テキストで表現してよいだろう。ルビや圏点などについては、西谷氏は、未来社独自のタグを考案しているから、そこまで模倣するわけにはいかないが、基本的な考え方は、これでいいのだ、という重要な示唆を与えてくれたのである。
また、西谷氏が、そのヒントとした「sed による編集＆DTP「実践」自動処理テクニック」高橋陽著（1998年、技術評論社刊）がある。
こちらは少しプロユースというか、専門的だが、非常に示唆に富んでいる。
電子書籍に関心がある人、ならびに作家にとって、テキストファイルとは何か、を知りたい人には必見の書ばかりである。
今ならAmazon でまだ発売中だ。上記のタイトルからリンクを張っている。
特に最初の（作家向けの）「出版のためのテキスト実践技法：執筆編」は、未見なら、ぜひ、一読をお奨めする。
しかしながら、西谷氏の書は、あくまでも紙媒体の出版を前提とした、編集の立場で、印刷所への入稿までの間に、編集者は何をなすべきか、といった技術的なノウハウであり、著者自身が、その作品を電子書籍としてネット上で出版する、といった目的からは外れる。
西谷氏は、非常な現実主義者であり、徹底して実際派だ。
おそらく、そうした「夢」が「夢」、否、「幻想」にすぎないことを熟知していたのだろう。
しかしながら、ともあれ、筆者は、こうしたテキストファイルの扱い方のプロに倣って、最終的に、InDesignの「タグ付きテキスト」にすれば、作者は、「産地直送」が可能ではないか、と思うにいたったのである。
その他にも、先述のように、あまたの先達の知恵や書にはお世話になったが、ここまで実際的に、出版における「テキスト処理」を語った本は、それまでなかった。
それゆえ、特に敬意を表し、ここに記して感謝する次第である。
さて――、
そういうわけで、筆者は、旧知の編集に相談の架電をした。
くり返すようだが、正直なところ、相手が、筆者の構想に、少なからず賛同してくれるのではないか、と期待をしていたのである。
ところが、それが大間違いであった。
そこで語られた内容は、筆者の「夢」を、文字通り木っ端微塵に粉砕したのである。
問題点は、先述した「入り口」と「出口」の問題がそれである。
（もともと、この用語自体、彼から聞いた話に出てきたものだ）。
まず最初は「入り口」の問題である。
すなわち、作家が、どのように多様性に富んだ電子ファイルを持ってくるか。
一言で云うならば、それは、あまりに多様性に富みすぎて、とても「汎用化」など出来ない、というのである。
実際に、その編集が、携わってきた事例を、一つひとつ挙げるのは、煩瑣に過ぎるが、その一部だけでも、筆者の「夢」が「幻想」にすぎないことを証しするものであった。
たとえば――、
印刷用語で「ダーシ」というものがある。
おそらく、英語の「dash」が訛ったものだろうが、簡単に云えば「――」である。
小説では主に、会話の行末に使って「余韻」を出したり、地の文中では、説明的文章を囲む目的などで使用されることが多い。
これが、作家によって千差万別だというのだ。
実を云うと、これは、筆者も間違えていた時期があった。
詳述すると、経緯が面倒なので、今は省くが、1999年頃、筆者は、仲間数人と語らって、電子書籍の「産直」を試作していたことがあるのだ。
そこで、思いもかけない自分のミスや間違いに気づいたのだが、その一つが、この「ダーシ」記号であった。
筆者は、当初、それを、109キーボードのテンキーの上部にある「－（＝マイナス記号）」で代用していたのである。これだと、横書きでは、問題ないように見えるが、縦書き表示にした時に、記号が横に寝たままになってしまうのである。
「ダーシ」は、JIS記号では、213D で表される記号を２つ重ねるのが「正しい」。
それ以外は、印刷段階で、エラーとなる。「――」と２つ重ねることで、印刷すると2本の棒線が一本に表示されるよう、設計されているのである。
他には、縦書きで書いていて、区切り記号の「｜」を、これに宛てている作家さんもいるとのことだった。
西谷氏の本にも言及されているが、「ダーシ」や「ー（＝音引き記号：JIS で213C）」、それに「－（＝マイナス記号：JIS で215D）」は、よく間違われるという。
事実、ネット上のある場所で、この話をしたら、すでにデビューして20年以上のキャリアを持つ友人の作家さんが、「自分も今まで間違えていた。早速、単語登録して、正しい記号にする」と云っていたほどである。
ことほどさように、この記号は（キーボード上に似た記号がある、という点でも）間違えやすいものらしい。
しかも、この作家さんの例で判るように、編集は、作家の間違いに気づいているはずなのに、それを本人には伝えてこなかったのだ。その方が、実は、恐るべきことではないか？
また、これも筆者が間違えていた例であるが、「ヤマ括弧」がある。
横書き表示編集の文章では、特に注意したいのだが、正しくは「〈 〉」を使う。JIS で2152，2153 に相当する。
筆者は、それを、キーボード上にある「＜ ＞」で代用していたのだ。これは、数学の不等号記号の「大きい・小さい（JIS で2163, 2164）」を意味し、全然、別の記号であり、しかも、横書きでは判らないが、縦書き表示にすると、これも記号が横に寝てしまうのだ。
（当時、筆者は、こうした間違いを、正に、縦書き表示にした時、それが横に寝てしまうことで気づき、その電子書籍試作プロジェクトで、指導役を務めた一人である、ジャストシステム勤務の女性編集から「正しい記号」を教えられた）
さらには、「……」がある。
これは、正確には「3点リーダ(…)」と云って、これまた小説では2つ重ねて、ひと連なりの破線にし、会話での行末の余韻や沈黙の表現に使ったりされることが多い。
ところが、これを、人によっては、「・（＝中黒）」や「‥（＝2点リーダ）」を３つほど重ねて使ったりするという。
もう一つ、筆者自身がやっていた、困った事例として、圏点の１つである「傍点」を、ワープロソフトの傍点機能を使わずに、ルビとして、それを入れる、といったことがあった。
これは、別な編集さんと話していて、談、ルビや圏点におよび、そこで判明したのだが、筆者は、先にもらった一太郎マクロが「ルビ」しか取得しないため、やむをえず、「傍点をルビで代用」し、ルビ文字として、キーボード上から打鍵可能な「`（アクサングレーブ＝アクセント記号）」を代わりに打っていたのである。
これだと、画面上の見た目ないしプリンタ出力では、傍点を打っているように見えるが、実際には全く異なる記号であるし、意味をなさない（活字上、アクセント記号を必要としない日本語の文字に、アクセント記号を打っても、それは、まあ、「意味」をなさないわけである）。
その時は、その編集さんは、「そうだったんですか。いや、他にも、同じようなことをしてる作家さんがいるので、なんで、そんなことをするのか、ずっと謎だったんです」と云っていた。（そうか、オレだけじゃなかったのか）、と筆者は半ば安堵したものだが、本当は、そこで安心してはいけない。テキストファイルの約束上、見過ごすわけにはいかないミスだからである。
また、これは、統一してこう記述する、といった約束事（ルール）がまだ、出来てないから、しようがないとは思うのだが、本来、日本語にはなかった用法として、「感嘆符や疑問符を重ねる」、という記号がある。そもそも、感嘆符などは、それ自体が、古来、日本語にはなかったものであり、外来記号だが、今では、感情表現を豊かにするものとして、それを全く使わずに小説を書いている人は、（時代小説など一部の例外を除いては）、稀少であろう。
代表的なものとしては、「!!」や「!?」だろう。変形として逆の「?!」もある。オドロキと疑念の両方をいっしょに表現する、今では、わりとよく使われる記号であるが、これは、単独の文字としては、JISにはない（ユニコードにはある）。そこで、どうしても、組み合わせて工夫する必要があるが、自分のうちで、町内会の案内状でも書くなら別だが、編集にわたす原稿で、「作字」したって、しょうがない。だから、大半の作家は、これを、いろいろな方法で、表現しようとしているだろう。
まず、思いつくのは、半角の「!」と「?」の組み合わせである。これだと、「縦中横（たてちゅうよこ）」というワープロソフトでの標準機能によって、自分で印刷する際にも、そのように表示されるので、使用例は多いと思われるし、また、編集も、その方がよいと判断するだろう。「縦中横」というルールは、もともと、印刷のルールにあるので、そう記述した方がよいのである。
しかしながら、人によっては、いちいち半角モードにするのが面倒だと、全角の「！」と「？」で表す作家もいると思われる。この場合、そのまま印刷すると、縦に感嘆符と疑問符が並ぶことになって具合が悪い。編集は、半角に直して、「縦中横」組みの指定をする必要が出てくる。
ふつう、縦中横は、3桁までの半角英数字や記号に適用される。
それ以上になると１頁の行数に影響するから、あまりヘンな縦中横を仕組まないほうがいいだろうが、そこは作家の「自由」だから、へんてこりんな組み合わせを考案する可能性はある（アスキーアートの「(^^)」が横になっている例をたまに見るが、みっともない）。
ともあれ、こうしたキーボード上にはない特殊な記号や「約物（やくもの）」と呼ばれる印刷用の記号類には、じゅうぶん気をつけたほうがよい。
最近は、携帯電話の発達により、「絵文字」が日常的になってきたため、「ハートマーク」などを使う作家さんも少なくないと思うが、これは、基本的に「機種依存文字」が多いため、留意すべきである。
さすがに、ケータイの絵文字をそのままワープロソフトで使えると思っている作家さんは少ないだろうが、しかし、自分が使っている文字が「機種依存文字」か、否かを、きちんと云える人は意外に、そう多くはないのだ。
「機種依存文字」とは、昔のワープロ専用機種から、最近では、NECのPC9801で使えた「98(きゅうはち）文字」、ＭＳ－ＤＯＳからWindows にいたるまでのPC/AT互換機上でのみ表示可能だった文字、さらには、特定のワープロソフト（一太郎など）だけで通用する文字などを指す。大体、「Macで文字化けする文字だ」、と考えれば判りやすいだろう。
代表的なものでは、「丸付き数字」、「ローマ数字（時計数字）」などがある。
実際には、これらは、現在、「ユニコード」に収録されているので、全文をユニコードで記述すれば問題はなくなる道理だが、あまり、そこまで考えて作品を書いている作家さんも少ないので、ファイル全体の文字コードががJIS規格ならば、それは、当然、Mac環境にいけば、文字化けする。
Macマシンは、世界でも日本でも市場のシェアが5％内外だから、考慮しないでもいいように思われるかも知れないが、こと「出版」の世界では、事情が異なる。
困ったことに、日本では、全国的に印刷所で使っているDTPソフトは、（古い）Mac上で動作するものが多いため、そこでは、機種依存文字は、文字化けが約束されているようなものなのである。
「物書きに、そこまで要求するのは、如何なものか」、といった意見もあるが、それこそ、その物書きには、ユニコードが導入される、されないといった時期に、あれほど固有の異体文字に拘った人がいたはずである（たとえば、ハシゴ高の「髙」など）。だったら、自分が使う文字コードの問題に、少しは拘ることはムリな要求ではないと思われる。
すくなくとも、機種依存文字は、インターネット環境では、文字化けする可能性がある。
つまり、ごく一般に使ってる、Webやメールでも文字化けするのだ。相手の利用環境が（Windows かMacか）不明な以上、それに留意して文章を書くのは、当然のマナー（ネチケット）であろう。なお、Windows 環境でも、世界標準の最新のメーラ「Thunderbird」などは文字コードがデフォルトではUTF-8というユニコード互換のコード体系なので、やはり文字化けする。
メールで気をつけていることを、一般の作品執筆に敷衍するのは、それほど可怪しなこととは思えないのだが……。
筆者は、たまたま、表稼業の勤め先が、某国立大学図書館といったアカデミックな環境のため、教官などにMacユーザが多い。そこでは、Windows のシェア拡大に伴い、こうしたMacで文字化けする機種依存文字への反感も多いのか、初期には、しばしばクレームを受けた。だから、今では、公式な文書(メールを含む）では、可能なかぎり、機種依存文字の使用をやめている。
しかし、このような環境は、筆者だけの特殊なものだろう。一般の作家さんで、Windows 上のワープロソフトなりエディタなりで打鍵している人は、どだい、何が機種依存文字であるか判らずに、無意識に機種依存文字を使っていることが多いはずだ。
上述した西谷氏は、これらの機種依存文字を、SED を使って、たとえば丸付き数字なら「○1」という具合に、あらかじめ変換させてしまう手法を紹介している。これは、あくまでも編集段階でのことであり、作家が使うのは、そうしたもの、というアキラメの境地であろう。
だが、電子書籍を自分の手でやりたい、といった考えであれば、こうした機種依存文字は、日頃から使わないでおいた方がよい。
（メールソフトなどでは、サブジェクトや本文に、機種依存文字が使用されていた場合、その旨、警告のアラートダイアログボックスが出るものがある。その時は、警告に従って、見直すほうがよいだろう。相手がMacユーザの場合、まず確実に文字化けするからである）
さらに、西谷氏も言及しているが、Wordというワープロソフトは、「余計なお世話」に満ちあふれており、例えば、「１）」と打鍵して、次にリターンを打ち改行すると、自動的に「2）」といった表示が出る。だが、コピー＆ペーストしてみると判るが、これは見かけだけの数字であり、実際には「無い」ことがある。
小説では、あまり、こうした例はないだろうが、テクニカルライターの方などは、こうしたワープロ依存の「余計なお世話」は、あらかじめ使用不能にしておいた方がよい。ファイルを編集に渡した段階で、テキスト化すると、頭に付けたはずの数字が全部、消失してしまうからである（驚くなかれ、最初に入力したはずの「1)」でさえ、消失するのだ）。
これらは、Wordの「オートコレクト」機能と呼ばれるもので、むろん、ユーザが自分でオフに出来る。
Word2003では、挿入＞定型句＞オートコレクトタブで、Word2007では、MS Office ボタン＞Wordのオプション＞文章校正＞オートコレクトのオプションで、細かいオン／オフの設定が可能である。
Wordのオートコレクト機能は、本当によく出来ていて（むろん、皮肉である）、画面を見ているだけでは絶対に判らない。英文で論文を書いているような人は、要注意だが、見かけ上、どのように見えても、テキストファイル化した時に再現されない「約物」ルールに準じたローカルルールが、やたら多いのだ。
早めに機能ごとオフにしておくにしくはないだろう。
筆者は、旧弊な考え方の人間なので、初期のWordを試用してみて、「とても、これでは小説は書けない」と思いこんでいたのだが、最近のWordは、かなり進化しており、それで小説を書いている作家さんも多いと聞く。最初にPCを購入して、そこにプリインストールされているのがWordであれば、それを使って執筆するのは、自然な流れだろう。そして、人は、多少の不便や不具合があったとしても、一度、習い憶えたソフトを、なかなか手放せないものだ。
だから、筆者は、Wordで小説を書くことが悪いとは云わない。
だが、そうするのであれば、当然、上記のことくらいには留意して、執筆すべきだと思われる。
だが、知り合いの編集によれば、こうした例は、まだ良い方だと云う。なぜなら、これらはまだ「予測可能」だからだ。
その編集は、気が短いというか、実際派というか、こうしたことが有るか、ないし、予測できた場合は、その作家の家を訪ねて、上がり込み、PCを立ち上げ、その作家が使っているワープロソフトで、単語登録をしてしまい、以後は、この場合は、この登録記号を使うこと、といった指示をしていた由である。なるほど、少し乱暴だが、確実に、それならば、ミスは減るだろう。
だが、上述したような「よくある間違い」なら、大したことはないのだ。
最も恐るべきことは、「予想だにしなかったような間違い」「編集でさえ、想像が出来ないほどの間違い」を、作家側が、いとも平然と、しでかすことなのである。
「予想不能な間違い」は、文字通り、予測することが出来ないのだから、事前に作家に注意もしかねるし、編集の現場でも見過ごしてしまうようなものさえある。印刷の現場に回って、初めて「なんぢゃ、こりゃあっ！」となるようなミスが、一番、タチが悪いのだ。
むろん、作家には悪気はない。
しかし、こうしたことは（上述した「よくある間違い」でさえ）、世にある「作家志望者のための文章術」や「作家になる方法」「新人賞の獲り方」といったハウツー本にも、あまり書いてないことである。
だとしたら、これからデビューする新人さんはもとより、ヴェテラン作家であっても、自分が間違っているかどうか、判断がつかない。これは、実際、慄然とすべき事実なのだが、これまで、作家サイドは、「出版」や「印刷」などは（分業制なんだから）、編集や印刷所がなんとかしてくれるもの、として、あまりに無関心すぎはしなかっただろうか。
そのツケが、今、回ってきたのだ。これは、どうしようもない。
西谷氏の本にも、そうした例が、いくつか紹介されていた。
まず、昔のワープロ専用機種では、テキストファイル化する際に、行末に改行記号が入ってしまう機能や機種があった。
その延長なのか、よく判らないが、今でも、PC上でワープロソフトを使っていながら、（作家が自分で決めた）見た目の編集画面で、行末に改行記号を入れてしまう作家がいるという。
これは、代表的なワープロソフトである、Wordのテキスト化の仕様に、「テキスト＋改行」といったメニューがあることが原因だとも云われている。エディタにはメールを書く時のために、行数の整形モード機能があるので、その応用だろうか。
だが、これで、うっかり、テキストファイル化すると、1行が全角20文字として、20字ごとに改行マークが入った、非常に厄介なテキストが生産される。もらった編集さんは苦慮するだろう。
Wordで書かれた作品をテキスト化する場合は、ルビとか圏点などが落ちてしまうのだが、それでも、やるとしたら「名前を付けて保存」の際、「ＭＳ－ＤＯＳテキスト」を選択しなければならない。
もともと、ワープロ専用機種には、「表示行」の概念しか、ない。ワープロも同様である。「見た目」だけの世界なのだ。
だが、「見た目」などは、そのワープロ上でさえ、書式設定で、行数と1行の文字数を換えれば、ガラリと変わってしまう。
テキストエディタの世界では、「表示行」と「論理行（最近では、段落行などとも云う）」の違いは歴然としていた。
本来、プログラミング用に開発されたエディタでは、「見かけ」は重視されない。あくまでも改行から次の改行までの1段落が「論理的に重要」なのである。ゆえに、「表示行」は画面上の見かけの折返し行だが、「論理行」は、1段落（つまり、改行記号まで）を1行と算える。試しに、エディタの書式設定で「折り返し」のチェックを省くと、1行がえんえんと横につづく、非常に見づらい表示になる。それを避けるために、「表示上、見かけ」で画面右端で、折り返しをしているだけなのだ。
だから、というのも何だが、ワープロしか使わないユーザに「論理行」の概念を理解してもらうのは、それだけでも骨だろう。
もっとも、これ（＝1行ごとの改行記号）ならば、まだ、なんとかなる。
詳述は避けるが、「エディタの正規表現を使った一括置換機能」を組み合わせることで、ザッとではあるが、こうした場合の対応の仕方があるのだ。
筆者自身、知り合いに頼まれて、やったこともある。
ネット上に上げてからテキストで回収した作品の行末に、全て改行記号が入っていたのだ。
多少、慣れが必要なことと、エディタでなければ出来ない（ワープロは、正規表現に対応しておらず、不可能なので）、といったことを除けば、致命的なエラーとは云えない。
むろん、そのような方法を取らないように、作家側が留意するなり、気づいた編集が注意するなりすれば、よいのだが、先の例にもあったように、編集は、作家とは、ことテキストファイルに関しては何を云ってもダメだ、といった先入主からか、注意もしてくれないことがある。この場合には、作家は、永遠に気づかないだろう。
双方にとって、時間のムダであるし、互いに情報共有した方がいいと思うのだが……。
これは、ローカルルールではなく、公式ルールなのだから、相手がどんな大家であろうと、編集は注意して上げるべきだと、筆者などは考えるのだが、現実は、そうではないのである。
もっと悪い例は、「１つの作品に最後まで改行記号を入れずに仕上げたもの」だったそうである。これは、まぁ、よくマシンやソフトのメモリが持ったものだと感心するが、笑い事ではない。ご苦労にも、字下げの箇所は、全角スペースで空白を入れていた由だ。そんな厖大な「1行ファイル」をもらった編集の胸中いかばかりか、また、その後の辛苦を察するにあまりある。
さすがに、これだと、筆者もどうしていいか、ちょっと判らない。
出力された原稿を元に、1つずつ、改行記号を手作業で入れてゆくしか、ないか。
先に挙げた例の、Wordで書いたものをテキスト化する際のミスなら、やり直してもらうことも可能だが、最初から、こうしたやり方で改行マークを入れないで作成されたファイルでは、作家側でも、どうしようもないと思う。
あるいは他に、筆者が知らない方法で、なんとかするやり方があるかも知れないが、厄介であることに違いはあるまい。
付言するが、西谷氏の書が、出版界で話題になったと云っても、全ての編集者が、エディタや正規表現を使いこなせているか、というと、もちろん、そんなことはないのだ。むしろ、西谷氏のような編集は、圧倒的に少数派だと思われる。
現状では、そうしたことに関心をもち、自分たちで何とか現状を打破し、手間と時間を節約し、出版全体のコストダウンをしようと考える、ごく少数の人たちが、個別に頑張っている、というところだろう。
これはエディタのユーザ数を考えてみれば判りやすいだろう。
ＭＳ－ＤＯＳ時代、市場を席巻したVzエディタでさえ、17万本くらいしか伸びなかった。他方、一太郎は、94年までに、のべ200万本の出荷数を誇っていた。
今、Windows 上のエディタで最も使われているとされる「秀丸」は、累計ユーザ数200万と云われるが、確かな数かどうか、よく判らないし、その大半は、プログラマであろう。作家で、エディタのユーザというのは、意外に少ないはずだ。
Wordのユーザ数は不明だが、凋落していると云われる一太郎でも、現在の出荷数は2000万本と云う。Wordは、おそらくその数倍はあるはずだから、その合計と比較すれば、圧倒的な彼我の差である。
であるから、上述したような、各行末ごとに改行記号が入った原稿をもらって、それを１つずつ、手作業で削除している編集も、現時点でも、少なからず存在するだろう。筆者は実際にそうした例を見聞している。エディタを適切に使えば、数分で終わる作業を、まる一日くらいかけて、やっているわけである。むろん、その編集とて無能なわけではない。その時間があれば、やるべき仕事は山ほどあるはずだ。大いなる時間のロス、マンパワーの無駄づかいだが、方法を知らなければ、他にどうしようもあるまい。
しかしながら――、
ここまで読んだだけでも、作家から編集に日常的に渡されるファイルが、尋常一様のモノではないことは判ると思う。
くだんの編集が云う、「とても汎用化など出来ないテキスト」とは、こうした「予測不能」なファイルなのである。
それを彼は「作家の書き癖」と称したが、とてもそんな形容で収まるものではない。
そして、問題は、どの作家が、どのような「書き癖」をもっているか、事前には誰にも、全く判らないことだ。西谷氏の書を読んで啓蒙された編集さんが、エディタで開いてみたところで、その段階で、すでに仰天するようなテキストが、世の中には山ほどあって、それは千差万別であり、間違い方に、統一性など、ない。チェーホフではないが、幸福な＝正しいテキストは１つだけだが、不幸な＝間違ったテキストは、それぞれ無数の間違え方があるのである。
だとしたら、確かに、云われるよう、「入り口」での多様性が、「汎用性」を妨げている、のは確かだ。
筆者が夢見る、汎用性の高い「統一フォーマット」などは、正しく「夢」で終わる可能性が高いわけである。
それも、他ならぬ作家側の無知によって、である。なんという不条理か。
だが、事態は、さらに面倒でややこしいのだった。
つまり、「入り口」があれば、当然、「出口」もある。
そこにも「入り口」に負けず劣らず、厄介な問題をかかえているのだ。
すなわち、編集と印刷の現場の人たちの「コダワリ」である。
直接、電子書籍には関係ないとしても、それは、やはり知っておくべき「知識」だと思われる。
作家は、通常、そのような世界（＝出版業界の職人芸）を知らないし、想像したこともないはずだ。
だが、われわれが、ごく普通に手にとる「本」という媒体が、どのようなプロセスを経て、「印刷」され、「出版」されるのか、そのことを、もっと積極的かつ主体的に把え返し、知るべきだと考えるのである。
（以下、次号(笑)）
上に述べた以外に、もうひとつ、「入り口」でのネックがある。
それは、作家ごとに異なる電子データファイル、に関わるが、最終的に、テキストファイル化し、必要なタグを付ける点では、筆者の方法論と変わらないのだが、そのためには、まず、豊富なテキスト化へのツールが必要だ、というのである。
あらゆるワープロ専用機種を、揃えるのは、現在では不可能だから、そのルビや圏点まで再現してくれる「コンバータソフト」が必須となる。だが、それは、今では入手不可能な古いPC9801マシンでしか、出来ないのだ。
これは、筆者自身が、かつて知人のために組み上げたPC9801互換のEPSONのＭＳ－ＤＯＳ＝Windows3.1マシンがあり、10年ほど前になるか、ＯＡＳＹＳ（ワープロ専用機種）で作成したファイルを大量に5吋フロッピーディスクで持っている人から照会を受け、その人のために、ＭＳ－ＤＯＳ上で「ＤＯＳ恋」というコンバータを、Windows3.1上で「リッチテキストコンバータ」というメディア変換ツールを備えた、マシンをセットアップして、送付したことがある。
EPSONもそうだが、ある時期のPC9801マシンには、デフォルトで、外部端子として、外付けFDDが付属した、5吋ＦＤ内蔵機種があったのだ。
それに外付けの3.5吋ＦＤＤを付ければ、5吋のＦＤを、3.5吋ＦＤへとコンバート出来る。
念のために云っておくと、逆は不可能である。あくまでも、内蔵FDDは5吋、外付けが3.5吋でなければならない。5吋ＦＤは、そのままでは、今のマシンはもとより、90年代後半に発売された（FELLOW以後の）PC9801マシンですら、コンバート不能であるが、それ以前の機種に、こういった工夫をこらせば、メディアコンバートが可能なのである。
相談した編集の職場には、そうした工夫をほどこしたマシンや、古い機種のワープロ専用機種が、万一のために、何台か、保存され、いつでも使えるようにチューンナップされていた由だ。
そのような組織的かつ戦略的な保管と整備がないと、いかに、作家側の手許に、論理資産がある、といっても、読み出し可能ではない5吋FDの媒体など、何の役にも立たない。
この件に関しては、拙サイトの該当ページを参照されたい。
なお、そこで記されたことは、ルビや圏点は落ちるか、または「〓（ゲタ）」に文字化けするコンバータを使った例である。知人にセットアップして送ったマシンには、古いヴァージョンの（Windows3.1上で動作する）、リッチテキストコンバータを同時にインストールしておいた。それなら、ルビや圏点もワープロ通りに変換してくれたはずである。
このような物理資源と論理資源が、ともに備わっていなければ、過去の論理資産は、活かしようがないのだ。そのことを、深く留意してもらいたい。
同時に、特定の機種やアプリケーションソフトに依存すること、その媒体に依存することが、いかに恐るべきであるかも、認識してほしい。
筆者が、テキストファイル至上主義を唱えるのも、同じことである。
マシンやＯＳやワープロは、いずれ無くなるかも知れない。だが、テキストファイルが読み取れなくなることは、当分、ないだろう。むろん、それを収めている媒体は、常に、最新か、あるいは、かなりのタイムスパンの耐久性に耐えうるものに格納しておくことを推奨する。
（今のところ、CD-Rに焼いておくのが一番、安全だが、それも、向こう10年か20年の間に、どうなるか、全く不明である。今の若い人は、フロッピーディスクさえ知らない人がいる。8吋や5吋のＦＤを知らないというならともかく、FDそのものを知らないのだ。そういえば、最近の機種のPCには、FDDはオプションでしか、付いていないものが多い。とはいえ、世代間ギャップをまざまざと感じさせる話である）
| noah@fialka.bizland.com |