I have read in the roadmap that snapping to objects is slated for version 0.48 of Inkscape. However, I have a problem now which I think may be related to this and I would be grateful for any assistance or pointers anyone could give me.
I am using Inkspace 0.43 under Mac OS X 10.4.3.
I want to be able to generate PNGs on the fly with Cocoon, so I have SVG templates which I create with Inkspace and transform with XSLT. That part works well.
However, I have noticed that contiguous objects in the template are often rendered with a gap between them. Inkspace does this itself when I zoom in on the image, and the Batik rasterizer does it too. I can't overlap the objects at all because they are partially transparent.
Is there a way of fixing this problem with Inkspace? Or is it a feature? Of SVG?
Regards Steve
What's this Inkspace? ;-)
On Wed, Jan 04, 2006 at 07:04:36PM +0100, Stephen Winnall wrote:
I am using Inkspace 0.43 under Mac OS X 10.4.3.
I want to be able to generate PNGs on the fly with Cocoon, so I have SVG templates which I create with Inkspace and transform with XSLT. That part works well.
However, I have noticed that contiguous objects in the template are often rendered with a gap between them. Inkspace does this itself when I zoom in on the image, and the Batik rasterizer does it too. I can't overlap the objects at all because they are partially transparent.
Is there a way of fixing this problem with Inkspace? Or is it a feature? Of SVG?
Regards Steve
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
I should add the following:
I think this is the result of a rounding error because the problem only seems to occur in Inkscape (sorry, Bryce:-) at zoom factors which are not multiples of 2 (i.e. 50% and 250% but not 800%, 1600% etc.). I'm not sure about Batik: it's written in Java, so I presume it's a completely different implementation.
Steve
On 4 Jan 2006, at 19:04, Stephen Winnall wrote:
I have read in the roadmap that snapping to objects is slated for version 0.48 of Inkscape. However, I have a problem now which I think may be related to this and I would be grateful for any assistance or pointers anyone could give me.
I am using Inkspace 0.43 under Mac OS X 10.4.3.
I want to be able to generate PNGs on the fly with Cocoon, so I have SVG templates which I create with Inkspace and transform with XSLT. That part works well.
However, I have noticed that contiguous objects in the template are often rendered with a gap between them. Inkspace does this itself when I zoom in on the image, and the Batik rasterizer does it too. I can't overlap the objects at all because they are partially transparent.
Is there a way of fixing this problem with Inkspace? Or is it a feature? Of SVG?
Regards Steve
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Quoting Stephen Winnall <stephen.winnall@...1452...>:
However, I have noticed that contiguous objects in the template are often rendered with a gap between them. Inkspace does this itself when I zoom in on the image, and the Batik rasterizer does it too. I can't overlap the objects at all because they are partially transparent.
Is there a way of fixing this problem with Inkspace? Or is it a feature? Of SVG?
If the objects truly are mathematically abutting, you may be getting bitten by a common implementation technique for antialiasing. You are likely to always get a very faint hairline in those cases.
However, since the effect you observe is dependent on zoom, it sounds like the objects are not quite touching. Without knowing more about the structure and arrangement of the document, I'm not sure of the best solution to making them touch.
In either case, SVG is not to blame per se.
-mental
I seem to have solved the problem: I simply selected all the elements which were contiguous and used Inkscape's "combine" command.
I like Inkscape, even if I can't always remember its name correctly. Thanks to the developers.
Steve
On 4 Jan 2006, at 20:30, mental@...32... wrote:
Quoting Stephen Winnall <stephen.winnall@...1452...>:
However, I have noticed that contiguous objects in the template are often rendered with a gap between them. Inkspace does this itself when I zoom in on the image, and the Batik rasterizer does it too. I can't overlap the objects at all because they are partially transparent.
Is there a way of fixing this problem with Inkspace? Or is it a feature? Of SVG?
If the objects truly are mathematically abutting, you may be getting bitten by a common implementation technique for antialiasing. You are likely to always get a very faint hairline in those cases.
However, since the effect you observe is dependent on zoom, it sounds like the objects are not quite touching. Without knowing more about the structure and arrangement of the document, I'm not sure of the best solution to making them touch.
In either case, SVG is not to blame per se.
-mental
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id%16865&op=click _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Quoting Stephen Winnall <stephen.winnall@...1452...>:
I seem to have solved the problem: I simply selected all the elements which were contiguous and used Inkscape's "combine" command.
Ah, interesting. That does sound like an antialiasing artifact...
I like Inkscape, even if I can't always remember its name correctly.
Heh, it's natural. I named the thing, and even I was calling it "Inkspace" occasionally for the first few months.
Thanks to the developers.
From me and all the rest: you're quite welcome. :)
-mental
On 5 Jan 2006, at 01:07, mental@...32... wrote:
Quoting Stephen Winnall <stephen.winnall@...1452...>:
I seem to have solved the problem: I simply selected all the elements which were contiguous and used Inkscape's "combine" command.
Ah, interesting. That does sound like an antialiasing artifact...
I looked around for anything to do with antialiasing, but I couldn't find anything which was obvious to me. I am an SVG newbie though. Is it likely that Mac OS X was doing something? The hairline occurred in the following programs: Inkscape, Squiggle (Batik), Safari - but not in Inkscape's Icon Preview.
Steve
Quoting Stephen Winnall <stephen.winnall@...1452...>:
I looked around for anything to do with antialiasing, but I couldn't find anything which was obvious to me.
There's surprisingly little written on the issue I had in mind... It's not something with your document, though -- basically just a shortcoming of a common technique used by many renderers (simulating partial pixel coverage via the alpha channel).
The workaround is to combine the shapes or overlap them (when possible).
I am an SVG newbie though. Is it likely that Mac OS X was doing something?
Pretty unlikely... most of those apps have their own renderers rather than relying on OS facilities.
Any chance you could post the version of the document with the hairline (or even just a simplified document that shows the problem) so I could examine it to confirm my theory?
-mental
On 5 Jan 2006, at 01:52, mental@...32... wrote:
Any chance you could post the version of the document with the hairline (or even just a simplified document that shows the problem) so I could examine it to confirm my theory?
The following minimal SVG demonstrates the problem. I actually tidied up the coordinates in the semicircle's path with the XML editor so it was clear that the objects were mathematically contiguous: Inkscape itself was not so precise. But the problem also occurs with the SVG generated by Inkscape. If you zoom the object to 100% (it is then quite small) you will see the hairline. If you zoom it to N x 100%, where N is a multiple of 2, there is no hairline. At all other zoom factors there is a hairline.
Note that the objects have no stroke defined. I thought this might be a factor in the problem, but adding a stroke didn't seem to make any difference (I didn't complete that exercise though).
Steve
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!-- Created with Inkscape (http://www.inkscape.org/) --> <svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="60" height="17" id="svg" sodipodi:version="0.32" inkscape:version="0.43" version="1.0" sodipodi:docbase="/Users/steve/Temporary" sodipodi:docname="sample-with-gap.svg"> <defs id="defs" /> <sodipodi:namedview id="base" pagecolor="#ffffff" bordercolor="#666666" borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="9.33033" inkscape:cx="29.93078" inkscape:cy="-1.6075655" inkscape:document-units="px" inkscape:current-layer="button" inkscape:window-width="1440" inkscape:window-height="874" inkscape:window-x="0" inkscape:window-y="0" inkscape:guide-points="false" showgrid="false" inkscape:grid-bbox="false" inkscape:grid-points="false" guidetolerance="0px" /> <metadata id="metadata"> rdf:RDF <cc:Work rdf:about=""> dc:formatimage/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> </cc:Work> </rdf:RDF> </metadata> <g inkscape:label="Button" inkscape:groupmode="layer" id="button" style="display:inline"> <path style="fill:#000000;fill-opacity:0.7" d="M 8.5,1 L 51.5,1 L 51.5,16 L 8.5,16 L 8.5,1 z " id="rect2463" /> <path style="fill:#000000;fill-opacity:0.7" d="M 8.5,16 C 4.36,16 1,12.64 1,8.5 C 1,4.36 4.36,1 8.5,1 C 8.5,1 8.5,1 8.5,1" id="path1769" /> </g> </svg>
On Thu, 2006-01-05 at 11:55 +0100, Stephen Winnall wrote:
On 5 Jan 2006, at 01:52, mental@...32... wrote:
Any chance you could post the version of the document with the hairline (or even just a simplified document that shows the problem) so I could examine it to confirm my theory?
The following minimal SVG demonstrates the problem. I actually tidied up the coordinates in the semicircle's path with the XML editor so it was clear that the objects were mathematically contiguous: Inkscape itself was not so precise.
Sorry I took so long to get back to you; I've been swamped for the past week. Thank you very much for taking the time to put together a minimal example of the problem.
I can see it is indeed the rendering issue I suspected; the hairline is an artifact of an antialiasing technique used by Inkscape and many other vector graphics renderers.
Essentially, a shape partially covering a pixel is simulated by making that pixel semi-transparent. This looks acceptable in most cases, but there are a few cases it behaves badly for -- exactly adjacent edges, for example.
Here's the deal: when the border between the two shapes doesn't fall exactly on the boundary between pixels (this is why zoom or scrolling can make a difference), you end up with one shape covering part of a pixel, and the other shape covering the remainder.
Shape A: Shape B:
+---+---+ +---+---+ |AAA|...| |...|BBB| |AAA|...| |...|BBB| +---+---+ +---+---+
Obviously, if we overlap these, we should get a pixel whose color is 50% A and 50% B, right?
+---+---+ |AAA|BBB| |AAA|BBB| +---+---+
Well... problem is that by the time they're combined, the renderer has already flattened these partially-covered pixels into flat pixels with transparency (alpha). The information about which portions of the pixel are covered by which colors is lost.
Using only the alpha information, if you composite A at 50% alpha, and B at 50% alpha, you get a pixel whose color is 25% the background color, 25% A, and 50% B (assuming B is "above" A in the stack). Hence, a one-pixel seam of 25% background color shows through...
There are better antialiasing methods available which don't exhibit this problem, but they are less often used because they are generally slower (so are likely to see the problem with other renderers too).
We can't really do anything about how it'll appear in other renderers, but Inkscape should probably implement one of the better antialiasing methods as a special "high-quality" rendering mode.
-mental
Thanks for the feedback. For me, using "combine" was the solution to the problem. You only really need to implement the high-quality rendering mode to fix this problem if there is a situation where you don't want to combine contiguous objects. I can't think of such a situation, but I'm an amateur at SVG...
Steve
On 13 Jan 2006, at 05:39, MenTaLguY wrote:
On Thu, 2006-01-05 at 11:55 +0100, Stephen Winnall wrote:
On 5 Jan 2006, at 01:52, mental@...32... wrote:
Any chance you could post the version of the document with the hairline (or even just a simplified document that shows the problem) so I could examine it to confirm my theory?
The following minimal SVG demonstrates the problem. I actually tidied up the coordinates in the semicircle's path with the XML editor so it was clear that the objects were mathematically contiguous: Inkscape itself was not so precise.
Sorry I took so long to get back to you; I've been swamped for the past week. Thank you very much for taking the time to put together a minimal example of the problem.
I can see it is indeed the rendering issue I suspected; the hairline is an artifact of an antialiasing technique used by Inkscape and many other vector graphics renderers.
Essentially, a shape partially covering a pixel is simulated by making that pixel semi-transparent. This looks acceptable in most cases, but there are a few cases it behaves badly for -- exactly adjacent edges, for example.
Here's the deal: when the border between the two shapes doesn't fall exactly on the boundary between pixels (this is why zoom or scrolling can make a difference), you end up with one shape covering part of a pixel, and the other shape covering the remainder.
Shape A: Shape B:
+---+---+ +---+---+ |AAA|...| |...|BBB| |AAA|...| |...|BBB| +---+---+ +---+---+
Obviously, if we overlap these, we should get a pixel whose color is 50% A and 50% B, right?
+---+---+ |AAA|BBB| |AAA|BBB| +---+---+
Well... problem is that by the time they're combined, the renderer has already flattened these partially-covered pixels into flat pixels with transparency (alpha). The information about which portions of the pixel are covered by which colors is lost.
Using only the alpha information, if you composite A at 50% alpha, and B at 50% alpha, you get a pixel whose color is 25% the background color, 25% A, and 50% B (assuming B is "above" A in the stack). Hence, a one-pixel seam of 25% background color shows through...
There are better antialiasing methods available which don't exhibit this problem, but they are less often used because they are generally slower (so are likely to see the problem with other renderers too).
We can't really do anything about how it'll appear in other renderers, but Inkscape should probably implement one of the better antialiasing methods as a special "high-quality" rendering mode.
-mental
Quoting Stephen Winnall <stephen.winnall@...1452...>:
You only really need to implement the high-quality rendering mode to fix this problem if there is a situation where you don't want to combine contiguous objects.
I can't think of such a situation, but I'm an amateur at SVG...
One of the most common places for this to come up is when people are trying to use shapes with different gradients for various visual effects.
For example, someone might want to put a radial gradient on the semicircle, and a linear gradient on the rectangle. Once they were lined up properly, it'd look like a shiny cylinder with a rounded end.
-mental
participants (4)
-
unknown＠example.com -
Bryce Harrington -
MenTaLguY -
Stephen Winnall