2009年03月09日

最近の書籍作りのプロセス(1)

いろいろな経緯があって、昨年から編集という業務だけでなくこのblogセクションにもあるようにAdobe InDesignを中心に据えたXML組版業務にも関わるようになっています(幼少からのコンピュータ、大学でUnix/LaTeX/SGML、最初の会社でPerl/SGML/XML/Webプログラミング、今の会社でEmacsマクロ/Ruby、もう10年以上になるDebianとフリーソフトウェアとオープンソースソフトウェアへのかかわり、と蓄積してきた知識が今になって集大成化してきたというのは不思議な感じもありますね)。

LaTeXを知る身からすると、高価にもかかわらず旧来のDTPソフトのおそろしいほどの手作業っぷり、まさに1ページ1ページを絵のように作っているのを見て愕然としていたわけですが、最近はDTPソフトも機能が向上してきてだいぶ作業者に優しく、機械処理にも優しいものになってきたと思います。特にAdobeのDTPソフトInDesignはXML処理やJavaScriptエンジンが塔載されて、ようやく機械組版が私にとっても現実味を帯びてきました。

バッチ組版処理ではLaTeXが最強だと思いますが、LaTeXのマクロや入力は常人には理解不能で標準的な書籍制作プロセスには採用し難いものがあります。原著がTeXでタグを活かさないと死ぬとか、著者なり編集なりが入稿青焼きまで責任を持ってやってくれるとかではない限りはまず敬遠されます。私の務めている(株)トップスタジオは編集プロダクション会社なので、データも組版レイアウト(テンプレート)もお客様のご希望合わせであり、定型フォーマットでのシステムを組むわけにもいきません。とはいえ、これまで同様にちまちまと手で作っているのでは、コストの安いところに根こそぎ持っていかれることはほぼ確実であり、各社バッチ的な組版を検討、あるいは実装を始めているところではないかと思います。

TeXに比べると、InDesignならDTPオペレータも馴染んでおり、新たな機能を使用するための教育コストはずっと低く済みます。導入するシステムの下地にはXMLがあるにしても、そこにかかわる作業者ができるだけそれを意識しないような仕組みにしておけば、既存知識+α程度で作業を進めることができます。

最近私が制作にかかわっている書籍は、納期的に厳しいとかデザインに凝りすぎということがなければ、InDesign+XMLでの機械組版で行うようにしています(『独習Java第4版』『OpenVZ徹底入門』『zsh最強シェル入門』『独習Javaサーバサイド編』『Windows Server 2008オフィシャルマニュアル』『独習Visual Basic 2008』『SQL Server 2008ビギナーズガイド』)。最近の書籍は立ち上げのみを私が担当し、本格的に始動してからの作業はほかの方々が担えるようになっています。

さて、私の構築した機械組版におけるステップは次のようになっています。

  1. 著者または編集者が簡易タグ付け。生のXMLは人間には見るに耐えないフォーマットであり、特にXML内の改行が重要な役割を果たすInDesignにおいてはますますひどい文書となります。そのため、この時点の作業者は扱いやすく読みやすい簡易タグでマークアップしていきます。現在は別記事でいつか紹介する予定のReVIEWという拡張可能なフォーマットを採用しています。見出しやキャプションの連番処理、相互参照といったミスや面倒を生みがちな処理はReVIEWの機能に任せることができます。Emacsと秀丸向けのエディタモードを作りました。
  2. 画像については従来同様にPhotoshopなりIllustratorなりで変換したり作成したりします。画像についてはスクリプトで一括のグレースケール化・適正リサイズ化・DPI変更をするようにしています。Illustrator(eps)向けには「4色になってる」「RGBだった」といった印刷事故を防ぐためにlgrepベースのチェッカースクリプトをかけるようにしています。
  3. 簡易タグ→XML変換。これはバッチです。簡易タグがいかにXMLに変換しやすいかが肝となります。ReVIEWフォーマット→XML変換自体はすでにReVIEWに実装されています。
  4. InDesignのテンプレートをXMLタグに合わせたり、XMLタグを構造に応じてテンプレートのスタイルに合わせたり。これはDTPオペレータとプログラマーの協業です。InDesignのXMLでは段落スタイル、文字スタイル、表スタイル、表セルスタイルを直接割り当てられます。オブジェクトスタイルはあとでJavaScriptでXMLを検査して適用します。現システムの単一障害点ですが、RubyのREXMLを使用したライブラリの充実を進めており、実装しなければならないコードはだいぶ短くなってきました。変換はRubyが動けば、たとえばLinuxに限らずMacOS Xでも動作するので、MacOS X環境であれば制作工程全部を1台で実施することも可能。
  5. テンプレートとXML変換部が完成したら本番のXMLを読み込ませ、スタイルの自動適用をします。これだけでもかなりの作業を軽減できますが、さらにオブジェクトスタイルの設定、脚注処理などもJavaScriptで自動化します。実行はメニュー形式でDTPオペレータが簡単に扱えるようにしています。
  6. ページの調整や長体処理などは通常のDTPオペレーションと同じです。InDesignで全部をバッチ処理でがんばろうとするのは無理というのが私の行き着いた結論でした。こういうお仕事では、あきらめどきの見極めが重要です。注文の多い書籍ではこの作業はそれなりに時間がかかりますが、手組みほどはかからない、かな？
  7. XMLと機械処理にとってガンなのがテキスト中にフレームを挿入して別ドキュメントをさしこむという、コラムなどによく使われるインラインテキストフレームなのですが、機械組版ではこれを極力排除して、代わりに下のレイヤーに枠やアミなどを描画しています。ページがこれ以上動かないと判断した段階でJavaScriptを実行して、XML要素の起点・終点情報からこのレイヤー描画を行うわけです。柱もこの段階でXML情報を基に作ります。実行は先と同様にメニュー形式なので、DTPオペレータが操作します。
  8. これでひととおりDTPは終わりで、Postscript出力→DistillerでPDFを生成します。InDesignの直接PDF出力はタグが含まれているとカーニングがおかしくなるという不具合が少なくともCS2,CS3にはあるので、入稿まですべてこの手順で作成するPDFを使うことになります(よってデータ入稿限定のお仕事にも使えないですね)。
  9. 目次作成はXML情報とInDesignのページ情報の双方からひっぱってXMLを生成させます。InDesignの段落スタイルベースの抜き出しはどうも怪しいことがありますし(順序が変わったりする)、XML生成版なら適当にスタイルを後処理で加えることができるというメリットがあります。
  10. 権利表記や奥付などの機械でやっても大してメリットのないところは手組みで組んでしまいます。
  11. 索引は簡易タグのときに埋め込んでおいたものをInDesignファイルから拾い出すこともできますし、別途テキストで作っておくこともできます。いずれにせよ、作ったテキストをmendexkを応用したCGIプログラムに通して索引XMLを生成します。本文のPDF内のテキストとgrepで照合するような仕組みも用意して、漏れやズレの大まかなチェックにも役立てています。
  12. 台割については簡易なテキストファイルから必要なチェック、Excelファイルへの変換をこなすようなCGIプログラムを作成して利用しています。ただその印刷についてはOpenOfficeもGnumericも必要となるマージン調整が面倒すぎるので、Microsoft Excelで印刷せざるを得ないというのが若干不満ではあります。

ごはんが食べられなくなると困るので全部を公開するわけにはいきませんが、時間のあるときに各手順などについてもう少し詳細を説明していく予定です。

リンク [hatena] | InDesign