InDesignでソースコードを自動的（？）に色分けする小技
InDesignでソースコードを色分けする小技（Visual StudioやXcode、Prettifyの色そのままに）があるんですが、先日「教えてください」といわれまして、一応自分で見つけた当社独自のワザだからどうしようか……とちょっと迷ったのですが、よくよく考えてみると毎月ソースコードが出てくる本を編集製作しているのに、色分けしているのはごく一部なので、教えてもあまり影響ないなーと。
要点をネタばらししてしまうと、VS、Xcode、Eclipse、ChromeなどからWordかテキストエディットにコピペすると色がそのまま来るんですね。後はRTF（リッチテキストフォーマット）で保存して、InDesignの配置機能で読み込むだけです。RTFの色がスウォッチになるので、後はちょちょっと微調整すればOKです。
あ、¥がバックスラッシュになってる。まぁ、あくまでサンプルということで……
最初にこのタイプの仕事が来たときはソースコード全部プリントアウトして、マーカー5〜6色買ってきて根性で色分けしたのですが、さすがにつら過ぎて……。二回目に来たときに編み出したのがこれです。
IDEからソースコードをコピペ
以下はたまたまVSですが、Xcode、Eclipse、Chrome（もちろんPrettifyなどで要色分け）でも大丈夫です。Sublime Textはダメだったので、クリップボードに書式付きでコピーできるアプリかどうかが肝心です。
テキストエディットかWordに貼り付けます（ここでVSからMacのテキストエディットにコピペできているのは、Parallelsを使っているからです）。ちなみに色が引き継がれることに気付いたのはフリーライター時代でして、たぶんWordで原稿を書く派のIT系ライターならみな知っているのではないかと思います。ちなみにWordを使う場合は、オートコンプリートで句読点が化けないよう要設定変更です。
そのままRTFで保存します。
Web系の場合はコードをChromeで表示すればOKなので話が早いのですが、それ以外のIDEを使っている場合はここまでの作業を著者さんにお願いするケースもありえます。 なので、出版社さん、著者さんとも要相談です。
原稿を全部RTFにするという手もありますが、本文に余計な書式が付きそうでちょっと怖いので試したことはありません。
InDesignに読み込む
InDesignの［ファイル］メニュー→［配置］で読み込みます。このとき初回読み込み時は〈読み込みオプションを表示〉のチェックをオンにしてください。
「RTF読み込みオプション」ダイアログが表示されるので、〈英文引用符を使用〉のチェックをオフにし、〈テキストと表のスタイルおよびフォーマットを保持〉を選択します。他はそのままでOKです。〈英文引用符を使用〉がオンのママだとダブルクォートが全角になってしまうのでそこだけ要注意です（厳密には全角ではなかったかも？ とにかくヘンになります）。
はい、読み込まれました。フレームグリッドに直接読み込むと書式が付くので、別にテキストフレームを作って配置したほうがよいはずです。
スウォッチパネルを見るとちゃんと色が引き継がれていることが確認できます。RGBなので後でCMYKに直しておきましょう。
後、忘れがちなのですが、Windows関連の本ではバックスラッシュを¥に要置換です。
フォントとサイズを整える
さて、ここからは色分けとは直接関係のないオマケです。まず、ソースコード用の欧文フォントに和文を組み合わせた合成フォントを作ります。
段落スタイルを作成し、さっき作った合成フォントとサイズを指定します。デフォルトだとタブ幅が広すぎるのでそれも設定しておくとベターですね。
読み込んだソースコードに段落スタイルを設定します。ここで［option］＋クリックで適用するとせっかくの色が消えてしまうので気を付けましょう。ただのスウォッチなので。 段落スタイルに「＋」が付いた状態でOKです。
自動というかだいぶ手作業なんですが、スタイル類は一度作ってしまえばいいので、それほど大変ではないです。
さらにもうひと手間
ソースコードはテキストボックスに入れることが多いのですが、長いコードが多い本だと修正が大変になってしまいます。なのでデザインの自由度は下がりますが、本によっては表組みにします（これは独自ではなく、とある仕事で教えてもらいました）。
［表］メニュー→［テキストを表に変換］を選択して、〈列分解〉の区切り文字をタブ以外にしておきます。
後はセルスタイルなどチャチャチャと設定して、最後に本文のフレームにカット＆ペーストして完成。これだとコードのページまたぎが文章と同じように自動処理されるので楽ですよ。
このソースコードを表にする方法はデメリットもありまして、数十行の長いソースコードが続きページまたぎが大量発生する本では便利なんですが、後からのソースコード差し替えが多い場合は逆に面倒なことになります（表に行を足したり削ったりするハメに……）。
ページまたぎが多いか少ないかでフォーマット作成の方針を決めておくと吉です（とはいえ、走り出してから気付くことも多いのですが……）。
