After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 316614 - stroke pattern does not scale
stroke pattern does not scale
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
2.11.x
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-18 09:54 UTC by Daniel Kinzler
Modified: 2005-10-10 19:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
good rendering by batik 1.6 (java -jar batik-rasterizer.jar -d test.100.png -m image/png -w 100 Hypercardioidpattern.svg) (2.33 KB, image/png)
2005-10-07 08:36 UTC, Daniel Kinzler
Details
broken rendering by rsvg 2.4.0 (rsvg -w 100 -h 100 Hypercardioidpattern.svg test.rsvg.100.png) (1.36 KB, image/png)
2005-10-07 08:38 UTC, Daniel Kinzler
Details
broken rendering by rsvg 2.11.1 (via MediaWiki) (1.86 KB, image/png)
2005-10-07 09:34 UTC, Daniel Kinzler
Details

Description Daniel Kinzler 2005-09-18 09:54:23 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
Comment 1 Dominic Lachowicz 2005-10-07 02:28:23 UTC
i can't reproduce this. i get exactly the same image from batik 1.5.1 and rsvg.
Comment 2 Daniel Kinzler 2005-10-07 08:36:58 UTC
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)
Comment 3 Daniel Kinzler 2005-10-07 08:38:18 UTC
Created attachment 53165 [details]
broken rendering by rsvg 2.4.0 (rsvg -w 100 -h 100 Hypercardioidpattern.svg test.rsvg.100.png)
Comment 4 Daniel Kinzler 2005-10-07 08:41:30 UTC
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?
Comment 5 Daniel Kinzler 2005-10-07 08:43:10 UTC
reopening, see previous comment. Sorry to be insistent...
Comment 6 Daniel Kinzler 2005-10-07 09:34:51 UTC
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.
Comment 7 Caleb Moore 2005-10-10 18:42:45 UTC
Everything works fine with the cairo backend in HEAD. I don't think we will ever
fix this for libart though.
Comment 8 Dominic Lachowicz 2005-10-10 18:50:20 UTC
agreed. i'm going to consider this FIXED.
Comment 9 Caleb Moore 2005-10-10 18:55:54 UTC
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 ;) 
Comment 10 Daniel Kinzler 2005-10-10 18:58:26 UTC
Thanks for the heads-up! I guess we'll just have to live with it for now... or
switch to batik.
Comment 11 Caleb Moore 2005-10-10 19:08:35 UTC
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.
Comment 12 Dominic Lachowicz 2005-10-10 19:12:14 UTC
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.