Optimized SVG is corrupt

[Rena Kunisaki]

When saving a complex image as Optimized SVG, paths and dimensions may be corrupted.
1) Open attached document.
2) Save a copy as optimized SVG.
3) Compare the images; the optimized version now has a vertex moved near the upper left corner producing a large black triangle across the image, and the page size is very small; 2x3 pixels in my case.

[su_v (suv-lp)]

In parts reproduced with Inkscape 0.47 and 0.47+devel r9456 on OS X 10.5.8:

- The corruption of the upper left path still happens with r9456 but to a lesser degree (see attached file).
- The page size stays unchanged in both 0.47 and r9456. Using default settings for the 'Optimized SVG' options I can't reproduce the 2x3 px size.

<off-topic>
@JazzyNico - scour.py in r9456 (with default export options) fails with

Traceback (most recent call last):
  File "scour.inkscape.py", line 54, in <module>
    e.affect(output=False)
  File "/Volumes/blue/src/Inkscape/src/inkscape-repo/mp-x11/Build/share/inkscape/extensions/inkex.py", line 215, in affect
    self.effect()
  File "scour.inkscape.py", line 47, in effect
    sys.stdout.write(scourString(input.read(), self.options).encode("UTF-8"))
  File "/Volumes/blue/src/Inkscape/src/inkscape-repo/mp-x11/Build/share/inkscape/extensions/scour.py", line 2306, in scourString
    embedRasters(elem, options)
  File "/Volumes/blue/src/Inkscape/src/inkscape-repo/mp-x11/Build/share/inkscape/extensions/scour.py", line 1950, in embedRasters
    if options.infilename: infilename = options.infilename
AttributeError: Values instance has no attribute 'infilename'

