> 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-gvdirpart.svg
> 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