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