出力の手引きWebのはてなブックマーク数
ホーム > 出力の手引きWeb > 解説追加|このエントリーを含むはてなブックマーク

出力の手引きWeb[解説追加]

前へ1 2 3 4 5 6 7 8次へ

2010年03月26日 | 白ノセ取り込み設定も万全ではない

興味深い現象ですが、役には立たないかもしれません…
auto_op.png■概要
Trueflowでは自動墨ノセ機能だけでなく、間違いの多い白ノセを取り込むかどうか設定できる機能があります。
しかし、この白ノセの取り込み設定もRIP上でデータを書き換えており、条件によって期待通り動作しない場合があるのは、以前の記事「「白ノセ」トラブルを解決する(2)」でも紹介した通りで、この機能も、間違った入力データに対処するための最後の手段であり、万全な対応ではない事を知っておく必要があります。
ここでは、もう一つの事例を紹介します。白ノセ指定された様に見えるデータをTrueflowで「白色のオーバープリントを取り込む」設定にチェックを入れて処理をします。この場合、理論的には白ノセのオブジェクトが消えて出力されると考えられますが、実際には消えずに白いオブジェクトが見える状態で出力されるケースがあります。

swatch.png■実例
この事例の最初のきっかけは、意図的に変な設定をしたところから始まります。
1) スウォッチの作成
再現するためには、Illustrator(CS4で試しています)のスウォッチで、CMYK全ての色値を0.003等の数値を入力します。この時、別のフィールドを入力しようとすると、表示上「0」に戻りますが、気にせずに4色とも入力します。(実験では、こういう事をする場合があります…)
この時に、見た目「0」に戻っているので入力できていないように見えますが、内部的には設定されている様です。
op_preview.png2) データへの適応
Illustratorでこのスウォッチを用いて色指定を行い、さらにそのオブジェクトにオーバープリント設定をします。
この時、あの意味の分からない警告ダイアログは表示されません。
しかし、オーバープリントプレビューで確認すると、確かにそのオブジェクトは白ノセの原理の通り消えて見えます。
このデータをEPS形式で書き出します。
3) InDesignへの配置
上記で作成したIllustratorEPSをInDesignに配置します。
この時、InDesignでのオーバープリントプレビューでも、該当オブジェクトは消えて見えます。他のオブジェクトの条件によっては白く見える場合もあります。
ここから、Trueflowの推奨設定でPostScript出力をします。
Acrobat.png4) PDFの作成と表示
上記で作成されたPostScriptからDistiller(Distiller 9で試しています)を用いてPDF/X-1a形式で作成し、Acrobat 9で表示します。
そうすると、該当部分の白ノセが消えずに、白く見えます。
つまり、IllustratorやInDesignでのオーバープリントプレビューとは異なる表示になり、Trueflow(最新PDF処理で試しました)でもAcrobatでの表示と同じ処理結果になります。


■発生条件
発生条件は以下の通りです。
・Illustratorのスウォッチで、見えない0.003%などの値を設定する
・IllustratorからEPS出力
・InDesignからTrueflowの推奨設定でPostScript書き出し

ObjectInspector.png■発生原理
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月24日 | 自動墨ノセは万全ではない

■概要
auto_op.pngTrueflowでは「自動オーバープリント設定」として、平網や文字がK=100%のみの場合、そのオブジェクトをオーバープリントとして出力する事ができます。
この処理は、入力されたデータ上でオーバープリントがOffの場合でも、そのデータを書き換えてオーバープリントOnとして演算します。
しかし、この機能は入力データの状態によって、期待通り出力されない場合があります。
この様な、RIP上でのデータの書き換えは、間違った入力データに対処するための最後の手段であり、万全な対応ではない事を知っておく必要があります。

sample_ai.png■実例
以下の手順で作成されたEPSは、Trueflowで「自動オーバープリント設定」を用いても、墨ベタ部分は下のグラデーションに対してオーバープリントになりません。
1) Illustrator(10~CS4)で右図の様なデータを作成します。
2) オブジェクトの重なりは、下からグラデーション、墨ベタ、画像の順で、僅かに墨ベタと画像が重なってします。(ここがミソ)
3) 墨ベタの部分の下にはグラデーションがあります。
4) ここで使用する画像は、この記事の手順で作成した(必要のない透明が含まれた)Photoshopネイティブです。
5) このデータをEPS保存します。

