GNOME Bugzilla – Bug 316614
stroke pattern does not scale
Last modified: 2005-10-10 19:12:14 UTC
Version details: also reproduced in 2.4.0 rsvg does not seem to scale the stroke-pattern of lines, so the gaps become larger (in relation to the rest of the image) if the image is rendered to a lower resolution. This can badly brake the appearance of the image, especially when rendered very small. I stumbeled across this one while testing the new SVG support of Wikipedia (well, MediaWiki, actually), which uses rsvg. Here are a few examples of the bug: http://commons.wikimedia.org/wiki/Image_talk:Hypercardioidpattern.svg#Rendering_bug Link to SVG source: http://upload.wikimedia.org/wikipedia/commons/0/0a/Hypercardioidpattern.svg I have tested that image with other renderers (sodipode, adobe plugin, ImageMagick), which seem all to scale the dash pattern with the rest of the image (although some screw up other aspects of the rendering). See also report in MediaWiki's bugtracker: http://bugzilla.wikimedia.org/show_bug.cgi?id=3488
i can't reproduce this. i get exactly the same image from batik 1.5.1 and rsvg.
Created attachment 53164 [details] good rendering by batik 1.6 (java -jar batik-rasterizer.jar -d test.100.png -m image/png -w 100 Hypercardioidpattern.svg)
Created attachment 53165 [details] broken rendering by rsvg 2.4.0 (rsvg -w 100 -h 100 Hypercardioidpattern.svg test.rsvg.100.png)
I don't know about batik 1.5.1, but 1.6 renders the image fine, and the dash pattern is scaled, unlike in the rendering by rsvg (see the files attached). Scaling is required by the SVG spec, as I understand it, see http://www.w3.org/TR/SVG/painting.html#StrokeProperties This is a real problem for wikipedia's SVG support. Please have another look. Maybe this is DPI-Related?
reopening, see previous comment. Sorry to be insistent...
Created attachment 53167 [details] broken rendering by rsvg 2.11.1 (via MediaWiki) attachment to illustrate that this is still broken in 2.11.1. BTW: that the 8-shape in the middle renders fine now, as opposed to 2.4.0 - but that's not subject of this bug report. The stroke pattern still does not scale.
Everything works fine with the cairo backend in HEAD. I don't think we will ever fix this for libart though.
agreed. i'm going to consider this FIXED.
B.t.w. Just in case you were wondering related to the whole closing it before business we do see the original problem and the cairo backend does fix it for real ;)
Thanks for the heads-up! I guess we'll just have to live with it for now... or switch to batik.
You could upgrade to cvs head with the cairo backend. It's probably just as stable as 2.12.x and a hell of a lot faster a nicer looking. The only problem is you have to live without filters, but nobody used them before anyway.
I agree 100% with Caleb. Configure the CVS HEAD version with --without-art, and please ignore the "The libart backend wasn't enabled" warning. This version is much faster and more correct. We currently don't handle filters, but that's about all that's missing.