Provide per-object antialiasing control (SVG 1.1 shape-rendering property)

I forgot, example 3 is the same as example 2, but there is a
dark red square behind it.

I don't think this is fixable with AA. Or, at least, I don't
know of any vector editor using AA that would not have this
problem. Your file shows the same thin boundary in both
Batik and Adobe. I think the ratio of the potential benefit
to the amount of effort needed to fix this (if it's fixable
at all) is too small.

I think the best way to "fix" this is to implement a non-AA
display mode for those who need it.

It happens as well if you duplicate and break paths... Say
that you have a torus (doghnut). Duplicate it, and break
apart the duplicated path (Control+Shift+k). Delete the
outermost (bigger) path, so that the smaller one fills the
torus' hole. You'll notice a white outline on it.

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

was marked as a duplicate of this bug.

Thank you for taking the time to report this bug and helping to make Inkscape better. You reported this bug a long while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Inkscape release? Thanks in advance

Marking as 'won't fix', since the issue being reported is actually 'valid', it is just apparently not fixable...
Also merging in a couple recent duplicates...

I wouldn't say it's impossible to fix. (fwiw, it can also happen on solid fills) But it requires a different method of doing antialiasing which is not as fast. We might just end up doing it for PNG export or something.

It certainly isn't unfixable; it would just take a lot of effort and slower rendering. Something working on top of whatever we've got right now. I think you should re-mark it as "fixable" or whatever but keep importance low just for priority's sake, since it would extremely important for those who need it and would undoubtedly increase Inkscape's usefulness and appeal to Illustrator users by huge leaps.

If this is ever revisited, be aware this problem shows up in two forms, both illustrated here: http://dagibit.googlepages.com/Aaissue.png

I think this should be worked on for at least png export.

I'm a little bit surprised to see this treated as low priority. It cripples Inkscape in some very common scenarios. I just wasted a half hour trying to get a seam-free export of my work. Yes, for the love of FSM, please fix this for png export. It's fine to see seams in the UI as long as they're gone in the final product!

I'm surprised too. The only workaround I've found is to save the vector as an eps then open it in GIMP and suppress antialiasing using its import options. It works, but I don't think is an ideal method for everyone.

Reproduced on Windows XP, Inkscape 0.48.1 and trunk revision 10441 (new Cairo renderer).

I develop a tool called pixel2svg which converts pixel art to vector images replacing pixels by squares, for upscaling and incorporation in vector logos etc. These images severly suffer from antialiasing artefacts at object boundaries. Any fix would be most welcome.

I'm surprised too. 8 years later and it (the seams) is still crippling Inkscape. A fix for export-only would be perfectly fine. Seams in viewport is no issue.

Anyone know if any progress has been made for this bug yet?
I noticed a proposed solution was to run through GIMP, but it
would be great if anyone had any simpler suggestions on how to
remove the artefacts as it's making exporting tiles very difficult

Since we are using Cairo everywhere now, this bug is easy to fix: simply call cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE) when drawing. However, we need to invent some kind of UI for this.

Starting with trunk r13144, there is a toggle in the document properties that allows one to disable antialiasing.

> ** Summary changed:
>
> - Suppress antialiasing artefact at the object boundary
> + Provide a display / export mode that does not use antialiasing

@Krzysztof - there are other reports which actually explicitly requested various aspects of such a feature (this one did not, AFAIU):

- Bug #170392 “Advanced antialiasing control & font hinting”
- Bug #175695 “FEATURE: display quality slider”
- Bug #180612 “Optionally disable anti-aliasing for bitmap export”
- Bug #437667 “anti aliasing command line options”

Reopening as per mailing list discussion

r13146 implements the global aliasing toggle via the shape-rendering property.

I apologize ahead of time if the following should have been sent to the mailing list instead of being listed on this bug. Other such comments seem to be here, so I assume this is the right place.

A true per-object implementation would ideally need to handle images as well. SVG 1.1 defines an image-rendering property that can be used to handle this. The currently recommended way to implement image-rendering="optimizeSpeed" is to use nearest neighbor scaling. It would be great to use that option on images rather than shape-rendering="crispEdges" property.

Ideally, the CSS property image-rendering will be completed, and we can use something more explicit such as image-rendering: crispEdges or, better yet, image-rendering: pixelated. Unfortunately, right now, those still use browser specific prefixes, which I believe are out of scope for Inkscape.

Neither shape-rendering="crispEdges" nor image-rendering="optimizeSpeed" explicitly disable anti-aliasing, so I don't think that should be a problem. As far as I know, all platforms that have implemented those properties use a nearest-neighbor scaling algorithm. They are thus the only method of implementing aliasing in SVG 1.1.

@trikly - I recommend you test with current Inkscape trunk - the mentioned rendering attribute is already implemented for bitmap images (that implementation is not really in the scope of this specific report); it can be set for each bitmap image on import, and changed later on in the image's Object properties.

See also the related discussion on the devel mailing list:
<http://sourceforge.net/p/inkscape/mailman/message/32095902/>

I don't know what their implementation is, but for people who need a workaround for PNG export, the IE browser does not have this problem. If you open the attached SVG file on IE you will see the pentagon "pixels" render seamlessly without blending with the solid fill background. PNG export also produces a correct output.

I have confirmed this workaround so far only on IE. It does not work on Chrome, for example.

Another necromancy on this 12 year old topic. It CAN be solved with anti-aliasing on.
Or should I say there is a workaround.

Anti-aliasing creates semi-transparent subpixels, and if they are next to eachother they work as if two objects with 50% transparency were overlayed one atop another: the background shows through, as the transparencies are not adding up.

But if those two are pulled in with an image filter primitive, you can composite with arithmetic rendering mode whith k2 and k3 set to 1. That way the semi-transparent pixels alpha values add up and there won't be gaps.

Here is an example of the compositing:
https://openclipart.org/detail/250219/compositeadd

And here is one more oriented to practiacal use:
https://openclipart.org/detail/262016/compositing-test-with-filtering-2

As you can see it is way too complicated pulling in every object in a group with image filter primitives.
So it's more of a feature request:
let's have an "additive alpha compositing group mode".

Either implemented by generating a custom filter with image filter primitives for each objects inside a group,
or, getting this feature into the svg specs so that the renderer renders the objects automatically as described without any further filter fiddling in the files.

Hi - thanks for reporting this bug, It's been migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at
https://inkscape.org/report .

Moved to: https://gitlab.com/inkscape/inkscape/-/issues/928
Closed by: https://gitlab.com/greytomorrow