Message: previous - next
Month: June 2012

Re: [trinity-devel] Corrupt image files in gwenview sources

From: "E. Liddell" <ejlddll@...>
Date: Mon, 18 Jun 2012 13:14:08 -0400
On Mon, 18 Jun 2012 09:47:07 -0700 (PDT)
Darrell Anderson <humanreadable@...> wrote:

> > In this case, Firefox reveals the error:
> > 
> > XML Parsing Error: prefix not bound to a namespace
> > Location:
> > 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?

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.

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