There are 6 png and 2 svg files in applications/gwenview/src/gvdirpart.
All png files are unviewable. I can restore the 6 png images from the original 1.4.2 sources. The difference with the png images is one byte in file size, so probably some kind of CR/LF copy error. I have pushed those 6 fixes to GIT.
One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview.
I can open the suspect svg in karbon and resave but before I push that copy I'd be grateful if one of the artists here would look at the file:
applications/gwenview/src/gvdirpart/crsc-app-gvdirpart.svg
I can open the suspect svg in a text editor.
Thanks again!
Darrell
On 06/18/2012 09:41 AM, Darrell Anderson wrote:
There are 6 png and 2 svg files in applications/gwenview/src/gvdirpart.
All png files are unviewable. I can restore the 6 png images from the original 1.4.2 sources. The difference with the png images is one byte in file size, so probably some kind of CR/LF copy error. I have pushed those 6 fixes to GIT.
Using different viewers, I tried eog (eye of gnome) and received the following on the png images:
Could not load image 'cr22-app-gvdirpart.png'. Fatal error reading PNG image file: PNG file corrupted by ASCII conversion
That goes for all the pngs. So your suspicion regarding the crlf type issue is one target.
One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview.
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.
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.
Darrell
On Mon, 18 Jun 2012 08:33:29 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com 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-gvd... 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?
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-gvd... 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?
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:
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
Darrell
On Mon, 18 Jun 2012 09:47:07 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
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-gvd... 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.
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.
Darrell
On Mon, 18 Jun 2012 11:39:39 -0700 (PDT) Darrell Anderson humanreadable@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.
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.
Okay, thanks for clarifying terminology!
I added the w3 link in the bug report.
I am curious what you discover to perhaps explain side-by-side why karbon did not fail and actually rendered the image.
Darrell
Darrell Anderson wrote:
One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview.
Seems the appropriate fix would be to fix the crash in Gwenview instead of changing the file?
Julius
On 18 June 2012 13:47, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Darrell Anderson wrote:
One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview.
Seems the appropriate fix would be to fix the crash in Gwenview instead of changing the file?
Julius
An image should never crash the program - instead the program should say "error this file is corrupt" or something similar.
General rule
Calvin
One of the svg files won't open in gwenview, in Trinity
GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview.
Seems the appropriate fix would be to fix the crash in Gwenview instead of changing the file?
Both. :-)
E. believes the image is corrupt, having been created 7 years ago with software that no longer exists and likely was not complying with whatever svg standards.
The viewer should not crash and should gracefully exit.
Darrell
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
Julius Schwartzenberg