出力の手引きWeb[Illustrator]
2012年04月23日 ｜ Adobe Creative Suite 6 (1) - 発表
Adobe Creative Suite 6 (1) - 発表
Adobe Creative Suite 6 (2) - 線にグラデーションを適応
Adobe Creative Suite 6 (3) - InDesignCS6の留意事項
Adobe Creative Suite 6 (4) - 評価結果報告
Adobe Creative Suite 6 (5) - サポート開始
Adobe Creative Suite 6 (6) - まとめ
■Adobe Creative Suite 6：2012年5月11日(金)発売 プレスリリース（PDF/618KByte）
新機能や特徴などは、Adobeのサイト情報をご参照下さい。
ここでは、出力に関係する情報と、当社の対応の予定をお伝えします。
特に、Adobe CS6に含まれるIllustrator CS6では出力に関係する新機能が追加されています。
当社ではアドビシステムズの協力のもと、早期にプレリリース版、正式製品版(GM版)を入手し、調査、検証を行っています。
本日より、順次出力に必要な技術情報をお知らせしていきます。
■EQUIOS / Trueflow出力の手引き(PDF版)でのサポート
今回のAdobe CS6でのリリースに際し、Trueflowの製品紹介ページで公開されている、PDF版の「EQUIOS / Trueflow出力の手引き 第15版」および、出力に必要な設定ファイルが入っている「Trueflow印刷ユーティリティ2.6」の更新の予定はありません。
以下のIllustrator CS6によるPDF/X-4:2010対応の設定ファイルに関する解説を追加するだけで、基本的に同じ手順、同じ留意事項、同じ設定で、EQUIOSやTrueflowでの出力対応ができる様になる予定です。
■Adobe Illustrator CS6 - PDF/X-4:2010のサポート
InDesign CS5.5で先行していたPDF/X-4:2010（PDF1.6ベース）が、Illustrator CS6でもサポートされました。
この変更により、InDesign CS6 / Illustrator CS6共に「Trueflow PDFX4 1.4J.joboptions」をお使い頂く事になります。
出力的にはドキッとするパッケージデザインです…
次回、「線にグラデーションを適応」出力への影響は？を予定しています。
[第15版] [Illustrator] [解説追加] ｜ 固定リンク｜
2011年04月19日 ｜ Adobe PDF Print Engineでのオーバープリント(6) - 番外編：DeviceGray
前の記事
「Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例」
の補足です。
この記事は全て従来処理系の内部の処理について言及していますが、出力結果は最新処理系と同じになります。
以下の事例2)について、さらに理解を深めるために2つの事例を紹介します。
前の記事の2)を引用します。
 2) 従来処理系なのにDeviceGrayのオーバープリントがヌキにTrueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。 ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。 |
