I have a yellow box1 with fill CMYK=0/10/50/0, and a yellow box2 with fill CMYK=0/0/10/0. Both are on the same layer with box2 being in front of box1. box2 has the "overprint fill" attribute ticked.
When I look at the overlap area, I expect CMYK=0/10/60/0. But Illustrator shows: CMYK=0/10/10/0. Why is that?
I am using CS4.
Overprint only adds different colors. The same colors are not added. http://livedocs.adobe.com/en_US/Illustrator/13.0/help.html?content=WS7 14a382cdf7d304e7e07d0100196cbc5f-6494.html
I read the text at the linked site and I do not see where it states that same colours are not added. Perhaps you can point me to the exact sentence/paragraph, in case I misunderstood. Thanks.
Overprint Preview is on already.
Thanks, I had misunderstood the sentence initially. Isn't it counter-intuitive though? I would think that adding a layer of the same colour on the background would make it more intense (in a real life "painting" situation), but here, the foreground colour prevails, as if it knocked out the background colour (i.e. no overprinting)!
e.g. adding background CMYK=0/0/50/0 and foreground CMYK=0/0/10/0 yields a combined result of 0/0/10/0 (same as foreground colour).
Thanks Monika. As far as any possible misregistration at print time, then does overprinting in such conditions (where top colour prevails on background colour if the same colour is present in both foreground and background) still prevent misregistration or is it no different than knocking out the background?
Isn't it counter-intuitive though? I would think that adding a layer of the same colour on the background would make it more intense (in a real life "painting" situation), but here, the foreground colour prevails, as if it knocked out the background colour (i.e. no overprinting)!
Exactly. But you won't win this argument. (I've tried, for many years.)
When you and I say "overprint," we are thinking in terms of real-world ink-on-paper to which the term supposedly alludes. In the real world, there is no prohibition against two "hits" of the same ink in a single pass. (Commonly done with black.) In Adobe-speak, that never happens. So coverage for a single ink cannot exceed 100%, because when separations are printed, there will (in your example) stil only be one Y separation plate generated.
That, of course, still doesn't explain why (as you point out) a lower percentage of a given ink component actually knocks out (the very opposite of overprinting) any other values of the same ink. In the normal sense of the word "overprint", one would expect the sum of the same-ink values to result (up to 100%). But even doing that would not really emulate true overprinting, because a true overprint might result in 110% Y, which of course cannot be imaged on a single Y separation plate.
So to actually achieve what you and I would call a double-hit of Y, you'd have to resort to adding a 5th ink (a spot Y). That's not too bad, since each separation should correspond to a single pass of a press inkwell. But then you are faced with the fact that in Illustrator, you cannot create solid Swatches from multiple inks (other than CMYK), as you can in InDesign (and in Quark XPress long before that). In Illustrator, you have to resort to methods like multiple fills or stroke for that.
So that's why it's often offhandedly suggested to use Multiply to effectively replicate what you and I call overprinting. But it doesn't really, because even with Multiply, you will still not achieve greater-than-100% coverage of a single ink. Multiply can often imitate overprinting the same ink, but it doesn't really replicate it in the real world if an actual physical overprint would result in greater than 100% of a single component ink.
It boils down to the failure of software to truly emulate what goes on in the real world, and creating confusion when real-world terms are adopted. For example, ask any screen printer if "Overprint Preview" even remotely previews what actually happens when overprinting opaque screen inks. Illustrator always assumes the translucent inks of offset lithography--which is why I have also long argued that spot color Swatches should provide an ink-specific opacity setting, which should in turn be simulated by Overprint Preview (which really should be named Overprint Simulation).
Thanks Monika and JET, those are both very informative insights.
So, in a scenario where I have a background coloured area, say made of CMYK=10/20/50/0, and foreground text in black, what is the best solution to have a good solid black text with well-defined edges and no misregistration?
a- Use a rich black (e.g. CMYK: 30/30/30/100) and overprint it on the background? In Adobe, this would yield 30/30/30/100 for the overprint area - this is similar to the rich black "knocking out" the background.
b- Use a rich black (e.g. CMYK: 30/30/30/100) and knock out the background?
c- Use a pure black (100% K only) with a knockout of the background where the text lies?
-Would the same answer apply to small text (e.g. 10pt) and large text (e.g. over 20pt)?
-Is there any difference in print between (a) and (b)?
-Out of curiosity, is there a chance to see any white halo iaround the text in solution (a), as in a true knockout, or will the paper be fully covered with ink?
...I have a background coloured area, say made of CMYK=10/20/50/0, and foreground text in black, what is the best solution to have a good solid black text with well-defined edges and no misregistration?
Simply set the black text to overprint. The 100% K text will overprint (not knock out) the other (non-K) components of the background. The 10c, 20m, and 50y dots will still be there. Your text will thereby be 10c20m50y100k.
Be careful with terminology. As Monika mentioned, creating traps or overprinting does not "prevent misregistration." They merely make it less noticable.
...is there a chance to see any white halo...
Designers often over-compensate in building traps. White slivers are only going to appear where there is no ink. This is why, for example, one can very often get away with placing colored type in front of a full-color photo without any traps whatsoever. For example, if, in the area of the type, both the image and the type have some significant component value of any given ink (other than Y, because it is light, even when 100%), a misregistration sliver is not likley to be significantly noticable, unless the printing is rather crude and misregistration is extreme. The resulting slivers will at least have some dots in them. That is, the slivers will only appear on sep plates of inks on which either the text or the image does not appear at all.
Remember: misregistration occurs on press (or in stripping), not in the printed seps. Same-ink objects are going to image to the same separation film (or plate) at the same time.
I've seen designers worry over things like, for example, 100y (solid yellow) text in front of a 100m100y (red) object. No trap or overprint whatsoever is needed in such a case.
I've also seen designers think they need to build traps on projects to be printed by composite printers on which all inks reside in the same carriage, and are therefore sprayed at the same time, on the same single-roller single-pass.
Thanks JET. Understood, I also meant to make mis-registration less noticeable, not prevent it.
One last question, somewhat related. What is the best practise in the case of grey text in the above example (instead of the black text)? I suppose overprinting is a no no for grey.
What is the best practise in the case of grey text in the above example (instead of the black text)? I suppose overprinting is a no no for grey.
I have a background coloured area, say made of CMYK=10/20/50/0, and foreground text in [grey, instead of black].
Another gentle admonition: You need to define "grey". Speak and think in terms of inks, not colors. Grey can be a tint of K, or could be built from CMY (or CMYK).
Best practice would depend on two things: the value (lightness/darkness) of the text as opposed to that of the background, and the size of the text relative to the thickness of the expected misregistration.
If built from a tint of K, then you would need either a choke or a spread to avoid the possibility of white slivers (or simply accept the possibility of a minor white sliver (which, depending on the values, may actually be preferable to spreading a black dot into the surrounding "background," or choking CMY dots into small type). If using a trap, you choke or spread the lighter color into the darker.
So knowing neither the size of the type nor the ink values of grey, let's assume middle ground in both:
10c20m50y is pretty light; about like the brightness of 30K. Yet there is enough color difference between 10c20m50y for 30K text to not look bad against it, depending on the size of the text, which I'll assume is headline size. In this case, either a choke or a spread is going to be distracting, resulting in a noticably darker outline around the text. It also will make the text itself either appear "bolder" (in the case of a spread) or "thinner" (in the case of a choke).
What to do? I wouldn't build a trap at all. I'd simply apply a CMY mix to the type which effectively "neutralizes" the color to grey. 30c21m17y on my present laptop screen pretty well simulates 30k. Use those values, and no trap (that is, no choking or spreading stroke) is needed. Any slivers would merely be a minor shift in percentage of C, M, or Y; probably not distracting at all. (I would, of course, validate the color mix by referencing a printed Postscript swatchbook.)
Or--depending on what kind of "grey" you want--simply coloring the text with a tint of one or two of the underlying CMY values and setting it to overprint (which, given the actual behavior, arguably should be called "Override", not "Overprint") may also "neutralize" the result to a "grey". For example, because the underlying fill you specify (10c20m50y) is orangeish, simply adding C would make it less saturated (more grey). So simply filling the text with 30c and setting it to overprint would serve to shift it to a warm gray without introducing K at all, and there would be no slivers whatsoever since in the resulting seps only one plate would be affected. The resulting gray would be a little darker than the background.
Or, you could fill the overprinting text with a K value (thereby creating a shade of the underlying color) and then add enough C to neutralize the color. Any resulting slivers would be position differences between C and K, which are the two darkest component inks anyway.
So no, overprinting grey is not necessarily a "no no." It depends on what you specifically mean by "grey." "Grey" simply means desaturated. It doesn't necesarily mean "tint of K."
The basic principle is like this:
Apply a Stroke to the type twice the weight of the potential slivers. (i.e.; a 1 pt. stroke will create a half-point trap.)
Set the Stroke to overprint.
If the grey of the text is darker than the rear object, set the stroke to the same color as the rear object. This will effectively choke the text with the CMY of the rear object.
If the grey of the text is lighter than the rear object, set the stroke to the same %K as the text fill. This will effectively spread the %K of the text into the rear object.
In both cases, the text fill will knock-out the rear object.
In the first case, the CMY values will overprint a half-point inside the edges of the type.
In the second case, the K tint will overprint a half-point outside the edges of the type.
In both cases, the area of overprint will consist of the CMY values plus the K value of the type.
If you want to semi-automate this, see Trapping in online Help. If you apply a trap as an Effect, it will not display with Overprint Preview on. If you apply via the Pathfinder palette, it will not work on type that is not converted to paths. Using these features lets you distort the trap so that horizontal width is a percentage of vertical, for when you know that the registration is better/worse in the direction of the paper pass or perpendicular to it on a given press.
If the tone value of the text and the rear object are similar, I would build a grey out of CMY as described before, and not worry about slivers. This would most likely avoid an unwanted visible "outline" around the text.
I always just build my own traps manually. If you build traps into your file, be sure the printing house which images the separations is not using other software to auto-create traps.
In addition to the above thourough descriptions: The behavior you were expecting is as if Overprint equals Transparency. As you see, they have entirely different purposes -- Overprint should mainly be used for special effects on the printing press (such as preventing visible misalignment).
I think we should really forget overprint all together.
We are building everything with transparencies here, and the main reason for that is that there is real risk of getting unexpected results if you have overprint and transparencies applied on the same elements.
Overprint was a postscript thing now most all modern rips are pdf rips that are fully compatible to the Adobe transparencies.
I think we should really forget overprint all together....Overprint was a postscript thing now most all modern rips are pdf rips that are fully compatible to the Adobe transparencies.
Nonsense. The existence of so-called Transparency Modes does not obviate the need for overprinting. Overprinting is not just "a PostScript thing." It dates back to the beginning of offset lithography. A RIP's being able to interpret Transparency Modes in a PDF does not mean that you no longer need to use overprinting to build traps. For starters, consider: What would result if you tried to use Transparency Modes in lieu of overprinting on a job which involved a spot ink?
Yes, a Transparency Mode (Multiply) would address the first situation mentioned in the original post (a 10y fill added to an underlying 10m50y fill). That solution was proferred in post 6. But the followup questions seek to understand overprinting, using other scenarios.
A blunderbuss statement that suggests overprinting is no longer needed just because of the existence of Transparency Modes is horribly misleading.
JET, we are using this all the time for packaging repro work and believe me we do a lot of it. We produce roughly 50.000 SKU's a year and deliver the final one up files to more than 500 packaging printers in 3 different printing processes around the world.
And we banned overprint and are using transparencies instead, thus avoiding costly mistakes by combining the 2 in the process.
So my advise is look into it and avoid it.
I don't care how many packages you print in your particular environment. The fact that in your environment, you are not using overprinting still does not mean that overprinting is not needed in other environments.
Consider a typical 5-color sheet-fed product brochure. CMYK plus one logo-spec spot color. How are you going to trap the 5th color to underlying process art using nothing but a Transparency Mode?
Set up a simple test using the sample scenario from the original post (a 10y fill in front of a 10m50y fill). Set the front object to Multiply. Print seps. See if the result is, in fact, the stated desired result (60y).
So to build the trap you have added a second offset fill to knock out the underlying process and set the 5th color element to multiply instead of overprint. That is no less work than doing the same, but setting the 5th color fill to overprint, and the freelance designer doesn't have to worry about whether the setup at the local sheetfed printing house or silkscreen shop or sign shop fully supports Transparency Modes.
I would be satisfied if Illustrator would simply use the darkest of any stack of colors in an overprint zone.
For example, if you put 100C 50M on top of 100M 50Y, you would get 100C, 100M, 50Y. This would satisfy my overprint trapping needs.
Anyone care to expain an alternate method in the event I am unable to fix this problem I'm having that Adobe was not able to duplicate on their end? It's definitely a bug, (possibly related to CS5.5 on OSX Lion?).
So now I'm confused. Is it nonsense, as claimed, that overprinting can be eliminated in workflows like the ones discussed here, or is it merely that more modern, alternative methods are no less work? There's a significant difference between the two.