On Mon, 18 Jun 2012 08:33:29 -0700 (PDT)
Darrell Anderson <humanreadable@...> wrote:

> > I can view crsc-app-gvdipart.svg and hisc-app-gvdipart.svg
> > in eog without issue. However attempting to open crsc-app-gvdipart.svg in
> > konqueror preview in kde 3.5.10 results in a CRASH that takes konqueror down. This
> > further points to some BUG in the kde/tde svg handling/rendering code. eog opened
> > the svg without any issue and displayed it correctly. kde (and I presume tde as
> > well) viewers crash on the same svg. That suggests to me that the kde/tde svg
> > code lack basic error checking to allow correct loading and display of svg
> > images.
> > 
> > Darrell, if you have eog installed, then conduct the same
> > test. View crsc-app-gvdipart.svg in eog and then attempt to view it in
> > konqueror by rt-clicking and choosing KSVGPlugin. If you get the same
> > crash, then we have a real svg bug in TDE that is a blocker and needs to be fixed
> > for 14. My kde kcrash is attached.
> 
> Yes, at one point during my fiddling I got konqueror to crash too. I was going to post backtraces, but my backtraces all are suspect because they all reference "/dev/shm," which is my tmpfs/$TMP location for building packages. I don't know why my backtraces say that.
> 
> I don't have eog installed and with Slackware, I'd have to build myself (not a stock package). I don't like GTK apps anyway. :-) Besides, karbon opened and saved the image fine, which then gwenview opened without crashing.
> 
> I wonder whether karbon is using different svg algorithms than the embedded svg viewer and gwenview. We have a few bug reports filed about svg. I wonder whether this type of behavior warrants a separate bug report. Or perhaps the bug report should address why some Trinity apps can open svg and some can't and to ensure all use the same algorithms.

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?