本を書いてみて、何が一番イヤかというと、せっかく書いた本が売れないこと……いやいや、それは措いておいて、なんといっても校正です。原稿を書く作業自体は、とりあえず(それがろくなもんではないかも知れないけれど)「何かを作り上げる」という前向きな作業なので、つらくてもなんとかやっていける面はあるのですが、それに対して校正は要するに間違い探しなわけです。こちらとしては完璧なものを出さないと、(たぶんお金を出してまで)読んでくれる読者に対して失礼だと思うわけですが、とはいえ、一字一句間違いがないように校正するのは、時間的な制約もあり(=いくらいやってもきりがない)なかなか難しいところではあります。
さて、本の校正は「校正刷」「ゲラ刷」「ゲラ」などと呼ばれるものに対して修正の指示を赤字とかで書き込みます。ちなみに「ゲラ」「ゲラ刷」とはいったい何か、ということで調べてみたところ(「広辞苑」第五版より)、
ゲラ
(galleyの訛)
(1)組み上げた活字版を収める長方形の盤。3方に縁がある。
(2)ゲラ刷ずりの略。
ゲラ-ずり【―刷】
組み上げた活字版をゲラに入れたまま校正用に試し刷りしたもの。校正刷。ゲラ。
だそうです。むかしむかしの印刷は活版印刷と言って、活字を拾ってそれを箱に並べて、それから印刷用の版を作ったそうですが、その箱のことをゲラ(galley)と呼んでいたそうです。で、そのゲラを使って試し刷りしたものがゲラ刷ということのようです ←よく知らないで言っている。
ちなみに、いまどきの印刷は活字を拾ったりはしないわけで、もちろんゲラなども使わないわけで、当然のことならが「ゲラ刷」ではないわけですが、でも校正刷のことを今でもゲラ刷と呼んだりもするようです。しかも、いまどきのDTPでは校正刷はプリンタ出力なわけで、校正「刷」ですらないような気もしますが、まああまり細かいことを気にしても仕方ないでしょう。
さて、私の場合、最初の2冊の本は、この校正刷(っつーても、いま言ったように当然プリンタ出力ですが)を紙の形で送ってもらい、それに赤ペンでいろいろと書き込んで送り返しました。以前にも書きましたが、この形式の場合、いろいろと面倒です。
まず、やりとりに時間がかかる、というのがあります。校正にはあまり時間が取れないことが多く、たとえば、編集部で木曜日に発送して、締め切りが翌週の火曜日の夕方に編集部必着だったとします。編集部から木曜日に発送された場合、それを私が受け取れるのは金曜日の夜になります(昼間は仕事なので)。そして、締め切りが火曜日の夕方ということになると、月曜の朝にはこちらから発送しないといけません(昼間は仕事なので)。ということは、校正のために実質的に取れる時間は、金曜夜〜日曜夜しかないことになってしまいます。
他にも厄介な点としては、バックアップを取っておくのが難しい、ということがあります。送り返したものと同じものを、こちらでも手元に取っておく必要がありますが、コピー機など家には無いし、コンビニでコピーするのも面倒だし、それにお金が……仕方がないので、デジカメで撮影しておいたりしました。ちなみに、なぜ「こちらでも手元に取っておく必要が」あるのか、というと、輸送中の紛失事故の問題もありますし、それよりなにより、「修正の指示をしたのに、それがなぜか直ってなかった」ということが、実は非常に多いのです。それをチェックするためには、どうしても手元に残しておかないと、次の校正でチェックができなくなってしまいます。
そんなわけで、その後の本については、メールで校正刷(とはもはや呼べんな)を送ってもらっています。とはいえ、DTPでたぶん使っているQuarkXPressというソフトのファイルをもらってもこちらではいかんともしがたいわけで(そんなもの持っていない)、もちろんPDFの形で送ってもらいます。
メールならば、先ほどの「木曜日発送、火曜日締め」の例ならば、こちらで校正のために取れる時間は、木曜夜〜月曜夜となり、時間的余裕ができます。また、バックアップも単なるファイルのコピーですから簡単です。
ただし、紙に赤ペンで書き込むのとは違い、PDFに書き込むためにはそれなりのソフトが必要です(Adobe Acrobat 7.0 Proffesionalで作成したPDFの場合には、無料のAdobe Readerでも書き込むことができるようなPDFを作成可能ですが、そうなっていないことが多い)。というわけで、Acrobatを購入しました。他のもっと安いソフトでもよかったかも知れませんが、変なところでトラブって時間を取られるよりは、ということで、高かったですが仕方なく買いました。
さて、もうすぐ発売される『Leptonの「基本情報」解体新書』の校正、3月後半から4月の頭にかけてやっていましたが、いつものことながら校正には苦労しました。今回の本では、図については(編集部を経由せずに)イラストレータと直接やりとりしたので、校正段階での修正は無かったのですが、文字のほうにはいろいろとあれこれありました。
特に問題だったのが、プログラムのコードを表記するときに使うフォントです。こちらとしては、コードの部分は等幅フォントを使って欲しいわけですが、その場所に合うような等幅フォントが無いということも多いらしく、なかなか納得の行くような見栄えにするのに苦労しました。あと、カッコやカンマ、それに + - * / > < などの記号は不規則に2バイト文字になってしまっていたり、スペースの空き方が違っていたり、そういうところを直してもらうのにかなり苦労しました。たとえば、私の元原稿で、
SELECT 地区名, SUM(講師数), COUNT(スクール名)
SUM(受講生数)/SUM(講師数) < 30
などとなっていたところが、初校(最初の校正)段階では、
SELECT 地区名, SUM（講師数）,COUNT（スクール名）
SUM（受講生数）／ SUM（講師数）＜30
となってしまっていました。この例はSQL文の一部分で、まあこの程度ならば「見栄えがよくない」くらいの弊害しかありませんが、場合によっては、スペース1文字あるかないかで、まったく意味の違ってしまうこともあるわけで、こちらとしては可能な限り元原稿どおりに表記して欲しいなあ、と思うわけです。
世にあるプログラミングの本などで、このようなヘンな表記がされている本を結構見かけます。「著者はどうしてこんなのでOKを出してしまったんだろう?」とずっと疑問に思っていたのですが、自分でも本を書いてみて、そして校正をしてみて、その疑問が氷解しました。これ、全部の修正指示を書き込むのはむちゃくちゃ大変ですし、時間もありませんし、「ええい、面倒だ。もういいや」となってしまうのでしょう。そこをがんばって修正指示をしたところで、その修正が次の校正刷でナゼか反映されていなかったりします。さらに、もしかするとDTPの作業をしている人に「あの著者の野郎、いちいちこんな細かいこと指示しやがって。そんなんどーでもいいだろ。ああ、めんどくせー」などと思われているのではないかと(←被害妄想です)。