GNOME Bugzilla – Bug 333057
stroke-widths thinner than 0.11pt (declared in css) are rendered incorrectly
Last modified: 2006-03-02 01:13:14 UTC
Please describe the problem: Using a CSS style with a stroke-width thinner than 0.11pt will cause librsvg to render the stroke with a width of about 1pt. .foo {stroke:#000000;stroke-width:0.11pt;fill:none} <-- ok, 0.11pt stroke .bar {stroke:#000000;stroke-width:0.1pt;fill:none} <-- not ok, ~1pt stroke Note that this problem does not occur when using a non-css style: style="stroke:#000000;stroke-width:0.1pt;fill:none" <-- ok Steps to reproduce: 1. rsvg-convert stroke-test.svg > stroke-test-librsvg.png 2. eog stroke-test-librsvg.png Actual results: See attached output Expected results: See batik output Does this happen every time? Yes Other information:
Created attachment 60431 [details] Testcase of different stroke widths
Created attachment 60432 [details] stroke-test.svg rasterized with batik (reference)
Created attachment 60433 [details] stroke-test.svg rasterized with librsvg
In rsvg-styles.c:926 (where we do CSS handling), we get back from libcroco: expr = (gchar *)cr_term_to_string (a_expr); (gdb) p expr $5 = (gchar *) 0x8bd8e18 "1pt" In other words, this initially looks like a bug in libcroco. I'm reassigning.
There's some shady logic in cr_tknzr_parse_num () and possibly cr_utils_n_to_0_dot_n (). The "int_part" vs. "dec_part" is guaranteed to be wrong for (example) "0.09", as it will produce: int_part: 0 dec_part: 9 Converting that to a double produces 0.9
Created attachment 60444 [details] [review] not the prettiest thing in the world... But it gets the job done. If it (or another suitable fix) isn't not committed in a day or two, I guess that I'll commit it.
Created attachment 60446 [details] [review] preferable patch
No commits since 1 year in libcroco's CVS. I'll commit this myself.