Is there a reason Hillary Clinton's logo has hidden notches?



This question is not political in the least!

enter image description here

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?

enter image description here

I. J. Kennedy

Posted 2016-06-18T21:04:48.143

Reputation: 1 238

45Technically this is a bug circumvention scheme. Its a bit surprising and unsettling to think that all the universities and mainstream vendors of 2D rendering engines do the same mistake over and over again, even though we know the cause, we know how to fix it abd its not that big of a performance hit on a modern computer. And no 3D graphics people rarely make this mistake and have known about it for 30+ years.joojaa 2016-06-19T10:22:40.113

@joojaa how's this apply in 3D? My thought was Z-fighting, but that still isn't terribly uncommon in video games (admittedly the permutations of degrees-of-freedom, polygons, shaders, model positions, etc. are practically infinite compared to making a specific 3D graphic)Nick T 2016-06-20T21:54:31.827

4@NickT Its not a z fighting issue its a issue of mixing together opacity and coverage but 3D is much more than games. In 3D we have for ages used multisampling to solve the aa issue. Multisampling (usually, even if it would the results would not be so pronounced) does not calculate coverage and thus does not make the mistake of thinking that 50% coverage is 25% visible trough another 50% coverage. While this may be true the answe can also be 50% is visible or none is visible. In this case to avoid confusion the other 50% is manually removed we can fix 3cases but not all. Should not be needed.joojaa 2016-06-20T22:23:42.057

3It is sad that I clearly recognized it as to avoid a rendering bug of overlapping borders. But SVG still is 14 years old so I hope this gets fixed some day.Francisco Presencia 2016-06-21T01:10:55.217

4@FranciscoPresencia its not a problem with SVG its just a problem with the way we choose to erroneously implement the renders. Different SVG renderers have different severity of this problemjoojaa 2016-06-21T08:36:27.060

1@joojaa but it still could be added to the spec how to render it properlyFrancisco Presencia 2016-06-21T14:21:22.027

@joojaa I don't think it's a simple 'fix' though. The 'bug' makes sense if you think about each element of the SVG being rasterized individually...which is exactly how an SVG works. If a vector lies on a pixel, there has to be that one pixel of anti-aliasing. In a purely static SVG, I do see that some logic could be added to mask items below others, but since you can do things like animate SVGs, I do see that being a much more complex bit of AI that would have to be written.DA01 2016-06-22T15:21:23.803

11@DA01 no the naive fix is incredibly simple, its less code than the current algorithm. Instead of doing coverage based calculation just render as if you did not antialias at all on a higher resolution then filter the image down to real resolution. This will never spill from bottom up since it can not make a mistake the front most element obscures it entirely. Graphics cards do this all the time that what the x4 x8 x16 aa settings are about in the gfx card settings.joojaa 2016-06-22T15:26:49.290

@joojaa ah, yes...that's an interesting solution.DA01 2016-06-22T16:15:09.167

@joojaa Even using the usual 3D engines you need to avoid T-joints since otherwise vertex position rounding errors can lead to holes or overlaps. In this case this amounts to adding vertices to the blue bar where the left of the left blue bar intersects the arrow. (As long as you don't rotate the logo it might not affect this case due to the alignment of the figure to the cardinal directions, so you would probably be fine without them)CodesInChaos 2016-06-24T08:09:09.360

@codesInChaos i am aware of this.joojaa 2016-06-24T09:35:20.150

1it's simply good practice to avoid printing problems - no big deal.Fattie 2016-06-26T03:18:17.537

@joojaa the issue with this is that you need to know when to downsample. And if you hold both the upsampled and the downsampled version at the same time, you'll end up with developers wanting pixel access to that upsampled buffer. A second issue is holding this much data in memory. (You can already do this in Javascript, BTW: Just have the canvas raster twice as big as the space it's rendered to)John Dvorak 2016-06-26T19:14:17.937

1@JanDvorak So you prefer errors because its easier? Your bank could also avoid the rounding and just truncate numbers because its convenient (boy would they be glad to do so). But no you dont need to store the buffer longer than it takes you to filter it down. I know it can be done its just that it is not done by default meaning that every graphics designer in the world spends hours every year debugging these problems. Its not like i have access now either.joojaa 2016-06-26T19:34:35.910



To prevent possible rendering artefacts.

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.


Posted 2016-06-18T21:04:48.143

Reputation: 33 295

6This can actually be just as big of a problem with printing. In digital printing at least the svg will typically be rasterized before being sent to the printer, and the same types of artifacts may appear. (last project at my last employer (big commercial printer) involved writing software to help identify these sorts of things before the expensive work of putting ink on paper was done.)Mr.Mindor 2016-06-22T19:29:11.937

1Since we're talking about US politics, you mean "artifacts"?Andrew Rasmussen 2016-06-24T00:06:28.573

5According to I mean artefacts, not artifacts. (But since I'm British, I mean artefacts regardless)Cai 2016-06-24T00:14:38.947

There's rarely any reason... just curious: is there ever any reason?Alois Mahdal 2016-06-24T16:03:55.670

@AloisMahdal I very much doubt it.Cai 2016-06-26T08:59:50.103


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, they 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.


Posted 2016-06-18T21:04:48.143

Reputation: 651

1Your description applies in the case of graphics containing alpha channels, or in the case of subpixel drawing when anti-aliasing. The OPs example will show the notch artifacts for blended layers contrary to what is intended. I'd suggest the issue is more related to registration errors in printing.Pekka 2016-06-20T18:01:20.173

2@pekka yes, but most rendering does anti-aliasing today.Yakk 2016-06-20T18:42:06.017

If the top layer has any transparency, then the notch will result in gradual drawing back of the lower layer from the edge impacting on both the anti-aliasing and the top level color. A more appropriate response would be to have a rectangular rebate (of a size difficult to estimate) in the area where the mixing is not desired. How do you quantify this?Pekka 2016-06-20T19:20:04.830

@pekka If the top layer has medium amounts of transparency, this problem is far less problematic (as you can see the red under the blue anyhow). As transparency of the top approaches opacity, approach the above solution. As it goes away from opacity, approach pre-compositing it. The general problem is tricky given registration errors, build-up problems (too many layers!), anti-aliasing, and everything else: at some point, you want to write custom vectors for each output format, or munge the vectors somehow. I simply tried to answer the exact technical cause of the problem the notch solves.Yakk 2016-06-20T19:34:15.923

1@Pekka a rectangular is harder to draw and then you end with teh opposite problem of the same issue in that the background shows trough. Notch is sort of a compromise between one bug over a number of others (the notch is for on screen rendering wile not having a square cavity is so that overprinting plates can be made if needed with minimal errors). But there really is no reason for there to be a need to do this, its just that our renderers work wrong thats all there is to it. We could all the 3 problems easily by switching the way we rasterize.joojaa 2016-06-21T08:28:24.867


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 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:

enter image description here

If I screen shot that and zoom in to show the rasterization, you can a clearer picture of what's going on:

enter image description here

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.


Posted 2016-06-18T21:04:48.143

Reputation: 46 046


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.


Posted 2016-06-18T21:04:48.143

Reputation: 269