『入門GTK+』

無事に発売。

『入門GTK+』
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06776-1

内容については、今回レビュアになってくださった須藤さんが代表を務める、ク リアコード社のBlogが詳しいのでそちらを。

入門GTK+ - ククログ(2009-10-14)
http://www.clear-code.com/blog/2009/10/14.html

GTK+の知識がそれほどない方でも読み進めていきながら徐々に理解を深めら れる流れになっています。

打てば響く優秀な人たちとご一緒できて、楽しい仕事でした。

ここでは編集制作の技術的な面についてメモ。

要件

• 著者が継続してメンテナンスでき、かつ増刷・改訂時に困らないように
• フォーマットは生のLaTeX

支援ツール

用意したもの

• メーリングリスト3つ（QuickML）
  • 本文関連
  • サーバからの自動通知配信
  • 装丁関連
• リポジトリ（Subversion）
• ITS（Trac）
• CI（CruiseControl.rb）

注

• 道具は普及していてハマりにくいものを使う。
• メーリングリストは山場では流量が増える（100+/日）ので、自動配信の類を 別のリストにしておくと、議論を見失いにくい。
• ITSやCIまで用意するのはおっくうだけど、みなが楽できるので、1冊終わる ころには割に合う。

紙版を作るにあたっての課題

スクリーン版と紙版の作り分け

Makefileをオリジナルのとは別に用意して、そちらで対処することに。

1. 本文中の切り替えが必要な部分を、新規に定義したマクロでくくる。

2. 媒体によってマクロを適切に再定義する。版面やフォントを変えたり、各種 カラーに適当な濃度のグレーを割り当てたり。

原稿にもかなり手を入れてしまったけれど、オリジナルのMakefileでもまだ一応 ビルドできる。

• LaTeXマクロは再定義より新規作成が安全
  既存のマクロを再定義すると、他のマクロとの不整合が生じる可能性がある ので、なるべくなら新規に定義した自前の環境で包んで、その中の振る舞い を変えたほうが安全。

カラー

紙版は墨1色刷なので、RGBカラーではなくグレースケールが必要。

• 文字や罫線
  • 媒体別に再定義して、紙媒体向けには適当な濃度のグレーを割り当てる。
• 画像
  • ImageMagickのconvert（内部でGSを利用）では劣化する画像などがあった ので、Illustratorを使って手動で変換・管理。（できればソースからRGB カラー（スクリーン向け）とグレー（紙向け）の画像をmake時に生成する ほうが望ましい。）
  • 使う画像を媒体によって切り替える方法も、basenameを区別するのは手間 がかかるうえに間違えそうだったので、同じ構造のツリーを2つ用意して、 \graphicspathで画像のサーチパスを切り替えて対処。

フォント

任意のフォントではなくHiraginoを使うように変更。

• Hiraginoの実体がない環境でもビルドできるように、RyuminやGothicBBBをい い加減に割り当てたfake.mapを用意。

ビルド環境

LaTeX環境を揃えるのは、DebianやUbuntuでもちょっと手間。以下対症療法：

• CIサーバを立てて、commitすればビルドできるようにする（ただし手元で試 行錯誤できないし、ビルドが頻繁に壊れる）
• ビルド環境をVMのイメージとして用意して、関係者に提供

まとめ

• Keep
  • 優先順位の高い順にtodoをこなし、ほぼ目論見どおりのものを時間どおりに リリースできた
• Problem
  • 画像を手作業で変換して目視で確認しているのは危うい。媒体に応じた画像 をソースから生成すべき
  • リリース管理が一時期軌道から外れた
  • 主にシステム管理やマクロ周りで、手離れが悪く自分がボトルネックになっ ている仕事が多い
• Try
  • 複数の出力媒体・複数の出力フォーマットを考慮した制作方法を確立する

この本に限らないtodo:

• CIやITSを改善する
  • 設定管理を他の人でもできるように
  • 負荷分散（主にCI）
• アカウント管理全体を改善する
  • SSH公開鍵に対応
  • 一元化
  • 参加するメンバー自身が設定できるように

システム管理仕事の大半は自動化できる類のことなので、手をかけずに回る仕組 みを早くつくりたい。編集制作以外にも執筆の支援など、やれるのにやれていな いことが多い。