18 Jun
2012
18 Jun
'12
4:47 p.m.
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.
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. 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
Darrell
