GNOME Bugzilla – Bug 670398
Patch for chained fractions in path data
Last modified: 2017-12-13 17:52:23 UTC
Some images like example.svg in the attachment don't render correctly. this happens if two numbers look like this: -1.23.45 (first number is -1.23, the second is 0.45) Changing two lines in rsvg-path.c remedies this.
Created attachment 207980 [details] [review] Proposed patch
Created attachment 207981 [details] example image
*** Bug 683559 has been marked as a duplicate of this bug. ***
Can this patch be merged into librsvg? Open Clip Art Library uses this library and it's causing rendering errors on some of the SVGs
I'm a bit wary to commit because our test suite doesn't work and doesn't cover this code path, so any changes in this intractable code might introduce regressions...
Created attachment 251307 [details] [review] Updated patch This version of the patch corrects the treatment of decimal places in rsvg_parse_path_data. The patch brings the rsvg_parse_path_data function into compliance with section 8.3.9 of the SVG 1.1 spec at http://www.w3.org/TR/SVG/paths.html#PathDataBNF in two ways: 1. The SVG fractional-constant may begin with a decimal place rather than a digit. This is the in_num == FALSE case, and does not cause the end of any current number (as there is no current number before the decimal place occurs). 2. The section below the BNF notes that a "second" decimal place ends the current number and begins a new (positive) fractional number. This is the in_frac == TRUE case, which emits the end of the current number. Both cases are handled in the new "if (in_frac || !in_num)" statement, which initializes a new positive number. Additionally, at the "natural" end of a number (when it is followed by an unknown character), in_frac and in_exp are reset to FALSE. This avoids a condition in which in_num == FALSE but in_frac == TRUE (and similarly with in_exp). I am seeing this problem in optimized SVG files, where leading zeroes have been removed, and particularly when "extra" spaces have been removed. If you require additional test cases, please let me know.
Is there anything that can be done to help merging the previous patch ? This bug is quite critical as many SVG optimiser (like https://github.com/RazrFalcon/SVGCleaner) produce the kind of number sequence described by OP in the first post.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/60.