Illy stroke overprints ignored sometimes...

[danprtr]

Printing from CS4 Illustrator, there is a problem with some stroke colors with the overprint attribute checked, knocking out within a process color file. Illustrators overprint preview on the monitor looks correct but separations printed from Illustrator show some objects strokes are overprinting (correct) and some are not.

Usually, we print spot color separations from Illustrator and have never noticed this problem. Recently we’ve printed the same type of image data (mostly colored objects without transparency or other complicated issues) as process color separations and discover that the Illustrator preview of overprints cannot be relied on. The same incorrect output results when printing to a PDF using In-Rip Separations and viewing in Acrobat or printing to a Harlequin RIP so it doesn’t appear to be a RIP issue.

Previous Illustrator versions did not seem to exhibit this print to preview “stroke overprint” inconsistency. We have checked preferences and tried several workstation installs of Adobe with the the same results. Using InDesign to print the Illustrator files fixes the problem but it seems strange that Illustrator won’t print simple native objects correctly.

Open to suggestions!

Thanks,
Dan

 

[Lukas Engqvist]

You are printing using print command in Illustrator? Or is it creating a PDF wich is dropped in a hot folder?
I would be interested in seeing a screen dump of this, if it is possible. (or if you don't want to post it feel free to PM i)
You mention printing to PDF it is not that you save to PDF? I am assuming that what you print from indesign is placed AI files? What is your PDF compatibility? Could it be that InDesign is using safe CMYK workflow (preserve numbers) and illustrator is not? Colour managing overprinted colours can give unwanted results. If you have a colour CMYK 100 0 0 0 and overprint a stroke of 0 0 100 0 the stroke will appear overprint. If the colour was managed and background is then redefined as 100 0 0 0
and stroke 1 0 100 0 the stroke will be 1 0 100 0 i e almost knocked out.


I would check the colour management and make sure colour settings are in order.

 

[CHM]

We dont have this problem, than again we always remove overprints and change them to transparencies mostly multiply.

 

[Stephen Marsh]

We dont have this problem, than again we always remove overprints and change them to transparencies mostly multiply.

CHM, can I assume that you are in a APPE workflow and not PostScript?


Stephen Marsh

 

[CHM]

we have a full Nexus environment for many years now

 

[michaelejahn]

find change saves the day.

find change saves the day.

We dont have this problem, than again we always remove overprints and change them to transparencies mostly multiply.

Actually, you and everyone else does have this problem, you just happen to use software to overcome it using this work around - problem solved !

Adobe engineers have to come up with solutions for things like "i have a spot color stroke overprinting an RGB filled objects and this is all set to 30% transparency over a CMYK..."

You get the picture - this is why we prepress vendors all licence things from Enfocus and Callas - the know we need to convert what we have into something we can use in our high end prepress environments - this is not where Adobe lives or makes is money.

 

[John W]

We knock the version down to CS3, expand objects where necessary and then save as eps (ie basically flattened postscript w/o transparency). Then overprints are honoured. When transparency is used, the preserve overprint checkbox must be checked as well.
The rip's vintage will clearly have an effect (receiver intent not sender intent); if fairly old, then an old ps recipe must be provided. Some modern auto rips actually print postscript behind the scenes, so testing would be a smart idea for yours.
We hate CS4 - can't select a mask and object in artwork mode - therefore, it's useless IMO.
CS5 continuation of trouble.
John W