Cannot align boxes properly.

[Hans Deragon]

Attached, an image with multiple squares. Zoom in far
enough and you will notice that between some squares
there are spaces. Using the grid, you still cannot
snap or resize the squares in any way to get the spaces
filled.

Two squares side by side should align properly on the
grid and let no space show up between them.

I tried both "snap box to grid" and "snap points to
grid" but nothing helped.

[Buliabyak-users (buliabyak-users)]

The squares are aligned exactly. The "gaps" are a rendering
artefact caused by the fact that the edges are antialiased.
These "gaps" therefore depend on zoom level. I don't know if
this is fixable at all without removing AA, at least I don't
know of any vector editor or viewer with antialiased display
that would not have this problem. For example your file is
displayed with similar gaps by both Adobe SVG viewer and
Batik. Xara and Illustrator also have this same problem.

In any case, this is a dupe of

http://sourceforge.net/tracker/index.php?func=detail&aid=1003049&group_id=93438&atid=604309

which will be closed when we have a non-AA rendering mode.

[Hans Deragon (deragon)]

There must be an easy solution. If two objects touch each
other, have some code to overide AA and ensure that no gap
is shown between their two touching borders. Maybe this is
dificult to implement for curbs, but at least for straight
lines that should be feasable.

This problem is serious because when I export in PNG this
image, the gaps still show! Thus my banner for a web page
is useless. Please reconsider opening it if only to fix the
PNG exporting facility.

[Buliabyak-users (buliabyak-users)]

> There must be an easy solution. If two objects touch each
other, have some code to overide AA and ensure that no gap
is shown between their two touching borders.

I would agree with you if you could show me a single vector
editor which solves this problem. As I said, I know of none.
Even professional ones such as Adobe Illustrator behave like
this.

Deciding "if two objects touch each other" is a very
non-trivial problem. I'm not sure it is solvable in the
general case, and in any case an attempt to solve it will be
very computationally intensive. "Overriding AA" selectively
is also a can of worms; I'm sure that trying to do this
would cause lots of artefacts that would be very difficult
to get rid of.

It's one of those cases where using human intelligence would
be much faster than trying to automate it. In your case,
just slightly enlarge all the squares so that they overlap a
bit. If your squares were clones of a single square (a
recommended approach for artwork like this), it would be a
one-minute task.

Another workaround which only works for strictly
horizontal/vertical boundaries (such as in your banner) is
to make sure each rectangle is completely snapped to the
grid and to export it with such resolution that the grid's
units have an integer unit-to-pixel ratio. For pt, this
would mean exporting at 72dpi or a multiplier of that. So,
if you fix ALL of your squares so that each shows integer X,
Y, W, H when you select it (right now many are slightly
misplaced or mis-sized), and then export your image at 72 or
144 dpi (instead of 122.95 dpi as you did), there will be no
AA gaps because there will be no AA, as each edge will be
exactly at a pixel boundary. So, it takes some planning and
some care, but it's easily doable.

Generally, even with best software in the world you need to
know some manual tricks if you want your artwork to look
perfect. Avoiding edge-to-edge boundaries and replacing them
with small overlaps is one of such tricks you need to learn
for vector graphics. Myself, I learned this long ago on an
early version of CorelXara (which was one of the earliest
vector editors with full antialiasing) and I haven't yet had
a chance to unlearn it, even though I used lots of different
vector editors since then.

[Hans Deragon (deragon)]

I will follow your advice to work around the problem.

But there is something I really do not understand. My
squares are almost of the same color and touching each
other. With AA, their borders should merge. Yet, instead
we see a gap made of the background color between the
squares. Somehow, I feel that this is a AA bug.

AA might generate shaggy borders, but the other "side" of
the border should have the color of the other object, not
the background color which is in theory totally hidden by
the two objects touching themselves.

In other words, AA should not even let these gaps appear in
the first place. So the question is, why AA merge the
borders with the background instead of the adjacent object?

I wish I had the time to get involve with this because
somehow, I feel that a solution for straight lines touching
themselves would be possible. When an object is droped, its
border is checked against its neighbourghs and borders that
meet are recorded. When rendering time comes, on these
borders AA is applied using the colors of the two objects,
not that of the background. I do not see how gaps would
show up in that scenario.

I agree that curves are difficult. But for straight lines,
this should be possible and I bet most people suffering of
this problem have them with straight lines anyway. If the
problem is solved only for straight lines, its still a major
improvement.

[Buliabyak-users (buliabyak-users)]

It's easy to explain. Imagine that the boundary of two 100%
black rectangles falls exactly in the middle of a screen
pixel (or export pixel). This means that this pixel is 50%
covered by one rect and 50% by the next one. Antialiasing,
therefore, paints that pixel 50% transparent black for one
rect and 50% transparent black for the other. However if you
add two 50% transparencies, you don't get 100% (fully
opaque). Instead you get a 75% transparency. You can try
that with transparent shapes in Inkscape - that's how
transparencies add up. As a result, you get a row of 75%
transparent pixels which are clearly visible between two
fully opaque rects. That's the artefact you are getting. The
exact level of transparency of that row of pixels will
depend on where the exact boundary falls within the pixel
grid, and therefore will change seemingly randomly as you
change zoom or export dpi. Snapping all boundaries to the
exact pixel grid, as I explained in the previous comment, is
a way to avoid this.

[Hans Deragon (deragon)]

I understand. However, why is AA using transparency all the
time? I would instead implement AA to merge the color of
the object with the one beside it. If beside the object
there is nothing, then merge color with transparency. But
if there is an object beside, merge both colors together.
So object A is 100% black, object B is 90% black, the pixel
on the boundary would be 95% black. That would look very
nice without any gap.

I assume that AA as implemented uses transparency because
this makes the implementation simple (you work on each
object individually without taking care of the objects
surrounding it). But you should check if it is easy to
change the AA algorithm to take into account objects that
share the same border.

[Buliabyak-users (buliabyak-users)]

> But you should check if it is easy to
change the AA algorithm to take into account objects that
share the same border.

Of course it's NOT easy, that's what I'm trying to tell you.
If it were easy, other apps would probably have this
implemented long ago.

[su_v (suv-lp)]

linking as duplicate to bug #170356 “Suppress antialiasing artefact at the object boundary” (see comment #1)