Message: previous - next
Month: June 2012

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

From: "E. Liddell" <ejlddll@...>
Date: Mon, 18 Jun 2012 16:55:18 -0400
On Mon, 18 Jun 2012 11:39:39 -0700 (PDT)
Darrell Anderson <humanreadable@...> wrote:

> > 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:
> Bug report 1053 filed. At the moment I left open the question of whether the 
>svg is corrupt. E. suspects possible corruption, but the fact that karbon opens 
>the file without hesitation motivated me to leave the question open (and I don't 
>have a clue whether the file is clean or corrupt :-) ). Possibly the file is okay and 
>the problem is gwenview or the ksvg rendering back engine. Both gwenview and 
>ksvg should get reviewed to resolve the crash with that particular file.

The file is not exactly corrupt, in that it contains well-formed XML
that is clearly exactly what was written by Sodipodi however many
years ago.  The problem is that it isn't *valid* XML--it contains
elements and attributes not present in the standard, and doesn't follow
the protocol for extending it.

In other words, the file is not standards compliant.  However, the
gwenview and Konqueror renderer(s) are not compliant either.  Proper 
behaviour for an SVG parser encountering an error is specified at:
A compliant parser should be capable of opening a bad file, but
will stop rendering when an error is encountered, which explains
why Karbon, etc. don't blow up when presented with this monstrosity.

Trying to trace the code to find what's actually doing the parsing is
giving me a headache. :( ksvg is very carefully split up internally in a
way that I'm sure made sense to the authors, but is completely
opaque to me.