2-1) DeviceGrayのオーバープリントがノセにならないといけないケース（Trueflowの従来処理系）上記では（PDFの規格に準じるとノセなくていいので）と説明しましたが、PDFの規格に準じるとDeviceGrayのオーバープリントがノセにならないといけないケースでは、どの様になるのでしょうか？
今までの全ての事例は下部のオブジェクトもプロセスカラーであることが条件です。もし、この例でも下部が特色でDeviceNやSeparationの場合、最新・従来に関わらずノセになる必要があります。
実際の出力結果も、右図の用に確かに元々DeviceGrayだった部分が（透明と同居しているにも関わらず）期待通りノセになります。
これはRIP内部の処理において、オーバープリントに対して、あたかも透明のような分割統合処理が行われています。基本的にDeviceGrayは（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYKに変換しますが、下部が特色の部分だけはノセる必要があるので、その部分を分割しDeviceCMYKのオーバープリントがOnに変換します。この単純な例では、DeviceGrayを分割せずにDeviceCMYKのノセに設定すれば良さそうですが、他のオブジェクトが絡んでくる事を考えると分割されるのが正解です
2-2) DeviceGrayの墨ベタで自動オーバープリントが効かないケース（Trueflowの従来処理系）
右図は、分かりやすくするために墨ベタを少し薄くしています
前の記事の最後に「DeviceGrayの墨ベタにも自動オーバープリントは効く」と書きました。確かに2)の例（下部が単純なDeviceCMYKの図形）で、もしDeviceGrayが墨ベタの場合は、分割は行われず、単にオーバープリントがOffに変換されるだけなので、その後の自動オーバープリントは効きます。
しかし、自動墨ノセは万全ではありません。
DeviceGrayで記述された墨ベタが、透明と同じページにあった場合、入力処理の分割統合処理において、DeviceCMYKの部品に対しては（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換されるまでは、上記2)と同じです。
しかし、下部のオブジェクトがグラデーションや画像の場合、分割統合の影響で重なっている部分が画像化されてしまいます。
この分割統合処理で生成された画像は、ノセなくていい前提で分割統合されているので、せっかく分割されたのに、グラデーションとは合成されておらず、単なる墨ベタの画像（トホホ…）になっています。
こうなってしまうと、テキストでも図形でも無いので、自動オーバープリントは効きません。
その上、下部のオブジェクトも欠けているのでどうしようもありません。
＜まとめ＞
・全ての例は、同じページ上に分割されていない透明オブジェクトがある場合に限ります。（つまりPDFのみ）
・Adobe CS3以降など推奨アプリケーションを使えば、この様なことを考える必要はありません。
2011年04月15日 ｜ Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例
以前の4つの記事
「Adobe PDF Print Engineでのオーバープリント(1) - 概要」
「Adobe PDF Print Engineでのオーバープリント(2) - 技術詳細」
「Adobe PDF Print Engineでのオーバープリント(3) - DTPアプリケーションの挙動」
「Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事」
では、基本的な事例を紹介しました。もう1年以上前ですね…
ここでは、その基本で説明した原理から外れる処理結果について、なぜ結果が異なる場合があるのか、技術的に説明します。
■結論「推奨アプリケーションではこの差違は発生しません」
・AdobeCS以降、QuarkXPress 6以降
オーバープリント処理の違いを意識する必要はほとんどありません
Acrobatのオーバープリントプレビュー通りの出力が得られます
・それよりも古いアプリケーション
オーバープリント処理の違いから出力を予測することが必要です
＜まとめ＞
不具合の要因(リンクで貼るとスジが出るなど)も考慮すると、特にAdobe CS 3以降、QuarkXPress 8以降を推奨します。詳細は、Trueflow出力の手引き 第14版P4「サポート DTP アプリケーション」を参照して下さい。
＜注意＞この記事は、特にIllustrator 10以前やInDesign 2.0.2以前、推奨設定を使用しないQuarkXPressを使用される場合にのみ必要な情報です。
■従来処理系と最新処理系の差違の基本
以下のオブジェクトにオーバープリント指定された場合で、かつ下部のオブジェクトもプロセスカラーの場合、オーバープリント属性が設定されていても、PDFの規格上ノセにならない事になっています。
・グラデーション(DeviceCMYKで指定された)
・パターン(DeviceCMYKで指定された)
・画像(DeviceCMYKで指定された)
・DeviceGrayのオブジェクト
Acrobatでの表示も規格通り、これらのオブジェクトはノセになりません。Trueflowでの出力結果は、基本的には以下の様になります。
・従来演算系：これらのオブジェクトのオーバープリントを処理
・最新演算系：PDFの規格通り、これらのオブジェクトはヌキに
これらの処理の違いから、同じデータをTrueflowの従来演算系と最新演算系の両方で処理した場合、出力結果の差違が表れます。上記、推奨アプリケーションでは、この差違は発生しませんし、デザインとしてもレアケースであること、DeviceGrayによる墨ベタにも自動オーバープリントは効くことを忘れないで下さい。
■基本通りにならない事例
以下の3つの事例は、本来の動作とは逆の結果になっていますが、それぞれ条件と技術的なロジック（理由）があります。
＜事例＞
1) 最新処理系なのに透明があるとDeviceGrayのオーバープリントがノセに
2) 従来処理系なのに透明があるとDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのに透明があるとDeviceCMYKのグラデーションのオーバープリントがヌキに
＜発生条件＞
・同じスプレッド内（ページ内）に透明オブジェクトが含まれている。
・透明オブジェクトと該当オーバープリントとの位置関係は問わない。
・同じスプレッド内（ページ内）に透明オブジェクトが無ければ基本通りの処理になる。
→つまり、同じ処理範囲内に透明オブジェクトがあると、位置的には全く関係のない場所のオーバープリントも含めて動作が基本通りになりません。同じ処理範囲内に透明があると、処理が変わる、ということになります。
＜発生ロジック＞
1) 最新処理系なのにDeviceGrayのオーバープリントがノセに
同じページに一つでも透明オブジェクトがあった場合、透明の処理による色の整合性を保つ（透明が関わるDeviceGrayと、透明が関わらないDeviceGrayの色の結果を合わせる）ため、全てのDeviceGrayオブジェクトはSeparation Blackに置き換える処理を行います。
この処理は、同じページ上であれば、透明との配置関係の有無に関わらず、印刷用の色空間であることを明確に示すSeparation Blackへの置き換えを、Trueflowの入力処理の内部で行います。
DeviceGrayは、DeviceRGBと同じく光の強さを示しており、DTPアプリケーション上グレースケール100%は「黒」ですが、PDFの記述上は0が「黒」、255が「白」になります。
その結果、ノセになります。
従って、同じページに透明オブジェクトが全く存在しない場合は、ヌキになります。
2) 従来処理系なのにDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのにDeviceCMYKのグラデーションのオーバープリントがヌキに
この2)と3)は同じ原理で説明できます。
Trueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。
ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。
DeviceCMYKのグラデーションも同じく（PDFの規格に準じるとノセなくていいので）オーバープリント設定はOffに変換されます。
逆に、同じページに透明オブジェクトが全く存在しない、などPDF1.3準拠のデータの場合、透明の分割統合処理も行われず、DeviceGrayやDeviceCMYKのグラデーションのオーバープリントオブジェクトは基本通りノセになります。
＜最後に＞くどい様ですが…
「結果は一致しない」事にのみ注目するのではなく、以下の項目を念頭に、「ほとんどの場合結果OK」と冷静に判断し、技術情報として正しく理解しておくことが重要です。
・全てAdobe CS3以降など推奨アプリケーションではこの差違は発生しない
・1)は、規格通りではないがオーバープリントがノセになる方向の違い
DeviceGrayになっている事に気付いていない事の方が多いので、ノセになるのが期待通りでは？
・2)は、DeviceGrayの墨ベタにも自動オーバープリントは効く
・3)は、ほとんどオペレーションミス（意図的にしたい場合は乗算の透明を使いましょう）
「最適な出力」とは、重箱のすみのギリギリの部分で、やむなく規格通りではない処理を行う事も含めて実現されます。今後も「最適な出力」を目指していきます。
2011年01月31日 ｜ 太らせた文字がかすれた様に出力される問題
■出力結果の例（拡大図）
■概要
文字の線幅を指定することで、文字を太らせるデザインを行った場合、RIPの演算結果、文字がかすれた様に出力される場合があります。この問題は低い解像度で、解像度に適さない線幅を指定した場合に発生する問題です。
■発生条件
・出力解像度が低い（この例では360dpi）
・文字の線幅を指定して、文字を太らせる
・この線幅が細い場合（この例では0.2pt）
→解像度が低く、線幅が細い結果、デバイス解像度で1ピクセルの線になる場合。
■回避策
・文字の線幅を指定する事で文字を太らせるのではなく、太い書体を用いる。
・文字に設定された線を太くする。（文字が潰れる弊害があります）
デザイン品質上の問題としても、文字の線幅を太らせる手法は、書体のバランスが失われ、文字が潰れるので、お勧めできません。
■発生原理
・文字はHINT情報により、図形の塗りつぶし (fill) の幅を一致させるために、調整されます。
・文字のアウトラインは、線幅補正機能（SA : stroke adjustment）により、線幅 (stroke) を一致させるために、調整されます。
・fillとstrokeが別々に調整（微細な移動）されることで、解像度が低い場合にstrokeとfillの間に隙間が現れます。
■HINT処理、線幅補正について（右図は概念で、実際の演算はもっと複雑です）
HINT処理や線幅補正処理は、文字や罫線の配置位置による統一性を保つために、理論的な配置位置を最大で0.5デバイスピクセル分移動します。
この移動により、実際の物理的な配置位置は1デバイスピクセル分の差違が出る場合があります。（実際には0.5ピクセルだけ塗ることはできないので、RIP演算時に丸められるから）
今回の線幅として指定された0.2ptは、360dpiではちょうど1ドットつまり1デバイスピクセル分しかありません。2400dpiだと0.2ptも7ドットで描画されます。
HINT処理や線幅保障処理によって、1デバイスピクセル移動した場合、2400dpiなら大きな影響はありませんが、1ドットしか描画されない360dpiでは大きな影響が出ることになります。
本来、HINT処理や線幅保障処理は、特に低い解像度で出力する場合に効果がありますが、360dpiでの出力において0.2ptの線幅を文字の周りにつける処理は、補正の限界を超えていると言えます。
2010年08月25日 ｜ Illustratorの「以前の形式」は推奨できません
Illustratorネイティブ形式や、Illustrator EPS形式で保存する場合に「以前の形式」で保存することができますが、この形式での運用は推奨できません。
「以前の形式」での保存というのは、以前のバージョンのIllustratorで開くことができるかも知れない形式であるに過ぎず、文字組みや新しいバージョンの機能に関わる効果が変化します。
また、それだけでなく、この「以前の形式」での保存に関わる修正が施される場合があり、過去のバージョンのIllustratorと完全に同じ出力が得られるとは限りません。
その修正の結果、より良い結果になる場合もそうじゃない場合もあるかも知れませんが、知らないうちに出力結果が変わる可能性のある運用は、印刷のワークフローとして好ましくありません。
これに起因する事故も現実に発生しています。
Trueflow出力の手引き 第14版 P6の「Illustratorデータ対応表」に基づいて、「以前の形式」は使用せず、常にそのバージョンが最新形式になる様な運用を行ってください。
2010年05月28日 ｜ 縦書き文字に透明効果で文字が欠ける問題 (4) - CS5で修正
以前の記事、「縦書き文字に透明効果で文字が欠ける問題 (3) - 注意事項」で、縦書き文字に透明とオーバープリントが同時に設定されると、以下の問題が発生することを説明していました。
(1) Acrobat 9で文字が欠ける。
(2) Trueflowでの出力は正常。
(3) InDesign CS4 / Illustrator CS4に貼り込むと文字が欠けたものとして「固定化」され、どのデバイスに出しても文字が欠けてしまう。
InDesign CS5 / Illustrator CS5では、上記(3)の問題が修正されています。
この問題、CS3以前でもOK、CS5でもOKなのに、CS4のみがNGなので、注意が必要です。
2010年05月28日 ｜ 意味が分かるようになったIllustratorCS5の警告
以前の記事でIllustratorの白ノセ指定時に表示される大きな警告*1の意味が分からない事を紹介しました。
*1大きな警告 「便利です。」って言われても…
しかしCS5の同じ警告*2では、意味が分かる様になりました。つまり…
・ホワイトのオブジェクトへのオーバープリントは期待通りにならない
・白色を透かせたい場合は、オーバープリントじゃなくて、透明を使って下さい
…という意味であることが分かります。
*2CS5の警告
そこまでするなら、指定できない様にすればいいのに…
[第14版] [オーバープリント] [Illustrator] ｜ 固定リンク｜ 
2010年03月31日 ｜ 文字に透明度グラデーションを使う
＜2010年7月27日追記＞
この問題はTrueflow側での対策が完了しています。
詳細は記事「2010年07月27日｜7つの問題の対策、完了しました」を参照してください。
■概要
Illustrator CS4を用いて、文字に透明度グラデーションを用いた場合、Acrobat 8以前では正しく表示されません。
■実例(右図は2つのセットアップを合成しています)
1) 右図の様に、文字を並べて、アピアランスから透明度グラデーションを設定
2) PDF/X-4など、透明の活きたPDF形式で保存する
3) Acrobat 8以前とAcrobat 9で表示を比較
■Trueflowでの処理結果
処理結果は以下の通りとなります。
*1最新演算(Adobe PDF Print Engine)で、入力データをPDF1.3に変換する設定
*2入構データのPDFバージョンを保持し透明を活かす設定 (推奨設定)
*3現在開発中のパッチで修正予定(時期未定ですが、このサイトにてお知らせ致します)
■再現条件
以下の全ての条件が揃った場合にこの問題が発生します。
・Illustrator CS4で文字属性の塗りに透明度グラデーションを使用する
・Trueflowの従来演算、PDF1.3化する最新演算、Acrobat 8以前での表示
・PDF/X-4など透明が活きたデータで書き出し
・文字列が2文字以上で、2文字目以降が結果不正
■まとめ
PDFの記述としては文字列にTextClipとsh（シェーディング）とSMask（ソフトマスク）が設定された場合に、2文字目以降で発生する問題となっていますが、現状のDTPアプリケーションにおいては、Illustrator CS4のアピアランスから塗りの属性として透明度グラデーションを使用した場合が該当します。
Trueflowでは最新演算系で処理を行えば、内部でPDF1.3化の処理が入らない限り問題は発生しません。
OutlinePDF-Adv.を作成する場合にもPDF1.3化をしなければ2サイト運用でも問題がありません。
TextClipは文字をアウトライン化せずに文字形状でClipする、というPostScriptにはない記述なため、その分割統合処理は何かと鬼門です。
分割統合処理の必要のないPDF/X-4 + Adobe PDF Print Engineなら全て問題ありません。
2010年03月26日 ｜ 白ノセ取り込み設定も万全ではない
興味深い現象ですが、役には立たないかもしれません…
■概要
Trueflowでは自動墨ノセ機能だけでなく、間違いの多い白ノセを取り込むかどうか設定できる機能があります。
しかし、この白ノセの取り込み設定もRIP上でデータを書き換えており、条件によって期待通り動作しない場合があるのは、以前の記事「「白ノセ」トラブルを解決する(2)」でも紹介した通りで、この機能も、間違った入力データに対処するための最後の手段であり、万全な対応ではない事を知っておく必要があります。
ここでは、もう一つの事例を紹介します。白ノセ指定された様に見えるデータをTrueflowで「白色のオーバープリントを取り込む」設定にチェックを入れて処理をします。この場合、理論的には白ノセのオブジェクトが消えて出力されると考えられますが、実際には消えずに白いオブジェクトが見える状態で出力されるケースがあります。
■実例
この事例の最初のきっかけは、意図的に変な設定をしたところから始まります。
1) スウォッチの作成
再現するためには、Illustrator(CS4で試しています)のスウォッチで、CMYK全ての色値を0.003等の数値を入力します。この時、別のフィールドを入力しようとすると、表示上「0」に戻りますが、気にせずに4色とも入力します。(実験では、こういう事をする場合があります…)
この時に、見た目「0」に戻っているので入力できていないように見えますが、内部的には設定されている様です。
2) データへの適応
Illustratorでこのスウォッチを用いて色指定を行い、さらにそのオブジェクトにオーバープリント設定をします。
この時、あの意味の分からない警告ダイアログは表示されません。
しかし、オーバープリントプレビューで確認すると、確かにそのオブジェクトは白ノセの原理の通り消えて見えます。
このデータをEPS形式で書き出します。
3) InDesignへの配置
上記で作成したIllustratorEPSをInDesignに配置します。
この時、InDesignでのオーバープリントプレビューでも、該当オブジェクトは消えて見えます。他のオブジェクトの条件によっては白く見える場合もあります。
ここから、Trueflowの推奨設定でPostScript出力をします。
4) PDFの作成と表示
上記で作成されたPostScriptからDistiller(Distiller 9で試しています)を用いてPDF/X-1a形式で作成し、Acrobat 9で表示します。
そうすると、該当部分の白ノセが消えずに、白く見えます。
つまり、IllustratorやInDesignでのオーバープリントプレビューとは異なる表示になり、Trueflow(最新PDF処理で試しました)でもAcrobatでの表示と同じ処理結果になります。
■発生条件
発生条件は以下の通りです。
・Illustratorのスウォッチで、見えない0.003%などの値を設定する
・IllustratorからEPS出力
・InDesignからTrueflowの推奨設定でPostScript書き出し
■発生原理
Acrobat 9のオブジェクトインスペクタで該当部分を見てみます。
・下の4つが本来は白ノセになるはずのオブジェクト
・1つのオブジェクトが4つのオブジェクトに分解されている
・すべて分離、つまりSeparationカラースペース
・色名がそれぞれBlack、Yellow、Magenta、Cyanとなっている
・4つのオブジェクトは全てオーバープリント設定されている
・全てカラー値は[0.00]が、ここでは有効桁数が足らないようです。
この状態で、白ノセの様なオブジェクトは見えるようになってしまいました。この原因は2つあります。
1) 色値が0ではない
実際は0.003という色値があるので、ノセにはならないのですが、このゼロ付近の色値については、最終的な丸め誤差によって、処理系によって0と見なされる場合もあり、これだけが原因とは言えません。
2) Separationカラースペースは「0%の色がある」
DeviceCMYKでは、0%のオーバープリントを透過と解釈していましたが、Separationカラースペースでは、DeviceNと同じ様に「0%の色がある」と解釈されるので、色値に関わらず透過にはなりません。
4版とも0%の色で描画されるため、白いオブジェクトが見える状態で出力されます。
■まとめと回避策
確かに、最初のスウォッチの設定で0.003などと設定するのは不自然ですが、一旦その様なスウォッチが設定されてしまうと、特別なツールでも使わない限りもう二度とその色値を確認する事はできず、しかもIllustratorやInDesignのオーバープリントプレビューでも、完全な白と同じ様な挙動を示すために、理論通りの結果にならない原因を発見することは困難です。
しかも、元のIllustratorのデータ一の一部の再利用などで使い回され、さらに特殊なスウォッチの存在は分からなくなります。
この4つのオブジェクトに分かれてSeparationカラースペースに変換される、という挙動は、微小な色値の入った白っぽい色が用いられた場合にのみ発生する様で、この分解を行っているのはInDesignでの最後のPostScript出力時です。
回避方法というか理論通りの結果を確認する方法としては以下の様な事が考えられます。
・スウォッチで微小な値を設定しない 試したとしても、試したことを忘れない
・Acrobatでのオーバープリントプレビューは、このデータを正しく表示できる
・IllustratorEPSを用いずにIllustratorネイティブを使用する 本来の推奨運用です
・InDesignからPostScript出力をせずに、PDFをダイレクトに出力する 本来の推奨運用です
白ノセが見えるようになるからと言って、絶対にこの様な設定を使ってはいけません。
[第13版] [オーバープリント] [Acrobat] [Illustrator] [InDesign] [解説追加] ｜ 固定リンク｜ 
2010年03月26日 ｜ 自動墨ノセは万全ではない（Adobe情報）
以前の記事「自動墨ノセは万全ではない」でお知らせした問題について、Adobeのサポートデータベースに「文章番号cpsid_82798 透明を使用した箇所がオーバープリントにならない（Illustrator CS-CS4）」が掲載されていました。
回避方法として、リッチブラックを用いる方法も紹介されています。
ケヌキのEPSとしては間違ってないのに、情報は公開するという姿勢は評価できます。