because the linked images are missing on my harddrive. Saving as 'Optimized SVG' only works after either unchecking 'Embed rasters' or removing the broken image links (Scour in 0.47 doesn't complain).
</off-topic>

[jazzynico (jazzynico)]

><off-topic>...</off-topic>

Scour in 0.47 doesn't complain because it doesn't embed images...

Anyway, upper left corruption confirmed on Windows XP, Inkscape 0.47 (scour 0.22) and revision 9433 (scour 0.24).
Embedding issue also confirmed with revision 9433.

[Louis Simard (louis-simard-deactivatedaccount)]

[Scour] This bug seems to have been fixed in my branch. I'll isolate the bug using the corrupt optimised SVG provided by ~suv.

[Louis Simard (louis-simard-deactivatedaccount)]

Just to be sure, which application did you use to render the SVG files for your comparison? I see no such "large black triangle" in your image, but I do see the green at the upper-left corner "bleed" a lot.

I'm running Eye of GNOME from Ubuntu Karmic with a librsvg containing a fix for bug 370061. This may actually affect your rendering a lot.

[Louis Simard (louis-simard-deactivatedaccount)]

The green path in question started with a moveto followed by relative linetos. Look for this in the optimised file provided by ~suv:

"m-77-115.09,1.2188,250.94,3.6562-5.0938,4.875-5.2812c-0.24412,0.12322

Scour, as released in Inkscape 0.47, doesn't calculate the start point of the second path command (c) correctly. It thinks the curve should be relative to (-77 -115.09), *skipping* the implied linetos.

This bug has been fixed in revision 23 of the linked Scour branch. To work around it in your file, you may add 'l' (lower case L) right after the two coordinates of 'm' in each of your source file's paths.

[su_v (suv-lp)]

> which application did you use to render the SVG files
> for your comparison?

comment #2:
Inkscape 0.47, Inkscape 0.47+devel r9456, Squiggle (Batik 1.7) / OS X 10.5.8,
comment #3:
Inkscape 0.47 (scour 0.22) and revision 9433 (scour 0.24) / Windows XP

> I see no such "large black triangle" in your image,
> but I do see the green at the upper-left corner "bleed" a lot.

In Inkscape change to 'Outline' or 'No Filter' view mode: without the SVG filter effect (Blur) you can see that some points of the path are displaced.

> I'm running Eye of GNOME from Ubuntu Karmic with a librsvg
> containing a fix for bug 370061. This may actually affect
> your rendering a lot.

(Inkscape's reference SVG renderer is Batik (or Adobe), not librsvg). See attached screenshot of '587746-svgcorrupttest-r9456-optimized.svg' in Inkscape (r9490): the nodes are actually misplaced, and it is not the Inkscape rendering issue as described in bug #370061 comment #4.

[Louis Simard (louis-simard-deactivatedaccount)]

So this bad node issue, in Inkscape, is not merely caused by Scour's output being bad for the input file?

If so, sorry about the Inkscape status change; I thought the Scour output caused the Inkscape bug. I won't touch that status anymore :)

[su_v (suv-lp)]

> So this bad node issue, in Inkscape, is not merely caused by Scour's output
> being bad for the input file?

The incorrect node positions as shown in the screenshot attached to comment #7 are the result of Scour's output, not an Inkscape error (I didn't reload the bug page before adding my previous comment and missed your analysis, sorry about that).

Changing the bug status to 'Invalid' for Inkscape was correct IMHO :)

[su_v (suv-lp)]

@JazzyNico - how do we handle bug status in Inkscape if bug is fixed outside Inkscape, but needs backporting/updating in Inkscape's trunk too?

[jazzynico (jazzynico)]

@~suv - If I plan to backport this fix, I change the status to "In progress" and assign the bug to myself until I commit the fix in Inkscape. Else I think it should be marked "Triage".

But are we sure the bug is fixed in scour? I reproduced it with scour r171, which is also used in the dev version, on Windows XP (see comment #4).

I'm going to test again on Ubuntu 10.04 with the standalone scour version.

[su_v (suv-lp)]

> But are we sure the bug is fixed in scour?

See comment #6:

Louis Simard wrote on 2010-06-08:
> This bug has been fixed in revision 23 of the linked Scour branch

The fix is in a different branch than Scour trunk: <lp:~louis-simard/scour/rework>

[jazzynico (jazzynico)]

> See comment #6:

Oh, I'm feeling a bit tired today ;)

[jazzynico (jazzynico)]

Fix confirmed in Louis's branch.
I commit it in Inkscape as soon as it's merged with the trunk.
Thanks!

[Louis Simard (louis-simard-deactivatedaccount)]

@JazzyNico, ~suv: Based on the lack of response to Scour bug 428069 and the Launchpad blueprints for Scour, I'd say the fix won't be in Scour trunk for a while. If this fix is important enough, isolate it from lp:~louis-simard/scour/rework revision 23 and import it into Inkscape before the trunk gets merged. I may even help you do that by giving a patch for you to use.

[Louis Simard (louis-simard-deactivatedaccount)]

Assigned myself to the bug as I was the one to fix it. I'm hesitating to say Fix Committed for this, because it's in a separate branch and not in trunk.

[codedread (codedread)]

Hi folks - sorry for the delay here, starting a new job this week.

Louis, would you like permissions to commit to the scour trunk?

Jeff

On Wed, Jun 9, 2010 at 12:53 PM, Louis Simard
<email address hidden>wrote:

> Assigned myself to the bug as I was the one to fix it. I'm hesitating to
> say Fix Committed for this, because it's in a separate branch and not in
> trunk.
>
> ** Changed in: scour
> Status: Confirmed => In Progress
>
> ** Changed in: scour
> Assignee: (unassigned) => Louis Simard (louis-simard)
>
> --
> Optimized SVG is corrupt
> https://bugs.launchpad.net/bugs/587746
> You received this bug notification because you are the registrant for
> Scour.
>
> Status in Inkscape: A Vector Drawing Tool: In Progress
> Status in Scour - Cleaning SVG Files: In Progress
>
> Bug description:
> When saving a complex image as Optimized SVG, paths and dimensions may be
> corrupted.
> 1) Open attached document.
> 2) Save a copy as optimized SVG.
> 3) Compare the images; the optimized version now has a vertex moved near
> the upper left corner producing a large black triangle across the image, and
> the page size is very small; 2x3 pixels in my case.
>
>
>

[Louis Simard (louis-simard-deactivatedaccount)]

@codedread: If that's not too much trouble, and you trust me enough with the commits I've made already to my branch.

I'll be responsible and create branches for fixes, or just patches attached to bug reports, but I'll have you know that I've already managed to lose the contents of my branch as I was starting out with bzr - Scour was actually the first project I needed bzr for. Now I should be ok with trunk access, but I never know.

[Louis Simard (louis-simard-deactivatedaccount)]

A fix for this bug has been merged into lp:scour, revision 172. Thanks for having reported this bug and made Scour better.