18 Jun
2012
18 Jun
'12
5:14 p.m.
On Mon, 18 Jun 2012 09:47:07 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
They *should* be line-by-line different. The Sodipodi file is poorly formatted in
addition to being buggy. If the two files *look* the same in a viewer and the new
one doesn't crash Konqueror, I would say it's safe to let the saved-with-Karbon
version stand.
In this case,
Firefox reveals the error:
XML Parsing Error: prefix not bound to a namespace
Location:
http://git.trinitydesktop.org/cgit/gwenview/plain/src/gvdirpart/crsc-app-gv…
Line Number 156, Column 36: id="stop788"
/></linearGradient><path
In other words, there's something wrong with the syntax of
the SVG file. Judging from the
header boilerplate, it was created by Inkscape's predecessor
Sodipodi, and probably predates
the finalization of the standard. I *think* the
problem is actually on the next line
( a:adobe-blending-mode="screen" ) with the a: being the
unrecognized namespace prefix.
Resaving it probably caused this unparseable nonstandard
attribute to be dropped.
But all of this notwithstanding, a parse error should not be
causing an application crash.
My suspicion is that the svg parsing code needs additional
error trapping and maybe some
other work.
Maybe we should slap together an SVG tracker bug?
Good catch. :-)
What is the best way to salvage this specific file? Do you want to tinker with the XML? I
mentioned that I can open in karbon and resave, but the two svg files are very different.
That is, kompare shows the two svg files as being completely different line by line. Is
resaving through karbon sufficient? 
Yes, there should no crashes. If an XML file is
corrupt in a bad way, the viewer should exit gracefully. We need to fix that.
Do we know if there's any generalized XML parsing code being used here, or are
we dealing with something that was created to deal with SVG specifically? If there
is a generalized XML parser, maybe it should be replaced with a better-maintained
and -tested third-party lib (assuming we can find a fairly light one)?
Before we open a bug report, do we have additional
examples of svg(z) files that cause crashes? If we can gather a few more such files then
the bug report becomes meaningful and has hope of being resolved.
If it's a parser bug, we should be able to create some by deleting/corrupting random
sections of
other SVG files (just taking out one of the namespace declarations at the beginning of an
Inkscape
file may be able to reproduce this particular crash, frex). And if all else fails, I
think I have an old
Windows version of Sodipodi on one of my desktop boatanchors (although it might be too old
to
even save SVG!)
Bug reports related to svg:
615 KSVG shows only black previews (Resolved)
1018 [Regression] Konqueror tooltip popup previews do not always show a thumbail image
1022 Add svg(z) support to kuickshow and kview
Also the one about desktop backgrounds.