SVG not correctly rendered

Bug #370061 reported by Roman Maurer
30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
librsvg
Fix Released
High
librsvg (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: librsvg2-common

1) OS RELEASE: Ubuntu 9.04.
2) LIBRARY RELEASE: librsvg-2.26.0-0ubuntu1
3) TEST CASE: http://upload.wikimedia.org/wikipedia/commons/3/3c/Obcine_Slovenija_2006_Crensovci.svg
     EXPECTED: something like http://commons.wikimedia.org/wiki/File:Obcine_Slovenija_2006_Crensovci.svg
     (note the red area!)
4) EXPERIENCED: red area is shifted to the left

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/eog
Package: eog 2.26.1-0ubuntu1
ProcEnviron:
 LANG=sl_SI.UTF-8
 SHELL=/bin/bash
SourcePackage: eog
Uname: Linux 2.6.28-11-generic i686

Revision history for this message
Roman Maurer (roman-maurer) wrote :
Revision history for this message
Roman Maurer (roman-maurer) wrote :

This is the way my SVG turns out in eod, inkscape and Gimp.
The red area on the left should be rendered at the right (see Wikimedia Commons link above for the correct rendering).
(Firefox rendering is OK, though.)

Revision history for this message
Lars Ljung (larslj) wrote :

Confirmed in eog, gimp and evince. But Inkscape (0.46-5ubuntu4) looks fine here.

Changed in librsvg (Ubuntu):
status: New → Confirmed
Revision history for this message
Roman Maurer (roman-maurer) wrote :

It's true that Inkscape does not have problems with the red area, so my previous comment was wrong in that point. Sorry and thank you for pointing this out.

However, Inkscape 0.46 has another (different) rendering problem - large areas of white and white stripes in the middle of the picture where there should be none (see attachment). Should I submit another bug for Inkscape separately?

Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

Still present in Ubuntu Lucid's libsrvg. I'm looking at the red path in the file to see if I can't isolate the problem.

Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

Well that was fast.

The problematic data is

> l.6

in

> <g id="obc_015" attrib:ob_ime="Črenšovci" fill="red">

> <path d="M601703.6 -157836.4l.6 6.6l10.1 53.1l-6.7 27.1l-7.3

and I worked around the bug by adding 0 before .6 (== 0.6).

The grammar for path data in the SVG specification [1] says that .6 *is* acceptable, because the digit-sequence before the decimal point is optional:

fractional-constant:
    digit-sequence? "." digit-sequence
    | digit-sequence "."

The parser in librsvg needs to accomodate this. I believe it also doesn't handle -.6 very well either.

Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

Forgot to define [1] in my previous post.

[1] = http://www.w3.org/TR/SVG11/paths.html#PathDataBNF :)

Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

Thanks for having reported this bug and making Ubuntu better!

This was an upstream (GNOME) problem, which has been re-reported independently yesterday; I happened to need it fixed today. What a coincidence! :)

Anyway, I attached a patch, which is also attached in the upstream GNOME bug. Please test it and give feedback in the upstream GNOME bug.

tags: added: patch
Changed in librsvg:
status: Unknown → New
Revision history for this message
xteejx (xteejx-deactivatedaccount) wrote :

The svg renders to png fine in GIMP in Maverick.
gimp version 2.6.8-2ubuntu1.1
librsvg2-2 version 2.26.3-1

Changed in librsvg (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

Teej: So it does. However, a second test case for this bug on the GNOME report fails rendering rather spectacularly, and the failure is due to code in the same function in librsvg. A patch by Thomas W. in the GNOME report now fixes the problem for this bug's test case (Obcine_Slovenija_2006_Crensovci.svg) *and* the GNOME report's test case (emptytrash.svg). It has good chances to be included upstream if so.

Revision history for this message
xteejx (xteejx-deactivatedaccount) wrote :

Cool. If it's included before DIF we should be able to sync/merge it over, or just take the patch directly :)

Revision history for this message
Sebastien Bacher (seb128) wrote :

we can get the change in Ubuntu once it gets in git

Changed in librsvg (Ubuntu):
importance: Undecided → Low
Revision history for this message
Louis Simard (louis-simard-deactivatedaccount) wrote :

This bug has been marked as duplicated on the GNOME tracker. The bug watch is now for the master bug in GNOME.

Changed in librsvg:
status: New → Unknown
Changed in librsvg:
status: Unknown → New
Revision history for this message
David Stansby (dstansby-deactivatedaccount) wrote :

Added the patch-forwarded-upstream tag because the original patch author said the patch was attached to the upstream report.

tags: added: patch-forwarded-upstream
Changed in librsvg:
importance: Unknown → High
Revision history for this message
xteejx (xteejx-deactivatedaccount) wrote :

Since this has been reported upstream, it's probably best to mark this Triaged. Further comments and discussion can be made at the Gnome bug tracker.

Changed in librsvg (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
madbiologist (me-again) wrote :

Fixed in librsvg2-2 2.36.4-1 and eog 3.6.2-0ubuntu1 on Ubuntu 13.04 "Raring Ringtail" (and possibly earlier).

Changed in librsvg (Ubuntu):
status: Triaged → Fix Released
Changed in librsvg:
status: New → Fix Released
Revision history for this message
Iain Lane (laney) wrote :

Don't thikn that was fixed when comment #16 said, but should be with 2.40.6, coming soon.

Changed in librsvg (Ubuntu):
status: Fix Released → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package librsvg - 2.40.6-1

---------------
librsvg (2.40.6-1) experimental; urgency=medium

  * New upstream release 2.40.6.
    - Fix path data number parsing (LP: #370061)

 -- Iain Lane <email address hidden> Wed, 10 Dec 2014 10:09:37 +0000

Changed in librsvg (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.