メッセージ。 - 本の作成工程における細々とした謎
# 本の作成工程における細々とした謎
森博嗣さんが、原稿の校正などについて書かれていた。ぼくもけっこう、普段この問題で悩んでいるので、困惑の様子がよく分かる。同じような悩みを持つ人を見つけてうれしいなぁ。
これはソフトウェアで禁則処理できると思うけどなぁ。QuarkXPressやInDesign(雑誌や広告で使われるソフト)を使っている分には少なくとも設定できるはず。文芸の世界では、別のソフトを使っているのかなぁ。よく分からないのだけど。できてもおかしくないと思う。一応、(雑誌しか知らないですが)そういう設定をしている例があるということで。
この感覚は本当によく分かる。なんていうのかなぁ。プログラミングの工程で言うと、テキストデータがソースコードで、最終原稿が実行ファイルに当たるんだよね。で、出版界では、最初に執筆者からもらった原稿こそテキストデータ(ソースコード)の状態で扱うのだけど、それ以降の工程では、印刷されたもの(実行ファイル)を元データとして扱う感じに近い。
だから赤入れという作業は、実行ファイルにパッチを当てるような感じで行われている。ある部分を変更すると、別の部分のアドレスが変わって、それを直すとまた……みたいな感じ。そうやって、徐々に完成に近付けていく。すごくアドホックで労働集約的だと思うけど、じゃあ実際どうすればいいかというと……なかなか難しい。
たとえばTeXやHTMLで原稿を書いても、抽象度の低いタグを使いたくなるときがあるのと同じ感じといえば分かってもらえるかなぁ。「ここで改ページしてほしくない」とか、「ここに50mmスペースが欲しい」とか、「1ページの中にたくさん図を入れたいのだけど、人手でレイアウトしないと美しくならない」とか。ほかにもたくさんたくさん、雑多なことで悩ましい事象が発生する。
それを解決しようとしたら、深みにはまらざるを得なくなっちゃうわけですね。本当はみんな、バイナリ(実行ファイル・具体的なデータファイル)なんていじりたくない。抽象度の高い、扱いやすいテキストデータをベースに作業したい。でも、なかなかねぇ……。(ちなみに、印刷所の人からすれば、「バイナリのほうが扱いやすい」のですよね。そういうのも問題をややこしくしていると思います)
で、上記なんですが、実は説明の都合上ちょっと不正確な部分があるのです。というのは、「実行ファイル」と表現した最終原稿なんですが、可読性がそんなに低くない電子データの状態で扱っているのです(現場によって違う可能性もあります)。HTMLみたいな感じで、たくさんメタタグ(少し正確に言うとレイアウト情報)が入っているとは思うのですが、「自分が書いたテキストが入ってるなぁ」ぐらいは識別できる状態のはず。PDFファイルから「テキストデータを抽出」ってやると、グチャッとなったテキストを得られるけど、そういう感じ。
もしそういうのでよければ、出版社との交渉次第でもらえると思います。ただし、権利関係が難しいと考えます。出版社からすれば、「レイアウトに費したコストや、企画・流通との調整コストなどはうちのものだし、できれば渡したくない」という考え方ですね。そういうこともあり、「権利やデータの壊れ具合といったシチメンドクサイことを考えるのなら、出版された本からスキャンしたほうが早いや。個人的に使いたいだけだし」、あるいは「たしかに本が手元にある」というのが、たぶん一般的に妥当とされている落としどころなんだと思います。
何度も何度も書いていることだが、僕は行の最初に「ー」や「…」が来るのが嫌なので、これを禁則処理してもらっている。雑誌の連載時には諦めていて、指摘しないことが多いが、せめて自分の本くらいは、自分の好きなフォーマットにしたいと思って、編集部に要求している。しかし、これが簡単にはできないのだ。そんなこと、プログラムで処理すれば良い(現にパソコンのワープロはできる)はずなのに、出版界では残念ながらこの処理ができない。だから、僕自身がすべて赤を入れて、こう直してくれ、この文字を送れ、ここで詰めてくれ、と指定をしている。しかし、どこかを直せば、新たに禁則が生じることもある。だから、それも見越して修正を指定している。それでも、完璧には直らない。
これはソフトウェアで禁則処理できると思うけどなぁ。QuarkXPressやInDesign(雑誌や広告で使われるソフト)を使っている分には少なくとも設定できるはず。文芸の世界では、別のソフトを使っているのかなぁ。よく分からないのだけど。できてもおかしくないと思う。一応、(雑誌しか知らないですが)そういう設定をしている例があるということで。
もう1つ、ついでに書いておくと、自分が書いた本のテキストデータを自分で持っていないことが不思議だ。最初の原稿は手元にある。しかし、ゲラ校正で赤を入れ、直した結果の最終原稿というものが、デジタルテキストとして存在していない。印刷所にはあるのだろう。でも編集部と作者は持っていない。印刷された本しかない。プリンタで紙に印刷したら、もとのファイルを消去してしまうのと似ている。この感覚も僕には信じられないことである。
この感覚は本当によく分かる。なんていうのかなぁ。プログラミングの工程で言うと、テキストデータがソースコードで、最終原稿が実行ファイルに当たるんだよね。で、出版界では、最初に執筆者からもらった原稿こそテキストデータ(ソースコード)の状態で扱うのだけど、それ以降の工程では、印刷されたもの(実行ファイル)を元データとして扱う感じに近い。
だから赤入れという作業は、実行ファイルにパッチを当てるような感じで行われている。ある部分を変更すると、別の部分のアドレスが変わって、それを直すとまた……みたいな感じ。そうやって、徐々に完成に近付けていく。すごくアドホックで労働集約的だと思うけど、じゃあ実際どうすればいいかというと……なかなか難しい。
たとえばTeXやHTMLで原稿を書いても、抽象度の低いタグを使いたくなるときがあるのと同じ感じといえば分かってもらえるかなぁ。「ここで改ページしてほしくない」とか、「ここに50mmスペースが欲しい」とか、「1ページの中にたくさん図を入れたいのだけど、人手でレイアウトしないと美しくならない」とか。ほかにもたくさんたくさん、雑多なことで悩ましい事象が発生する。
それを解決しようとしたら、深みにはまらざるを得なくなっちゃうわけですね。本当はみんな、バイナリ(実行ファイル・具体的なデータファイル)なんていじりたくない。抽象度の高い、扱いやすいテキストデータをベースに作業したい。でも、なかなかねぇ……。(ちなみに、印刷所の人からすれば、「バイナリのほうが扱いやすい」のですよね。そういうのも問題をややこしくしていると思います)
で、上記なんですが、実は説明の都合上ちょっと不正確な部分があるのです。というのは、「実行ファイル」と表現した最終原稿なんですが、可読性がそんなに低くない電子データの状態で扱っているのです(現場によって違う可能性もあります)。HTMLみたいな感じで、たくさんメタタグ(少し正確に言うとレイアウト情報)が入っているとは思うのですが、「自分が書いたテキストが入ってるなぁ」ぐらいは識別できる状態のはず。PDFファイルから「テキストデータを抽出」ってやると、グチャッとなったテキストを得られるけど、そういう感じ。
もしそういうのでよければ、出版社との交渉次第でもらえると思います。ただし、権利関係が難しいと考えます。出版社からすれば、「レイアウトに費したコストや、企画・流通との調整コストなどはうちのものだし、できれば渡したくない」という考え方ですね。そういうこともあり、「権利やデータの壊れ具合といったシチメンドクサイことを考えるのなら、出版された本からスキャンしたほうが早いや。個人的に使いたいだけだし」、あるいは「たしかに本が手元にある」というのが、たぶん一般的に妥当とされている落としどころなんだと思います。
Comment
Trackback