■発生条件
発生条件は以下の通りです。
・グラデーションや画像の上部に墨ベタの平網がある
・その平網に影響する透明オブジェクトがある
・EPS形式で保存する(Illustratorで透明の分割統合処理を行う)
・Trueflowの「自動オーバープリント設定」で墨ベタをノセに

sample2_ai.png■発生原理
データ上で、どの様な事が発生しているのでしょうか?
発生条件を満たす、もう少し単純なデータで確認してみます。
右図の様なデータでもEPS形式で保存すれば条件を満たします。
以下の手順で発生原理を確認します。
1) このEPSをDistillerでPDFに変換し、Acrobatで開く
2) AcrobatのTouchUpオブジェクトツールで墨ベタの部分を削除
・この手順で確認すると、右図のように墨ベタの部分にグラデーションがなく、白く抜けており、上部の墨ベタ部分にオーバープリント属性を加えても、下部のグラデーションとは合成されません。
・もし、この墨ベタ部分に透明オブジェクトが関係していなければ(右下図参照)、TouchUpオブジェクトツールを用いて削除しても、その下にグラデーションが存在しているので、墨ベタの部分にオーバープリント属性を加えると期待通り墨ノセになります。
・TouchUpオブジェクトツールで墨ベタを消去して見える部分は、あくまでもデータ上そのオブジェクトがあることを確認しているだけで、実際に出力されるかどうかは、墨ベタのノセ、ケヌキ設定に依存します。
・つまり、このデータを、RIP側でデータ通り(つまりケヌキで)出力すると、演算結果として、この部分にはグラデーションは描画されません。

sample3_ai.png■まとめと回避策
つまりIllustratorのEPS出力で行われる透明の分割統合では、データ通り、つまりケヌキであることを解釈して、分割統合を行う為に、下のグラデーションの部分が抜けています。(つまりRIP演算の一部をケヌキ前提で済ませている訳です)
RIPでデータの書き換えを行わない場合、この部分はケヌキで出せばいいので、EPSの記述内容には問題ありません。
しかし、RIP側でデータを書き換えて、間違ったデータを期待通り出力しようとしても、データの時点でオーバープリントの対象となるオブジェクトがないので、期待通りにはなりません。

上記のダッキーの例の様に、オーバープリントになるべきオブジェクトに、透明が関係していることが簡単に発見できない場合もあります。
以下の回避方法によって、この問題を確実に防ぐことができます。

・正しくオーバープリント設定を行い、データ通り出力する
・aiネイティブやPDF/X-4など、透明を活かした出力を行う

[第13版] [オーバープリント] [透明効果] [Illustrator] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2010年01月15日 | Adobe PDF Print Engineでのオーバープリント(2) - 技術詳細

<ご注意>OPMの概念は、PDFの技術情報の中でもかなり難解な部類であり、オーバープリントの挙動を完全に理解したい方向けの情報となります。

■従来演算系でもPDFの規格通りに処理を行う
TF_opm.png以前の記事「Adobe PDF Print Engineでのオーバープリント(1) - 概要」では、従来演算系とAdobe PDF Print Engineを使用した最新演算系では結果が異なると説明していましたが、設定を変更することで、その処理をPDFの規格通りに合わせることが可能です。
Trueflowには「オーバープリントモード」という設定(詳細はTrueflow出力の手引き 第13版P30~P31参照)があります。この設定で「PDFのオーバープリントに準拠する」を選択すると、従来演算系であっても以前の記事で説明したPDFの規格通りの出力結果を得ることができます。
この設定は、従来の演算結果との互換性の観点から、デフォルトでは従来通りの(4つの例外のない)オーバープリント処理を行う設定「システム設定を使用する」になっています。

■DeviceGrayについて
Trueflowの最新演算処理では、DeviceGrayのオブジェクトにオーバープリントが設定されていても、ノセにはなりません。これもAcrobatでの表示と同じです。
また、Trueflowの従来演算系では、DeviceGrayの対するオーバープリントを処理します。これも、他の3種類のオブジェクトと同じです。この挙動も、Trueflowの「オーバープリントモード」の設定を「PDFのオーバープリントに準拠する」に設定しておくと、Acrobatでの表示と同じ出力結果を得ることができます。
ただし、DeviceGray 0%、つまり印刷的には墨100%のデータを、最新演算処理でオーバープリントにしたい場合は、上記仕様の通り、単純にオーバープリント指定をしてもノセにはなりませんので注意が必要です。とりあえず、Trueflowの「自動オーバープリント設定」を利用すれば最新演算処理でもDeviceGrayによる墨ベタをノセにすることができますが、これはPDFの書き換えて実現しているので、汎用性のつまり、元のPDFを他のRIPで処理した場合には同じ結果にならないという観点からあまりオススメできません。
DeviceGrayは最近のDTPアプリケーションでは、ほとんど使用されません。
確実な墨ノセ指定のためにはDeviceGrayへの「自動オーバープリント設定」を期待するのではなく、DeviceCMYKやDeviceN、Separationなどのインキを前提とした色空間でオーバープリント設定する事を推奨します。この指定により、演算系に関わらず確実な墨ノセ処理が行われます。
QuarkXPress 8のPDF書き出しでは、出力のカラースペースを明示的に指定できるので、DeviceGrayのみで記述されたPDFを作成することもできますが、推奨設定ではありません。

