Take the 2-minute tour ×
Graphic Design Stack Exchange is a question and answer site for Graphic Design professionals, students, and enthusiasts. It's 100% free, no registration required.

When covering one vector shape with another; if the edges overlap, the background shape's color is used as a (distasteful looking) pseudo-anti-alias effect on the foreground shape's edge, instead of having the foreground shape's color blend in with the color of whatever is outside both shapes. (Wow, I'm not sure if I made any sense describing this.)

I can cope with this happening within Illustrator, but why does it have to happen in any exported vector formats as well? For instance, when rendering logos in .EPS format, how do you deal with this annoying phenomenon? Is there any way to circumvent it without having to manually offset (trap?) the background object's edge so as not to get this undesired effect?

Choosing "Save for Web" in Illustratos seems to always render perfect results. But somehow (maybe someone can explain the technical reason) vector formats won't regard the behind-object to be entirely covered by the frontmost object (i.e. disregard the lower object's edge), but instead insist on "spilling" in its color onto the edge of the frontmost object.

To wrap it up:

I'm mainly looking for advice/approaches when dealing with this, especially within context of logotype crafting, where deliverables may often be requested in .EPS format, apart from normal bitmap formats.

EDIT: one thing I find interesting is that when doing "Save for Web" and switching between Art Optimized and Type Optimized, the latter will also exhibit this undesired phenomenon.

enter image description here

enter image description here

enter image description here

share|improve this question
It's officially acknowledged that the title for this entry is quite hard to understand. So anyone, feel welcome to perfect it if you know better words for describing this problem. –  hced Sep 30 '11 at 1:31

3 Answers 3

up vote 4 down vote accepted

This isn't really an Illustrator issue, but a general problem when vector art is rasterized. Displaying vector art on a pixel-based screen involves rasterizing just as exporting vector art to a pixel-based image format does.

Why is "Save for Web" better at this? Difficult to say, but it might require relatively slow, complex calculations to give the best result, which would be unacceptably slow if applied in real-time while you're editing.

I would imagine there are academic papers on this if you want to look into it further.

When supplying vector logos, it would definitely be best practice to eliminate the possibility of the issue occurring.

In your examples, you could either nudge the foreground object up and to the left, or subtract a copy of the foreground object from the background object and ensure that no traces of the background object remain at upper left.

share|improve this answer
e100: Well put. The subtraction approach is a good advice to include in the workflow (as well as keep in mind when designing). As for the assumable slow rendering of "Save for Web's" algorithm in a real-time situation, I'd kill for a vector based standard (be it .eps, .svg or what have you), where there are two different display modes; one being suitable for fast-rendering (including this display flaw), and another one that's not suitable for fast rendering (where overlapping objects render in a 'visually flawless' manner). –  hced Sep 30 '11 at 11:14
+1 I was going to make a post suggesting using the subtract feature in the Pathfinder palette. Copy the shape, subtract, paste in front with fill. Looks like you covered it. –  ghoppe Oct 2 '11 at 22:10

I did a few tests duplicating your scenario in AI CS5.1, and the fringing effect was (barely) visible on my big honking Cinema display when zoomed out, but not visible when zoomed in. My secondary display has a coarser pitch than the Big Guy, and it was more visible there. This tends to confirm what I suspected was the problem, and is more or less what e100 pointed out: this is an artifact of antialiasing by the application at the relatively coarse resolution of your monitor. It's a bit like the fine hairlines that sometimes show up in PDFs and cause clients to make frantic phone calls to the designer.

For obvious reasons, the effect is visible primarily on curved and diagonal edges, doesn't exist on vertical and horizontal ones that fall on pixel boundaries and is somewhat there when an edge falls between pixels, forcing anti-aliasing.

You can mitigate the problem by checking "Align New Objects to Pixel Grid" in the "Advanced" section of the New File dialog, but I found the effect disappeared completely when I turned off "Anti-Alias Artwork" in the Preferences > General section. You end up with "jaggies," but no false color artifacts.

It doesn't show in SfW because it's not really there. It's also not there in PDF if you zoom in. PDF "knows" there's a shape behind, and tries to anti-alias it at the resolution of the screen, so it shows up at small image sizes and disappears as you zoom. It also won't show on Export to jpeg if you change "Text Optimized (Hinting)" in the export dialog to "Art Optimized."

SVG is at the mercy of the browser's rendering engine. None of them (IE9, Chrome, FF, Opera and Safari) are up to the task, based on my tests. EPS, similarly, renders according to the application but will print or export to raster formats without problem.

share|improve this answer
Alan, thanks for your thorough analysis. I wonder if there's any chance of seeing some kind of plugin to mitigate these effects; preferrably where you can designate parts to exclude from anti-alias bleeding. I.e. detect and offset the outlines of culprit areas. Hm, wonder if this could somehow be vaguely related to trapping? Maybe not… But I was thinking, perhaps something like Esko's PowerTrapper (formely Trap-X?) might prove handy (although it isn't specifically tailored to fix this particular problem). esko.com/en/Products/overview/deskpack/modules/… –  hced Oct 5 '11 at 1:01
Since this is an anti-aliasing artifact, and only affects low resolution rasterization for display purposes, it doesn't seem like a trapping plug-in would be of value. Trapping is peculiar to print, and is by nature high resolution. –  Alan Gilbertson Oct 5 '11 at 6:52
I seem to have downvoted this by mistake, but can't upvote unless you edit... –  e100 Nov 17 '11 at 16:08
Dang, where's that "Oops!" link when you need it. :-) –  Alan Gilbertson Nov 17 '11 at 19:41

I would suggest trying a couple of things:

  • Nudge the top object over just enough to cover that extra line
  • Add a border to the top object the same color as the fill.

Using Illustrator is as much about creating the illusion of shape as it is creating the shape itself, and that requires a bit of strategy to get to work right.

Asking why Illustrator does this is unanswerable.

share|improve this answer
Adding borders is generally not a good idea in a logo, to prevent issues when a third party scales it with "scale borders and effects" turned off. –  e100 Sep 30 '11 at 10:32
Right. The only problem is within a precise/complex design, this would be a points and paths operation rather than nudging whole objects in order to compensate for this flaw (if I may call it that). One would expect – at least within the digital domain – that programs were smart enough to guarantee that when one object is carbon copied and placed exactly on top of another, the one below should be completely invisible. I suspect the culprit is in fact the way anti-aliasing works. If only one could prevent any surface but the topmost from anti-aliased rendering. –  hced Sep 30 '11 at 11:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.