原稿指定のあり方を考える
文字をどう指定するか
手書きの原稿を元に専門のオペレーターが文字を入力していた昔に比べ、最近は原稿を作る側が直接パソコンで入力したテキストをDTPソフトに流し込むというのが一般的になり、作業は大幅に効率化されました。さらに昔は、原稿に従って活字を選ぶ「文選」、それを文章に組む「植字」という工程に分かれて作業していたわけですから、その作業の効率向上の度合いは計り知れないものがあります。
テキストデータという便利なものを使うようになったことでもたらされたのは、作業の効率化というメリットばかりではありません。気をつけないとトラブルを引き起こす危険がないわけではないのです。
テキストデータは、基本的にシフトJISで保存されるのが一般的です。最近はユニコードで入力できるワープロソフトも多くなりましたが、プレーンなテキストに保存する際はシフトJISの範囲内でしか保存できないことがほとんどです。
多くの場合、シフトJISの範囲内で文字が不足することはないでしょうが、専門的な文章でシフトJISにない文字を多く使うケース、あるいは、文字の形を厳密に使い分けたいといった場合、シフトJISの文字だけでは不足することになります。
OpenTypeフォントはユニコードベースのフォントであり、シフトJISにない文字や文字コードでは同じ字とみなされる異体字などを多く収録してあります。OpenTypeフォントを使うことで、DTP作業では筆者が使いたい文字で組むことができるわけですが、そのためには文字が正確に指定されるということが前提となります。
シフトJISで保存されたテキストデータをそのまま流し込んだだけでは、当然ながらシフトJISにない文字は出てきません。ユニコードにしかない文字や、文字コードでは同じ字とみなされる異体字などはDTPソフトの機能を使って指定するしかないのです。
この場合、テキストでは指定できないこれらの情報を原稿の段階でいかに指定し、作業するオペレーターに伝えるかが重要になってきます。たとえば、ユニコードで指定すれば解決するということであれば、原稿をテキストではなく、Wordドキュメント形式で保存するというのもひとつの方法です。ただし、それでもユニコードで指定しきれない異体字の問題は残ります。
OpenTypeフォントには、字形を指定するタグがあります。たとえば、JIS78とか印刷標準自体といったタグを使うことで、異体字をある程度コントロールすることができます。ただし、これも完璧ではなく、また、タグによって字形がどう変わるかを把握しておかないと、かえってトラブルが起きる元になりかねません。
OpenTypeフォントを使うことを考えると、異体字を指定する場合はフォント名とCID(GID)番号を指定するのがベストでしょう。字形を直接指定するのであれば間違いが起きる余地はありません。ただ、原稿作成者にCID番号まで調べさせるというのは現実的とは言えません。
スマートではありませんが、必要な文字だけ手書きの原稿を添付するという方法もあります。その文字が複数出てくるのであれば、一括して検索・置換すればいいわけです。InDesign CS3以降では字形を指定した検索・置換が可能になったため、この方法はかなり楽になりました。今のところ最も現実的なやり方でしょう。
組版の指定
組版レイアウトの指定は、きちんと指定されていればそれほど問題が起きることはありません。指定する項目自体は従来から変わりがないので、それをレイアウトソフトに即して考えればいいわけです。ただし、レイアウトソフトの特性をよく知らないと問題が起きる可能性もあります。
よく問題になるのが行送りの指定です。行と行の間の広さを指定する場合、行送りと行間という二通りの指定方法があります。行間は文字通り行と行の間のアキを指定するもの、行送りは、行の並ぶ間隔を指定するものです。行送りは行の基準となる位置から次の行の同じ基準位置までの間隔ですから、行送り=行間+文字高さ(幅)という関係です。
複数の文字サイズが混在する組版では、行間より行送りで考えたほうが便利ですが、その場合、基準位置をどこにするかで実際の送りが変わってくる可能性があります。
たとえば、文字サイズが12級の行と13級の行で混在していた場合でも、行送りを20歯で指定すれば20歯で行が並ぶはずです。ただし、基準の位置が上(横組みの場合)と下では、同じ行送りでも見た目の間隔(行間)が違ってきます。
なお、InDesignでは、段落設定で「行送りの基準位置」を指定するようになっています。この設定で、「仮想ボディの上/右」を選んだ場合(デフォルト設定)は、行送りは指定した行から下の行までの間に適用されますが、それ以外だとその行から上の行までの間に適用されます。行送りをこまめに変えて調整する場合は注意が必要です。特に、和文と欧文が混在するようなケースでは、十分気をつけて指定をしないと、思ったような結果が得られないことになります。
原稿がデータで渡されるようになって、便利になったのは間違いありません。ただし、そのことによって、データに関する知識が要求されるようになったということも忘れるべきではないでしょう。
(田村 2009.5.11初出)
(田村 2016.6.29更新)