OPM-2.png■OPMとの関連
上記のDeviceGrayを除く、この3種類のオブジェクトに設定されたオーバープリントの処理は、これらのオブジェクトがDeviceCMYKで定義されている場合が前提になっています。
OPMについて説明した「オーバープリントを正しく理解する(3) - OPM」の記事にも「DeviceCMYKのオーバープリントの挙動を変えるOPM」とあるように、DeviceCMYKのオーバープリントだけは「版が0%であるかどうか」に基づいて処理が行われます。この動作が一般的な/OPM 1の場合の処理になります。
つまり、/OPM 0の場合は、この4種類のオブジェクトに限らず、全てのDeviceCMYKのオブジェクトに設定されたオーバープリントは対象がプロセスカラーの場合、有効ではありません。

APPE_op_DevN.png■特色オブジェクトが対象の場合
この3種類のオブジェクトがDeviceCMYKでオーバープリントが設定されていても、その下部にあるオーバープリントの対象となるオブジェクトが、特色のオブジェクトの場合はノセになります。
特色オブジェクトとは、特色がSeparation色空間やDeviceNで定義されている場合つまり予約語は使用されていない場合を差します。
この特色は、明らかにDeviceCMYKとは「版」が異なるので、オーバープリントが設定された場合に、単純にノセになります。これは、上記の条件から、この3種類のオブジェクトの例外や、OPMにも関係なく、ノセになります。
つまり、この3種のオブジェクトの例外は、あくまでもプロセスカラーどうしのオーバープリントにのみ影響を与えます。

■オブジェクトがDeviceCMYKでない場合
プロセスカラーどうしであっても、オーバープリント指定されたこの3種類のオブジェクトがDeviceNで必要な版のみが指定されている場合は、以前の記事「Adobe PDF Print Engineでのオーバープリント(1) - 概要」で図示したような例であっても、グラデーションや画像オブジェクトをDeviceNで定義する事で、OPMの設定やTrueflowの演算系の新旧に関わらず、ノセになります。
右図はグラデーションの例ですが、画像であるダッキーの例では、あえてCyan成分が全くない画像にオーバープリント指定すると、従来演算系で背景のCyanが透けて見えますが、画像がDeviceCMYKではなくDeviceNで記述されれば、最新演算系でも透けて見えます。

PreSepa.png

■歴史的背景
グラデーション(シェーディング)、パターン、画像、DeviceGrayなどに設定されたオーバープリントの処理については、PostScriptでは厳密に決められていませんでした。
「正しい出力とは何か」を考える上では、画面上の表示が、実際の印刷結果と一致するのが好ましいのですが、当時のDTPアプリケーションでは、オーバープリントプレビューができなかったり(今もQuarkXPressはサポートしていません)、印刷結果の方もアプリケーション側で分版するプリセパレーション運用が主流であったために、それらの出力を予測する事は困難で、「正しい出力」の定義も曖昧でした。
「オーバープリント」とは、分版の方法を定義する記述なので、DTPアプリケーション側で分版するプリセパレーション運用では、オーバープリントの挙動もDTPアプリケーションの実装で決まってしまいます。
その状況において、当時からIn-RIPセパレーション運用を推奨していたTrueflowでは、オーバープリント設定されたものは、設定通り極力ノセる仕様になっていました。
一方では間違ったオーバープリント設定されたデータも多かったので、オーバープリント設定を無視したり、自動的に墨ノセにする運用が良く行われていました。
今では、DTPアプリケーション側ではオーバープリントプレビューが実装され、PDFの規格で厳密な挙動も定義されたので、画面で見た通り、Acrobatでの表示通りに出力する事が可能になってきました。
例えば、従来のPostScript運用ではDeviceCMYKの0%の解釈が曖昧で、アプリケーションやRIPで結果が異なる問題を解決するために、PDFではOPMというフラグで厳密に定義されました。
今は、オーバープリントを正しく取り込んで、「自動オーバープリント設定」を使わない運用をおすすめしています。

