23 replies to this topic

[Greg]

Lately I have been having quite a few jobs come back from the printer because there are a few text items or symbols that have been processed in rich black

Which reads as;

C - 73.73%
M - 63.92%
Y - 65.49%
K - 72.55%

I do all my drawing at 100% K in a cmyk illustrator CS3 document, but sometimes the objects i copy from other documents have been processed as 100% K spot or process color. When I export, It automatically converts to rich black, which when printed has a ton of registration issues, and ends up looking blurry.

There IS a setting in both Illustrator and InDesign under preferences that sets the appearance of black to either accurate (100k) or Rich. I have this set to 100k, but my exports seem to still output Rich on occasion.

I would like a sure fire way to either ensure my documents are saving without rich black, or an easy way to check the file for rich black once it has been exported to an eps.

Hopefully someone out there can assist!

Cheers

[frax]

Can you maybe use the magic wand to select similar colors, and replace them with rich black? Wouldn't pre-flighting the file in Acrobat warn, if you would use it?

[Greg]

Can you maybe use the magic wand to select similar colors, and replace them with rich black? Wouldn't pre-flighting the file in Acrobat warn, if you would use it?

I can select same Fill & Stroke to correct the issue, but that only works if I know the issue has occurred.
I am not sure about pre-flighting in Acrobat.

How does that work?

[Unit Seven]

It sound like you have your colour management settings messed up somewhere which should be a reasonably easy fix. If you can post a screen shot of you have in your Illustrator > Edit > Colour Settings window that should show whats up.

How are you creating your pdfs—export or print to PDF?

I take it you Illy documents are in CMYK colour mode but What cmyk working space are you working in? You have to make sure when you export to pdf you don't export to a different destination profile as a cmyk to cmyk conversion has to go through the lab working space (which gives similar results as if you took it tthrough an rgb space—you lose all control of black generation).

Also if you copy an object from one cmyk pdf to another and they are in different cmyk colour spaces

Otherwise as mentioned to fix you could try Acrobat > Advanced > preflight but I have looked before and I don't think Acrobat preflighting will fix rich black. This is a set of tests to check how 'press-ready' a file is. Things like check all objects are cmyk, check for small text on more than one plate, check for white overprinting objects etc. There are other more powerful preflighting tolls such as "Pitstop" and "Quite a Box of Tricks" whic I think can do this as we get our printer to fix some rich black problems for us at prepress.

[Greg]

Thanks, the preflight in Acrobat is not quite what I need, but I found a plugin called PhantasmCS, which claims to solve my exact problem, along with an abundance of other nifty functions.

http://www.phantasmcs.com/

I am going to try it out, hopefully it is the wondertool I have been looking for!

[Claude]

i wonder if this Golding tutorial would help?

http://rwillustrator...ng-artwork.html

[Kevin McManigal]

This really is controled by the pre-press guy or gall at the printers. On a recent job, I had everthing in 100% K, but the plates were burned to overprint black, which is a mix of CMYK (Rich). It looked like hell because the black roads and such were semi-transparent and showed the rivers, contours, and borders beneath. After a ton of back and forth, the answwer was to turn off overprinting for black, which knocks out all black on the plate, and prints it all in one run of 100% K ink. Whalla!!

[Greg]

This really is controled by the pre-press guy or gall at the printers.

This is the way I have always dealt with it, but printers have been sending work back if it has rich black.. rather then just fixing it on their end like they used to do.

pain in the a*s!

[rudy]

We occasionally get this problem - and I'm not always entirely sure as to why. However, we are finding the easiest way to check for this and for unwanted spot colours is to review the press ready pdf in Acrobat. Go to Advanced > Print Production > Output Preview. Up will pop a dialog box that lists all the plates to be used. If you turn off the black one, you can quickly see which items are rich black as they will still appear black on screen. Alternatively, when you have this dialog box open, you can hover your curse over any item and it will return the cmyk values for that item. Not entirely foolproof but certainly helpful in catching most problems.

[natcase]

This really is controled by the pre-press guy or gall at the printers. On a recent job, I had everthing in 100% K, but the plates were burned to overprint black, which is a mix of CMYK (Rich). It looked like hell because the black roads and such were semi-transparent and showed the rivers, contours, and borders beneath. After a ton of back and forth, the answwer was to turn off overprinting for black, which knocks out all black on the plate, and prints it all in one run of 100% K ink. Whalla!!

Well, yes an no. A few instances:
If an image goes through "RGB-ization" anywhere in the process, then back to CMYK, there's a good chance you'll get rich blacks. This is a problem in translating files out of Freehand (where black is it's own special thing) into AI, where that Freehand black is treated as RGB and translated into rich black.

Second, overprinting and trapping are different from rich black. I've never heard of "overprint black" as an ink color. Overprinting is another thing to check for in Acrobat (also nice you can see it in InDesign and AI). There's no reason that a black ink, overprinting, shouldn't appear simply as 100%K + whatever color lies behind it in the document.

Perhaps your issue involved a one-color map, where some of the blacks and grays were RGB and the others CMYK? I can see that causing some headaches.

[rudy]

This is a problem in translating files out of Freehand (where black is it's own special thing) into AI, where that Freehand black is treated as RGB and translated into rich black.

THAT is the problem! We've had files coming from Freehand, sometimes exported to eps, sometimes exported to Illustrator and there never seemed to be any rhyme or reason as to why some files coming out of InDesign were okay and others were not. Thanks!

[smellykev]

self edited- dumbass thing to say

[Greg]

...

[MapMedia]

...

dude! that is uncool

[smellykev]

...

dude! that is uncool

yeah, you're right... I guess we're less PC in Australia but it still was a dumb comment. Apologies to all.