自動スミノセが破綻している事例

RIPで自動スミノセ、もうおなじみのアレですが、Cをちょっと混ぜてノックアウトにしたりとか、バッドノウハウ感満載ですよね。まぁ仕方ないです、そういう前提でデータ作ります。狙い通り刷れればいいですからね。

よし、入稿完了。

は!? なんでK100なのにノックアウトになってるの!?(PDF校正)

これ、何かというと、印刷所によるラスタライズが原因です。

RIPにかける前に、PDF/X-1aをラスタライズしてInDesignに貼ってます。
ちょっと理解し難いですが、そういうフローで行う「ことがある」そうです。

パスが多いデザインデータや効果が多用されたデザインデータでご入稿の場合、使用ソフトに限らず弊社にて全体を画像化し進行することがございますので予めご了承ください。

こうなると、自動スミノセは、いっさいされません。
全部ノックアウトです。

逆に、こちらでオーバープリントを適切に設定し、ノセイキでラスタライズした画像を入稿するしかないようです。このケースでは600dpiのTIFFを作成して再入稿しました。

これって、入稿データの不備ですか?

ということで、ちょっとヤバイ、自動スミノセの破綻事例でした。勘弁してくれ……。


※ なお、ノセイキでラスタライズっての結構ムズカシイ

「いいね!」 1

事前通知しないのはEvilだ……

全部ノセイキで処理すれば、一貫したフローになると思うんですよ。
私はその方が嬉しいなw

印刷所で一貫性のない処理をしといて、データの不備とか言うのはマズイです。

一応、サイトに掲載された説明通りの処理をしているわけで、了解済みの事柄ではあります。
事故っても誰も責任負わないというアレな状況にはなりますが……。

そうしないこともあるって事ですかね、これ。絵に描いたような綺麗すぎるダブルスタンダード('A`)
どっちがでるか、当選の発表は製品の納品をもって代えさせていただく所存なのかしら。
ヒドス。

「いいね!」 1

パスor効果が多いと、ラスタライズされる前提でデータ作ることもできないしされない前提でも作れない。
辛い。

これ、究極的には、画像で入れるしかないんですよ。

X-1aにしてRIPに負担かけないようにしているつもりなんですが、まぁだから大丈夫というワケじゃないですしね。

逆に考えると、印刷所側でラスタライスする際に、自動スミノセがちゃんと行われればいいんだと思いますが、どうなんでしょうか? それなら最初からRIP使えよってなっちゃうかな……。

RIPがギブアップするようなデータをPC上のAdobeアプリで現実的な品質・時間でラスタライズできるのか、という疑問も……実際どの程度まで耐えられるんでしょうか?

とりあえず、この例のヤツはA2ポスターだったので、何も問題無く、かるーくラスタライズできました。

普段扱っているのはもっと大判なので、さすがにpsdで書き出せるピクセル数超えてたりして、メモリ不足って言ってギブアップするヤツが多いですね。分割して書き出して、psbにまとめる感じで……。

「いいね!」 1

@jdash2000 さんから、PDF/X-1aのラスタライズ部分も同じじゃね?って指摘をいただきました。

やってみようとしてもなかなか作例が作れない!

墨文字が画像に一体化されてしまえばノックアウト確定で自動スミノセできなくなるんですが、別々にラスタライズされるパターンしか作れない。どうやったら一体になりますかね……。

こういうノセイキでラスタライズなデータを作りたいってコトですか?

作例と事例、 @moriwaty さん、 @jdash2000 さんよりいただきました!

モリオさんにいただいた分、ドロップシャドウにかかっている部分の文字が、ラスタライスしたCMYK画像(CMY 0%,K100%)とアウトライン化テキストによるベクトルマスクになっていて、おそらくRIPでの自動スミノセでは対象外になる感じだと思います。

一応、K100%のオブジェクトではあるので、自動スミノセできる可能性も……ないかw

笹川さんのヤツ、あーーーって感じです。これですね :sob:

こんな有様で、本当に自動スミノセなんて使っていいんでしょうか……良くないと思うんだけどなぁ。

「いいね!」 1

作例の件とは違いますが、これも大きな課題です。
ノセイキでラスタライズって、こうやったらいいよって方法ありますか?

そもそも論として、X1a+自動スミ乗せがワークフローとして現在のベストアンサーではないですよね。
それを理解した上で、印刷会社(というか製版サイド)が正しく(狙い通りのオーバープリントで)刷れるかどうかをデータを見て判断すべき、と印刷会社のオペレーターのひとりとしては思います^^;;

X1aに書き出した時点でラスタライズがされてしまう、RIPによるスミ乗せはあくまでもPDFに対して行うもの、という2点から、X1a運用であればデータ上でしっかりオーバープリントを管理できてないとアウトじゃないかと僕は思います。

  • RIPによる自動スミ乗せを適用したければ、X1aで運用すべきではない
  • X1aで運用したければ、データ上でオーバープリントを管理すべし

というのが僕の理解ですね。

「いいね!」 3

ラスタライズされれば、非ベクター系オブジェクトたるビットマップ要素がオーバープリントかからないのはある意味当たり前なわけで……。
で、PDF/X-1aの特性まで考えたうえで、ラスタライズ処理を発生させないって考えたら、結局は「透明使わない」っていう、ある意味太古の作成方法を踏襲するしかないような。

というかそうなるとそもそもPDF/X-1aでの運用をいつまで引っ張るのかっていうほうが大きいわけで。
これもCPSI併用での過渡期としての仕様だってのもあるからねえ……。

CPSI併用での過渡期としての仕様>は「PDF/X-1aでの運用」に掛かっているのかな?

APPEが登場したのが2006年、PDF/X-4の正式リリースは2008年ですので、当然当初のPDF/X-1aの処理はCPSIで行う前提となります。

※私のところは当時全部EPSに変換していたけどね (。・ω・。)