※AD-810MXはIn-RIPセパレーションもサポートしています。

このあと、
Adobe PDF Print Engineでのオーバープリント(3) - DTPアプリケーションの挙動
Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事
に続きます。

[第13版] [オーバープリント] [Acrobat] [Illustrator] [InDesign] [QuarkXPress] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2010年01月13日 | Adobe PDF Print Engineでのオーバープリント(1) - 概要

グラデーション、パターン、画像などに、デザインとしてオーバープリントを設定される事は稀かも知れませんが、これらのオブジェクトにオーバープリントが設定された場合、従来のPostScript運用とPDF運用では、処理の違いがあります。
ほとんどの運用ではその違いが問題になる事は少ないと思われますが、PDFにおけるオーバープリントの仕様について、正確に理解しておく事は重要です。

このあと、詳細な解説が続きますが、「Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事」で結論をまとめています。

■関連記事(あらかじめ読んでおいてください)
Trueflow出力の手引き 第13版 P27~P31 「オーバープリントモード」
DeviceNを理解する
オーバープリントを正しく理解する
オーバープリントを正しく理解する(2) - DeviceNの影響
オーバープリントを正しく理解する(3) - OPM

APPE_op.png■オーバープリント処理の例外について
以下のオブジェクトにオーバープリント指定された場合で、かつ下部のオブジェクトもプロセスカラーの場合、オーバープリント属性が設定されていても、PDFの規格上ノセにならない事になっています。
・グラデーション(DeviceCMYKで指定された)
・パターン(DeviceCMYKで指定された)
・画像(DeviceCMYKで指定された)
・DeviceGrayのオブジェクト
Acrobatでの表示も規格通り、これらのオブジェクトはノセになりません。
PostScriptの規格では、これらのオブジェクトについては厳密に規定されておらず、RIPによって処理結果が異なっていました。例えば、TrueflowのAdobe PDF Print Engineではない従来演算系では、仕様上これら全てのオブジェクトのオーバープリントは処理されます。
これは従来演算系にPostScriptを入力した場合も、PDFを入力した場合も同じロジックで演算されるので、入力データがPDFでも同じ結果つまりオーバープリント処理になります。
言い換えると、これらのオブジェクトにオーバープリントが設定されていると、その(PostScriptの場合はそれをDistiller で変換した)PDFのAcrobatでの表示とは、結果が異なる事になります。

■Adobe PDF Print Engineでのオーバープリント(Trueflowの場合)
Trueflowの従来演算系では、これらのオブジェクトのオーバープリント処理結果は、Acrobatとは異なっていましたが、Adobe PDF Print Engine(Trueflowでの最新演算処理系)での処理はあくまでもAcrobatと同じ結果になるように、つまり規格通り演算されます。
間もなくリリースされるTrueflow SE Ver7.10では、いよいよ最新演算処理ルートでもPostScriptを入力することができるようになりますが、これら4種類のオーバープリント処理に関しても、従来とは異なり、PDFの規格通り演算されます。
この処理により、それらのPostScriptをDistillerで変換したPDFのAcrobatでの表示と一致するようになります。
つまり、同じデータでも、これらのオブジェクトのオーバープリント処理結果は、Trueflowの従来演算系と、最新演算系では異なる事になりますので、注意が必要です。

■まとめ
重要なことは、実際のデザインにおいて、グラデーション、パターン、画像、DeviceGray等のオブジェクトにオーバープリント指定される可能性は低いと思われることです。
また、データ制作時においても、この様な本来の目的からは外れたようなオーバープリント指定したくなる場合は、その代わりに透明効果を用いて同様のデザインが得られるようにデザインすることで、間違いのない出力が得られます。

このあと、
Adobe PDF Print Engineでのオーバープリント(2) - 技術詳細
Adobe PDF Print Engineでのオーバープリント(3) - DTPアプリケーションの挙動
Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事
と続きます。

[第13版] [オーバープリント] [Acrobat] [Illustrator] [InDesign] [QuarkXPress] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年12月22日 | 特色名の予約語とQuarkXPressの問題

