＜まず再現が大事＞
（前回より続く）
前回の前書きで精神論を書きましたので今回は技術論を。
持ち込まれたオフィス・データを印刷用のPDFに変換するにあたっては、まず通常のDTPアプリと一般的なオフィス・アプリではアプリの性格に違いがあることを認識することが必要です。
IllustratorなどのDTPアプリは体裁の維持が優先されています。環境が違うことで体裁が変化することがないように、ファイルを開いた時にいろいろな警告を出してくれます。これに対してMS Officeなどの一般的なオフィス・アプリでは情報の維持が優先されます。Aの環境で4ページに収まっていた書類がBの環境では5ページになってしまう、といったことも日常茶飯事です。そして怖いことは体裁が変化しても警告を出してくれることがないことです。
ですから、オフィス・データをそのまま使用することになった場合、先方の環境ではどのように表示されていたかを把握することは重要です。厳密には先方の環境をそっくり再現しなければいけないのですが、それは非現実的ですから実際には先方の環境で印刷出力されたものを預かることになります。これを横着して先方との間に入る営業マンが自分の環境で印刷出力したものでこっそり代用しようとすることがあるので、よく重要性を理解してもらって基本的なルールとして守るように努力しましょう。（私もこれであわや刷り直しになるような事故にあったことがあります。）事故というのは多かれ少なかれヒューマン・エラーから発生するものです。
先に書いたとおりオフィス・アプリでは体裁の変化に対して警告が出ませんから、先方の環境で印刷出力されたものとこちらの環境での表示結果をよく見比べて確認します。ただ、たとえばWordではWYSWYGと言っても画面表示ではフォントはビットマップになったりしますので、印刷出力して確認したほうがいいと思います。
おそらくほとんどの場合、Mac版ではWindows環境で作られたオフィス・データの体裁は維持されていないと思います。（私の経験が少ないので断定はできませんが。）MS明朝やMSゴシックは付属しているとはいえ、その他のWindows用フォントが使われていることも多いし、GDIとQuickDrawという根本的な部分で異なるMac版では再現が難しい部分もあるでしょう。ですのでWindows環境を用意しておくことが必要になるかと思います。幸いなことにMacも新しい機種はIntel搭載マシンになり、Windowsとの併用もできるようになりましたから以前よりは敷居は低くなっているかと思います。
こちら側の環境で十分に再現できているのを確認できたらPDF変換の作業にかかりますが、再現できない場合も出てきます。その場合にいくつか試したりする点があるのですが、次回はそれらをいくつか書いてみようと思います。
（次回に続く）
＜オフィス・データの印刷用PDF変換の位置づけ＞
近年ではパソコンの普及によって、今まで印刷業者に制作一切を頼んでいたような印刷物を顧客自身がパソコンでデータを作成して持ち込むケースが増えています。また、制作を依頼される場合でも、ケースによっては顧客が用意したデータをそのまま使うこともあるでしょう。
特に印刷業者にとってはその対応に苦慮する場面が多いと思います。DTPの技術的なレベルが高くない、あるいは単一的な制作システムでしか対応できないような中小業者では、受けたくてもそれを適切に扱えない、断れば顧客が他所へ流れてしまう、ということで判断が難しくなります。まして今まである程度の金額が見込めた制作代の売上も削られることになるわけです。
印刷・デザインに携わる人たちの間には以前からMacが普及していたこともあり、オフィス・データで主流のWindowsへの対応には消極的だった感があります。私はもっと積極的にオフィス・データへの対応をしていくべきだと以前から主張をしてきました。ひとつにはこれだけパソコンが普及すれば顧客もそれを利用して営業しているのは当たり前で、印刷業者が受け皿にならないなら他業種がそこに進出し、引いては業界の先細りの原因のひとつになる可能性があるからです。そしてもうひとつ、こういうことを言う人を見かけないのですが…
顧客が作成したオフィス・データには顧客が持っているその印刷物への願望が詰まっているのです。私はDTPに触れる前には普通にWindowsでWordやExcelをいじっていましたから、データを開けば「あ、制作者はこういうことをやりたかったんだな」というのがすぐ理解できます。たとえそのままでは使えないにしろデータを受け取って見てみることで、顧客が何を考えているか、下手な打ち合わせを重ねるよりも大きなヒントをもらえるのです。
そしてデータを受け取ってから、「うちではこれをそのままでも出せますが、もっと効果的にお作りすることもできます。」と言うのと「うちではこれは使えませんが、もっと効果的にお作りいたします。」と言うのとでは営業的な威力が全然違ってくると思います。後者の方はどうしても言い訳じみたニュアンスを感じさせてしまいます。そして顧客は前者の方が後者よりも顧客の意図を尊重してくれそうだという期待感を抱くはずです。（もっとも制作の力量に明らかな差がある場合は別ですが。）
「顧客が作ったオフィス・データなんてそのまま商業印刷には使えない」ということは確かなことかもしれませんが、それが「できない」ことへの言い訳になっているならそれは間違いだと思うのです。「できる」ことを示さない限り「できない」理由が単なる言い訳でないことを相手に納得させるのは難しいでしょう。相手が苦労して作った思い入れのあるデータを持ち込んだ場合ならなおさらです。
私はオフィス・データへの対応についてそのような観点で考えているので、印刷用のPDFに変換する場合でもあまり細かい所まで修正する必要はないと思っています。（例えばMS OfficeのXP以降では表の罫線を墨のみに変換するのは難しいと思います。）ただ、例えば文字の黒が墨のみになっていないとか、線が消えてしまうとか、変換の設定次第で容易に避けられることはきちんと処理するべきでしょう。難しい点はオフィス・データの多くはPostScriptとは違う体系で作られているので、状況に応じて最善の処理の仕方が変わってくることです。そのあたりの例を、DTP Referenceのカテゴリーで続けて書こうと思っています。
（次回に続く）
意味不明な名前がついている当ブログですが、ブログ名にちなんで？今回はトンボについて書きたいと思います。
DTPを職業にしている方でもIllustratorでの「正しいトンボのつけ方」を知っている方は意外に少数派のようです。私がある印刷会社の出力業務を請け負っていた頃、Illustratorでの入稿で正しいトンボがついたものは全体の2、3割程度しかありませんでした。
「オブジェクト→トンボ→作成じゃなくて、フィルタ→クリエイト→トリムマークで作るんだろ、そのぐらい知ってるよ！」と思った方、それだけではないですから注意してください。8割近くの方が間違えていたという点はそこではなく、トンボを作成するもとのオブジェクトの線幅の状態なのです。
正しいトンボの例
間違いの例
上が正しいトンボがついた例、下はありがちな間違いの例です。トンボを選択ツールで選択するとこの寸法になっています。幅（W）と高さ（H）に注目してください。正しい例よりも約0.353mm大きくなってしまっています。なぜこうなってしまうのか？
それはトンボを作成する際にもとのオブジェクトに線幅が設定されてしまっているからです。Illustratorはもとのオブジェクトで実際に描画で使用される領域の端を基準にトンボを作成します。ですからこの間違いの例では線幅の1ポイント分だけ大きくなっているというわけです。
実際の現場では問題になることは少ないし、問題になる場合でも製版側で対応してしまうことが多いです。私も制作側にフィードバックしたことはないです。（ただでさえ文句が多いと思われているのに、ここまで細かく言うと仕事が来なくなってしまう^^;）
ただ、例えば名刺の刷り込みの仕事などではこの1ポイントのズレでも致命的な事故になる可能性はあります。やはりこうした基本的な部分には気を使ってほしいと思います。
トンボの位置もできれば正しくアートボードの中央になっているのが望ましいです。フィルム出力時代の名残なのか、アートボードが実際の制作サイズより1サイズ大きく取ってあってトンボの位置をきちんと取っていない方が多いです。これからPDFワークフローが普及していくにつれ、アートボード＝実際の制作サイズにしておかないといけなくなることも多くなると考えられますから、トンボの位置は正しくアートボードの中央にするように習慣づけした方がいいかと思います。
Illustratorで1ポイント分大きいトンボの寸法の端数は「753」となります。私の狭い経験内での話ですが、この753ファイルは出力の際は要注意でした。入稿データに不備がある確率は753ファイルの方が圧倒的に多いのです。後工程に優しい、完全データの出発点はまず正しいトンボのつけ方から、なのかもしれません。
私は最初にEPSがIllustratorのネイティブ・ファイルのように錯覚するのは問題だと書きました。何が問題なのかを抽象的な文章で説明するより、トラブルの実例を体験していただいた方がわかりやすいかと思います。前回の記事（書き直し前）のコメントでMM岩手さんから面白いサンプルを教えていただきましたので、ここで紹介しようと思います。
手順（一部引用者加筆）
1. Illustratorで太い線を使って円を描く。（例：半径の5分の1程度）
2. EPS形式で保存する（PDFでも可）。
3. InDesignのドキュメントに先程保存したEPSをリンク配置。
4. 配置した画像に変倍をかけて楕円にする。
5. InDesignからEPS形式で書き出す。
6. このEPSをIllustratorで編集しようとしてみてください。
どうでしょう？ ちなみに5.のEPSをDistillerに送ると正常なPDFが出力されます。InDesignのEPSが不正ということではないのです。Illustratorで正常に開くことができると言い得るEPSは同じバージョンのIllustratorで作成したEPSに限られると思っていた方が無難です。InDesignを含め他のアプリケーションで作成されたEPSは正常に開けないか、開けたとしてもそれは偶然でしかありません。なぜなら再三書いている通りEPSはIllustratorのネイティブ・ファイルではないからです。
さらに6.からそのままIllustratorで上書き保存をしたとします。そのEPSを「イラレの鬼」等で作成アプリケーションを確認するとIllustratorになっているはずです。このファイルを何も教えずに後工程に流したらどうなるでしょう？ 後工程でこの不具合に気がつく手がかりはありません。
非常に怖い状況だと思えませんか？ しかしこういった危険は顧みられずに、今日もどこかでIllustratorで他のアプリケーションで作成されたEPSが無理やり編集されているのでしょう。
私がよく見たのはQuarkXPressから書き出したEPSをIllustratorで開いてフォントのアウトラインを取ろうとしたものです。その手のファイルは気がつきにくいところで部分部分が飛んでいたりします。しかしファイルをくれる人は平気で「Illustratorのファイルだよ」と言って渡すのです。もうこうなると卓越した洞察力が無ければ出力業務を無事にこなすことは不可能です。出力業務に負担をさせているこの状況が私は問題だと思っているのです。
最近ではスクリーンも富士もハイデルも、ソリューションとしてPDFワークフローを中心にラインナップを揃えています。それはPDFワークフローが、今までのPostScriptワークフローでは解決できないこれらの問題に対して、有効だと考えているからでしょう。PDFワークフローを正しく運用できれば、制作側にも出力側にも負担が少なく、かつ今までより多彩な展開が可能になるといいます。私も大まかな方向性についてはそれに賛成しますし、おそらく業界の進んでいる方向もPDFワークフローです。
先に書いたようにIllustratorでしか出力データを作れない人が増えています。そこからPDF/Xなどを作成できるくらいの知識を持っていてくれれば問題は無いのでしょうが、そうではなくただ習慣でEPSでファイルを作成しているという方は、ぜひ自分のワークフローをもう一度振り返り、うやむやな理解でやり過ごしている部分を勉強し直してみてほしいと思うのです。そしてMacOSXやInDesignやOpenTypeフォントやPDFワークフローなど、新しい技術を試してみてほしいのです。
無理に新しい技術に乗り換えろということではありません。新しい技術を勉強することで自分の今のワークフローを客観的に評価することができるようになろう、と言いたいのです。
EPSとは？という本題から逸れてしまうのでこれくらいで。EPSとはどういうファイル・フォーマットなのかということの要点をこの至らない文章で掴んでもらえるか疑問ではありますが、このあたりで締めようと思います。
この文章への質問や問題提起は大歓迎です、全部に応えられるかはわかりませんが。必要と考えればもしかしたら再度取り上げ直すかもしれません。DTPにおいてのEPSというファイル・フォーマットの存在意義は、簡単に説明できるものではないと書きながらあらためて思い知らされました。
（前回より続く）
さて、あらためて、PostScriptとは何なのか。
実は書いている私もPostScriptを完全に理解しているわけではありませんm(__)m
なのでここでは実務上差し支えない程度のレベルに必要な初歩的な理解を目標に書いています。
物を理解するにはまずその物の作成者自身が書いた解説を読むのが基本でしょうが、PostScripの開発元であるアドビシステムズから出ている公式リファレンスマニュアルの日本語版は総ページ数が約900ページあり、初心者にいきなり買って読めと言ってもあまり効果的ではないでしょう。（私もリファレンスマニュアルの分厚さに恐れをなして買うのをやめてしまいましたし、おそらく買っても本棚の肥やしと化していたでしょう）
システム開発に携わろうという方にはこのリファレンスマニュアルは必携だと思いますが、ここではそれは置いておいて、まず感覚的にどう捉えておくのがよいかという視点で書きたいと思います。
あらためてWikipediaでPostScriptを参照してみると、EPSはファイル・フォーマットと説明されているのに対して、PostScriptはページ記述言語と書かれています。ページ記述言語とはプリンタなどで文字や画像を描画していくためのプログラミング言語のことです。
PostScriptは本来は特定のアプリケーションで編集過程で使われることを目的に開発されているわけではない、ということをまず覚えておきましょう。PostScriptとはファイル・フォーマットではなくページ記述言語であるという認識が「PostScriptという言葉が持つ意味を正確に掴む」第一歩だと私は思っています。
その認識であらためてDTPで使われるアプリケーションやファイル・フォーマットの役割を考察してみると、それらが持つ本来の意味がわかりやすく見えてくると思います。
EPSは本来はEncapsulated PostScript、つまりPostScriptにプレビュー画像等の情報を補ったものであり、本来は別のアプリケーションやメディアにデータを渡すためのファイル・フォーマットです。編集のためのネイティブ・フォーマットとしてはIllustratorならAI形式、PhotoshopであればPSD形式があります。EPSは別のアプリケーションで再編集されることは意図されていない、そのまま貼り込んで利用するのが前提、というのが重要なポイントです。
QuarkXPressやInDesignのようなレイアウト・ソフトではIllustratorやPhotoshopから書き出されたEPSを配置できますが、配置したEPSを直接編集するようにはできていません。これは先ほど述べたEPSファイルの特性を考えれば理解できると思います。IllustratorとPhotoshopだけでDTPの仕事をしているとレイアウト・ソフトの役割を忘れてしまいますが、IllustratorとPhotoshopでは部品を作りQuarkXPressやInDesignのようなレイアウト・ソフトで最終的にまとめる、というのが本来の役割でしょう。
「面付け」をレイアウトの一種と考えると、レイアウト・ソフトを面付け作業に使うというアイディアも浮かんでくるでしょう。事実QuarkXPressは多くの印刷業者、製版業者が面付けソフトとして使っていましたし、現在でも現役で使われていることが少なくありません。そこでなぜIllustratorが使われないかというと、Illustratorは編集するためのソフトであるためにEPSの扱い方がレイアウト・ソフトよりも出力作業に向いていないのです。（MM岩手さんから面白いサンプルを教えていただきましたので続きで紹介します）
繰り返しますが、EPSファイルは別のアプリケーションやメディアにデータを渡すためのファイル・フォーマットですから、それを利用する側のアプリケーションでは手を加えないのが基本です。
では次回にEPSをIllustratorのネイティブ・ファイルのように錯覚する弊害について書こうと思います。
（次回に続く）