On Mon, 18 Jun 2012 11:39:39 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> 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:
http://www.w3.org/TR/2001/REC-SVG-20010904/implnote.html#ErrorProcessing
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.