■特色名には予約語を使用しない
以前の記事「DeviceNを理解する」では、特色名に予約語があることを説明しました。これはDeviceNを構成する各々の色名(以後「構成要素」と書きます)としての予約語の説明でした。例えばDeviceNの一つの色名が「(特色)Black」と書かれた場合はプロセスカラーのBlackと解釈されます。
つまり、DeviceNは特色とプロセスカラーや、複数の特色を混ぜる場合に良く使用され、その構成要素してプロセスカラーの予約語は使用できます。できないとプロセスカラーと混ぜる事ができません…

DeviceN.gif

swatch.pngしかし、例えばスウォッチ上の特色名、一つの色として定義された特色名としては、予約語は使うべきではありません。
予約語としては「Cyan」「Magenta」「Yellow」「Black」の他に、レジストレーションで使用される「All」と、何も描画しないという意味の「None」(ナン)が挙げられます。

Trueflowでは、それ以外にも例えば「イエロー」(半角カタカナの場合も含めて)「Hexachrome Yellow」「Gelb」(ドイツ語)なども予約語として扱っています。特色名の取り扱いについては、各々のシステムによって、拡張されていたり、使ってはいけない文字(記号など)が異なる場合などがあり、注意が必要です。

Quark-all.png■DeviceNの構成要素で「All」や「None」は使用しない
上記では、DeviceNの構成要素してプロセスカラーの予約語は使用できる、と書きましたが、同じ予約語でも「All」と「None」は使ってはいけません。
これに関して、QuarkXPress 6.x, 8.xのPDF出力において、以下の問題が発見されました。TrueflowではQuarkXPress 6.xのPDF出力はサポートしていません。

QuarkXPressでは、特色名として予約語である「All」や「None」といった色名を使うことができてしまいます。
しかし、DeviceN出力のサポートされたQuarkXPress 6以降では、この様な特色が定義され、PDF出力すると、DeviceNの構成要素として「All」や「None」を定義してしまいます。
これらの予約語の色は、他の色と合成されても意味がないので、1色のDeviceNとして定義されます。
本来のPDF/PostScriptの仕様では、この2つの予約語の色は(1色のカラーを定義する)Separation(分離)カラースペースでのみ記述が認められています。
DeviceN-none.pngQuarkXPress 6.x, 8.xの場合は、本来Separation(分離)カラースペースで記述されるべき「All」や「None」が、DeviceNの構成要素として記述されるため、Acorbat8,9では右下図の様なエラーが表示され、Adobe PDF Print Engineの処理でもエラーになります。
error-dialog.png
色名が「None」の場合のメッセージは「ページ処理中にエラーが発生しました。オペランドの種類が正しくありません。」になります。厳密には、「None」は禁止されているわけではありませんが、DeviceNの構成要素として「None」つまり「描画しない」は適切ではありません、というメッセージです。エラーになり使ってはいけないことに変わりありません。
また、古いAcrobatの表示やTrueflowの従来演算では正常に処理できてしまいます。

やはり、特色名に予約語を使用すべきではなく、予約語以外の色名に変更することで、この問題は回避できます。
もちろんプロセスカラーへの変換が前提の特色指定も絶対にやめましょう。

ai-dialog.png■AdobeCS系の場合
ちなみにAdobeCS系のアプリケーションでは、右図の様なダイアログが出て、予約語の特色設定をする事はできなくなっています。

[第13版] [DeviceN] [特色指定] [Acrobat] [QuarkXPress] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年11月05日 | InDesignに効果付きデータを配置(2) - 発生原理、解説

<2010年7月27日追記>
この問題はTrueflow側での対策が完了しています。
詳細は記事「2010年07月27日|7つの問題の対策、完了しました」を参照してください。

先ほどの記事「InDesignに効果付きデータを配置(1) - 発生条件、回避策」の続きです。

■発生原理
前の記事では、発生条件として、「特定の効果が使用された場合に発生する」となっていました。
しかし、これは表面的な条件であって、根本には「画像に不透明度0%が指定され、背面に透明オブジェクト+不透明オブジェクトが存在する」という条件があります。(UI表記としては「透明度」100%の方が分かりやすいと思いますが…)
例えば、ダッキーの画像を切り抜いて、Illustratorに配置して、通常の透明の不透明度0%に設定すると、消えてしまいます。
本来の期待される出力としては、消えたまま出力されるべきなのですが、実際には画像ボックスの形状で背面の透明オブジェクトが抜けてしまいます。この挙動が、今回の問題の根本原因です。
sample2-workflow.png
この場合は、画像全体が矩形で不透明度0%が指定されている事になり、この矩形で背面の透明オブジェクトが抜けています。
実際には、画像に通常の透明として不透明度0%を指定すると、全く消えてしまうので、あまりその様な指定が行われる事はないと言えるでしょう。
しかし、前の記事のサンプルにある「光彩(外側)」は実際に使用されることのある効果の1つです。
この「光彩(外側)」で付加される効果は、下図(左)の様な画像が透明で合成されます。この場合、画像に応じて透明度が変化するソフトマスク(SMask)で記述されます。
この様なSMaskが使用される場合、対象となる画像の一部に対して、不透明度0%の指定になります。このサンプルの場合、下図(右)のハッチングの部分が不透明度0%の領域になります。
SMask.png
ここで先ほどと同じ様に、この不透明度0%の領域前の記事のサンプルの画像に適応すると、同様にその領域の背面の透明オブジェクトが抜け、同じ原理で発生していることが説明できます。
SMask2.png

