Graphic Design Stack Exchange is a question and answer site for Graphic Design professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
This question is not political in the least!
While looking at the SVG version of Hillary's logo found here, I noticed there were notches in the two vertical bars of the H. The arrow crossbar covers up the notches so they are not seen when viewing the logo. But I'm very curious why the designer might have put in these notches. Does anybody know?
Without the notches you're likely to see the edges of the bottom shapes where they meet the edges of the overlaying shapes (on screen anyway, it's not really a problem when printing).
You can see examples and explanation of the possible artefacts here:
There's rarely any reason to have perfectly aligned edges that would cause artefacts like that so using "notches" like in Hillary's logo is a good habit to get in to.
Understanding rasterization and the painter's algorithm might help.
One way of rendering vector graphics (graphics defined by polygons, instead of pixels) to pixels is to rasterize the polygons while running the painter's algorithm.
The painter's algorithm is a bottom-up process where you first put down the background, then draw on top of that background with each layer of color until you reach the top layer.
When you deposit a layer, you pay attention to its coverage (usually stored in an extra channel, the alpha channel), and use it to mix the added color with what is already there.
If your new layer covers a pixel by 50%, and it is blue, you average the current color of that pixel with blue and draw that there instead.
Things get a bit more complex if you are creating an image with transparency, but not fundamentally.
Rasterization is the process of turning a polygon into pixels. Here, we work out how much the polygon covers a given pixel using some algebra, then calculate a coverage amount.
If you have two edges of a polygon that are coincident -- exactly on top of each other -- but both half-cover a given pixel, what happens is a problem.
Suppose the bottom polygon is red and the top blue and the background is white.
First we paint the red. This mixes with the white, leading to 50% white 50% red.
We then paint the blue. This mixes with the 50% white 50% red and we get 25% white 25% red 50% blue. The same thing happens if red and blue meet in the middle, or if blue covers red completely.
But "in reality" the blue polygon completely covered the red one, so why are we seeing it? Because the algorithm forgets sub-pixel positioning details.
So long as there is 100% coverage of one polygon, this isn't a problem.
Now, this problem is not fundamental. You can do polygon rendering with a ray-tracing like approach (where you over-render by a factor of N^2 at points), or even a pure-vector like approach (where you subtract blocking shapes from the geometry of the shapes under them, cutting them out). In neither case do "hidden" colors leak through to the output image.
The painter's algorithm isn't the only case where "hidden" geometry can leak through. If you are printing with opaque media, sometimes the color layers are not perfectly aligned. So under-layers leak through when the top layer should be covering it completely.
As you don't know how your vector image will be output, notches like that let you make images that are more robust against imperfect printing/display techniques.
Cai is correct. I thought I'd add a visual answer as well.
The reason this happens is that it's an SVG. Unlike a raster image where you control each rendered pixel, the rasterization of the SVG happens in the browser...so the browser makes these decisions.
One of the decisions the browser has to make is when to do anti-aliasing. It will typically do this when a point along a line falls on a pixel. It will then anti alias that pixel. Since it will render all layers of the SVG, it will do this to each layer and that's where you can start to get the edge artifacting. This is especially true when you play with the zoom of the SVG as that will cause it to overlap different screen pixels.
Here's a screen shot of a green box overlapping a red box in Chrome. The top is at 100% page zoom, the bottom is zoomed in. Notice the difference in rendering that edge:
If I screen shot that and zoom in to show the rasterization, you can a clearer picture of what's going on:
The ideal fix here would be for the SVG rasterizer in the browser to be 'smarter' and not render things that are stacked, but given that SVG elements can be manipulated externally and live (as it's just an XML file) it's not a practical solution for the browser.
So, instead, the designer makes that decision by using the notches you see.
By the way, this is similar in concept to how to deal with registration in printing by using trapping.
Printing in multiple colours requires accurate registration to avoid unsightly gaps and is a concern when artifacts are composed from multiple sources. Similar concerns can occur even in digital products where limited precision arithmetic necessarily introduces error.
The problem being avoided is one of inverse trapping - where deviation from the intended graphic can result in a thin line of the background colour showing on the left of the vertical coincident edges. As the colours are highly contrasting, the impact will be noticeable (try moving the broken line even 1 pixel to the left of vertical.
The approach is not intended to impact on mixing of inks. On-screen consistent coordinates avoids the problem, while half-toning is used to manage colour.