■回避方法について
おもてには見えない発生条件がもう一つあります。
この条件が合致しないと今回の問題は発生せず、正常に処理できます。
isolated.pngこの問題は、IllustratorのデータからそのままPDF出力した場合は発生せず、InDesignに配置した場合にのみ発生します。
配置された場合、PDFの記述にはどの様な変化があるのでしょう?
これは、InDesignにIllustratorネイティブを配置する際の「背景を透明に」の設定がOffの場合には、PDF上にそのIllustratorデータ全体に対してのグループキーとして、「描画モードを分離」(Isolated Group)がtrueに設定されます。
本来であれば、このIllustratorデータ全体に対して、「描画モードを分離」することにより、背面のInDesignオブジェクトの影響を受けることなく、Illustratorの描画部品にのみ影響する透明グループとして処理されることにより、背景を不透明として処理することができるのですが、この処理の誤動作がもう一つの発生条件になっているようです。
回避策として有効である、この「背景を透明に」の設定がOnの場合は、Illustratorデータ自体がグループ化されず、出力されるPDF上では、あたかもInDesignのオブジェクトの様に記述されます。だからといって、InDesign上で編集できるわけではなく、あくまでも出力PDF上での記述の話です。
つまり、グループ化さえされていないので、このIllustratorデータに対するIsolated Groupの記述も存在しないことになり、今回の問題は回避できることになります。

■最後に
今回の問題は、全ての条件が完全に解明されたわけではありません。最終的には今回の条件に該当するデータのカンプ出力をTrueflowを用いて、事前確認を行って頂く事を推奨いたします。
この件に関して、新しい情報が分かり次第、このサイトからお知らせいたします。

[第13版] [透明効果] [Acrobat] [Photoshop] [Illustrator] [InDesign] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年09月10日 | PDF運用での重要な3つの留意事項

現状、PDF運用で留意が必要な3つの問題について、まとめました。
PDF運用であれば、データの制作において以下の3つの事例に関して、該当データを避けたり、回避策を講じることで、これだけが全てではありませんが、相当数のトラブル発生を未然予防することができます。
以下に、発生条件、回避策を記載した以前の記事へのリンクがありますのでもう一度参照してみてください。

1) InDesignCS2~CS4での合成フォントの問題(1)(2)(Adobe情報)
【発生条件】
acrobat7_2.pngtable1-1.png
ここでの「○」はInDesignの表示と出力が一致するという意味です。
【概要】
この問題は、InDesignCS2~CS4で発生する問題で、同じ事をIllustratorで行っても発生しません。

2) 縦書き文字で文字が欠ける問題(1)(2)(3)(Adobe情報)
【発生条件】
Acrobat9_2.pngTable2.png
【概要】
この問題は、InDesignCS4だけでなく、IllustratorCS4、PhotoshopCS4、Acrobat 9などの全てのアプリケーションで再現する共通の問題です。Adobe CS3シリーズ以前やAcrobat 8以前では問題ありません。

3) InDesignCS3/4の「効果」で出力が不正になる(1)(2)(Adobe情報)
【発生条件】
InD_effect_2.pngTable3.png
(*1) AcrobatはTouchUpオブジェクトツールでNG
(*2) Trueflow従来演算では、Polished Inputを使った場合のみNG、通常入力ではOK

【概要】
この問題はInDesignCS3から新たにサポートされた「効果」機能で発生する問題で、Acrobatの表示では問題が見つからない未然予防の難しい問題です。ただし、再現条件や回避方法は明確になっていますので、詳細は以前の記事を参照してください。


この記事、空白が多いのはなぜでしょうか?

[第13版] [透明効果] [Illustrator] [InDesign] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年08月13日 | QuarkXPress 8.1リリース(3) - その他の改良点と留意事項

QuarkXPress 8.1における当社で確認した改良点および留意点には以下の様なものがあります。

■ページ原点のPostScript記述の追加
以前の記事「QuarkXPress 8のPostScript対応リリース延期」で説明していたように、TrueflowではQuarkXPressが出力するPostScriptからページ原点(仕上がりサイズ:TrimBox、裁ち落としサイズ:BleedBox)を求める際に、そのトンボ記述を認識する方法をとっていました。この方法の欠点として、QuarkXPressのトンボ記述のパターンが変わるとTrueflow側でもそれに応じた対応が必要でした。
このQuarkXPress 8.1では、それを改善するためにTrimBoxやBleedBoxの値をPostScriptのpdfmark(pdfmarkの説明はコチラ)という命令で記述されるようになっています。この修正により、トンボの記述パターンに変更があっても、処理系の修正の必要なしに対応できることが可能になります。
この修正に併せて、従来のパターン認識が反応しないように、僅かにトンボの記述パターンも変更されています。

■Illustrator ネイティブ貼り込みにおける「不透明マスク」の問題
Trueflow出力の手引き 第13版 P103に記載されている、Illustrator の「不透明マスク」機能を用いたデータが正常に出力できない問題について、「不透明マスク」が正常に出力できない原因は他にもありますが当社が確認していた以下の条件における問題は解決されています。
QuarkXPress 8.1までのバージョンでAIネイティブ形式を配置した場合において、Illustrator CS以前で作成した不透明マスクのオブジェクトが正しく出力できない場合がありました。この様なデータは、Illustrator CS2以上でOpen & Saveしただけでは修正できず、Illustrator CS2以上で不透明マスクを再設定する必要がありました。過去の記事「QuarkXPress 8における留意事項」にも同様の記載があります。
QuarkXPress 8.1ではIllustrator CS以前で作成された不透明マスクも正しく表示/出力されます。「不透明マスク」が要注意であることに変わりありませんが…

■Illustratorネイティブ更新時の問題
同じく「QuarkXPress 8における留意事項」に記載されている「Illustratorネイティブ更新時の問題」は残念ながら修正されていません。Mac OS XのFileVaultがOnの場合は、Illustratorネイティブ更新時にはファイル名を変えるなどして対策してください。以前の記事にも記載がありますが、回避方法は以下のいずれかの方法となります。
・FileVaultをOffにする。
・Illustratorネイティブ更新時にファイル名を変更する。
・更新時に別のディレクトリに移動する。
・更新時にQuarkXPressのプロジェクトを一旦閉じてから開き直してから画像の更新を行う。

■オンラインによるアクティブ化
QuarkXPress 8におけるオンラインアクティブ化は、インターネットにダイレクトに接続されている場合は問題ありませんが、Proxyサーバー経由の場合はhttp、httpsに対してport番号80で設定されている必要があり、それ以外の場合は正常にアクティブ化できません。Webサイト経由や電話などでのアクティブ化の手続きが必要です。


■出力スタイルファイルのアイコン
出力スタイルをファイルに書き出した時に、アイコンが付かなかった問題は修正されていますが、カラーセットアップを書き出した時のアイコンはまだ付きません。

■ウエルカムスクリーン
ウエルカムスクリーンに「期間限定のキャンペーン(~8/1)」などの8.0発売前の情報が表示されてしまう問題も、ネットワークさえつながっていれば修正されます。

[第13版] [QuarkXPress] [FAQ] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年07月31日 | 縦書き文字に透明効果で文字が欠ける問題 (3) - 注意事項

縦書き文字に透明効果で文字が欠ける問題」「縦書き文字に透明効果で文字が欠ける問題(2) - Adobe情報
のトラブルに関して、さらに注意事項があります。
Adobeのサポートデータベースでは、問題が発生しているPDFをInDesign CS4またはIllustrator CS4に配置した場合でも、同じ問題を確認できるつまり同じ問題が発生する、と書かれています。では、具体的にどの様な問題が発生するのでしょう?

■具体的な症状
この問題の本質は、PDFの記述には問題はなく、それをAcrobat 9が解釈して表示する部分に問題があると「縦書き文字に透明効果で文字が欠ける問題」で説明しました。
これが、InDesign CS4やIllustrator CS4にも同じ問題があると言うことになります。
言い換えるとこれらのアプリケーションがPDFを読み込んで解釈する時に、縦書きの透明とオーバープリントの設定によりPDF/X-1a出力の分割統合によって生成されたテキストクリップの位置を間違って解釈してしまいます。
その結果、InDesign CS4やIllustrator CS4の画面上の表示も文字が欠けた状態で表示されます。この時点で気付きましょう
その上、PDFの書き出し側には問題がないので、InDesign CS4やIllustrator CS4によって間違って解釈されたこのオブジェクトは、そのままあたかも元から文字が欠けたデザインであるかの様に取り扱われ保存されます。
この様な処理を行われた結果、そのInDesign CS4やIllustrator CS4ドキュメントから生成されたPDFはもちろんPostScriptでも、もはや処理系、つまりAcrobatのバージョンやRIPのバージョンに関わらず、文字が欠けた状態で出力されます。
読み込まれるアプリケーションがCS3系以前の場合では、解釈の問題はなく、仮に元のPDFがCS4系で作成されたものであっても、正常に表示/出力されます。
workflow.png

■出力における注意事項
この問題は、AcrobatだけでなくRIPのバージョンによっても出力結果が異なる事が考えられます。その様な場合、Acrobat 8以前では問題なく表示できていたPDFが、RIP演算の結果文字が欠けて出力されるという事故が発生する可能性があります。
Trueflow SEでは、最新演算系や従来演算系など処理系に関わらず問題なく出力できます。

■まとめ
上図のPDF(A),(B),(C)のそれぞれにおけるPDF処理系による演算結果を表にしました。
重要なことは、たとえ問題の発生しない処理系を用いても、CS4系アプリケーションでPDFを配置した場合、元のデータが書き換わってしまい、同様の問題が発生してしまうということです。
もし、縦書き文字に透明とオーバープリントの両方が設定されるようなデータの場合、データの作成方法や処理系の挙動を理解し対策する事で、正しい出力を得ることができます。
繰り返しになりますが、この問題はあくまでも「オーバープリント」+「透明」の両方が同時に指定された「縦書き」文字の場合にのみ発生する特異な問題であり、通常の使用におけるAcrobatの再現性について全面的に否定するものではありません。また、この問題の発生条件も回避方法も明確になっています。

table.png

[第13版] [透明効果] [Acrobat] [Illustrator] [InDesign] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

2009年07月15日 | 縦書き文字に透明効果で文字が欠ける問題(2) - Adobe情報

outline.png以前の記事「縦書き文字に透明効果で文字が欠ける問題」でお知らせした問題について、Adobeのサポートデータベースに「文章番号235814 縦書き文字に透明効果とオーバープリントが適用されているとAcrobat 9で文字が欠ける(Illustrator CS2-CS4/InDesign CS2-CS4)」が掲載されました。
この記事では、問題が発生しているPDFをInDesign CS4またはIllustrator CS4に配置した場合でも、同じ問題を確認できるつまり同じ問題が発生する、と説明しています。

<Acrobatによる出力の事前確認の推奨>
この問題はあくまでも「オーバープリント」+「透明」の両方が同時に指定された「縦書き」文字の場合にのみ発生する特異な問題であり、通常の使用におけるAcrobatの再現性について全面的に否定するものではありません。また、この問題の発生条件も回避方法も明確になっています。
OutlinePDFおよびOutlinePDF Advanceを含む全てのPDFを出力前に確認するためにAcrobatを用いる事は、事前の問題発見のために有効です。
Acrobatの表示は非常に高い精度で出力を再現しますが、いくつかのバージョンでは、まれに再現の違いがでることがあります。AcrobatでPDFを確認する際は、再現の違いがでる条件を把握した上で確認することが重要であり、この問題もその一つであると言えます。
これ以外に、PDFをAcrobatで確認する際に必要な留意事項として、以下の3点が確認されています。
InDesignCS2〜CS4での合成フォントの問題
→Acrobatでは正常に表示できていても、条件が合致すると問題が発生します。
InDesignCS3/4の「効果」で出力が不正になる
→Acrobatでの表示上では見えている効果が、条件が合致した場合、出力すると消えます。
AdobeCS系のカラー設定と透明効果
→「透明の変換用カラースペース」はAcrobatではシミュレーションされません。この問題を自動的に補正するTrueflowのパッチが適応されていないと、出力で問題が発生します。

[第13版] [透明効果] [Acrobat] [Illustrator] [InDesign] [お知らせ] [解説追加] | 固定リンクこの記事をメールで共有 このエントリーを含むはてなブックマーク

前へ1 2 3 4 5 6 7 8次へ

このページの先頭に戻る