Unable to open SVG in Inkscape
Hi guys, The attached file (our company logo) renders fine with librsvg, but inkscape seems unable to even load it. Any ideas why?
Christian
The error message that Inkscape gives is quite descriptive:
fluendologo.svg:102: parser error : Extra content at the end of the document ) ^
Remove that closing parenthesis at the end and it will open fine.
On Mon, 07 Feb 2005 18:15:55 +0100, Christian Fredrik Kalager Schaller <uraeus@...45...> wrote:
Hi guys, The attached file (our company logo) renders fine with librsvg, but inkscape seems unable to even load it. Any ideas why?
Christian
On Mon, 7 Feb 2005, bulia byak wrote:
Date: Mon, 7 Feb 2005 13:26:13 -0400 From: bulia byak <buliabyak@...400...> To: Christian Fredrik Kalager Schaller <uraeus@...45...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Unable to open SVG in Inkscape
The error message that Inkscape gives is quite descriptive:
fluendologo.svg:102: parser error : Extra content at the end of the document ) ^
Remove that closing parenthesis at the end and it will open fine.
Seems odd that such a minor deviation would cause Inkscape to fail. I guess I would have expected the stray ) to simply be ignored.
Presumably this indicates a greater underlying problem?
- Alan H
Quoting Alan Horkan <horkana@...44...>:
Seems odd that such a minor deviation would cause Inkscape to fail. I guess I would have expected the stray ) to simply be ignored.
Presumably this indicates a greater underlying problem?
No, it's working as designed. The XML standard doesn't permit a ) there, full stop. We don't want to enter the morass of permissive-by-default parsing.
Now, what would be nice is if a file fails to load due to invalid XML, the user gets a dialog like this:
-----------------------------------------------
This file is damaged. Do you want to try to automatically repair it? Some data may not be recoverable.
| Cancel | [ Repair Document ]
-----------------------------------------------
..at which point Inkscape would retry parsing the file with a more "permissive" XML parser, and mark the document as dirty when first loaded. Similar actions for other gross violations of validity might be nice too.
One important property of the "permissive parser" would be to preserve anything it doesn't understand as an XML comment (rather than throwing it away), to permit further hand-recovery if the automatic recovery isn't sufficient.
Could someone please capture this in an RFE?
-mental
On Mon, 7 Feb 2005 mental@...3... wrote:
Date: Mon, 7 Feb 2005 14:47:43 -0500 From: mental@...3... To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Unable to open SVG in Inkscape
Quoting Alan Horkan <horkana@...44...>:
Seems odd that such a minor deviation would cause Inkscape to fail. I guess I would have expected the stray ) to simply be ignored.
Presumably this indicates a greater underlying problem?
No, it's working as designed. The XML standard doesn't permit a ) there, full stop. We don't want to enter the morass of permissive-by-default parsing.
Given the abomination that is Internet Explorer I can undestand the need to be strict about imports.
Now, what would be nice is if a file fails to load due to invalid XML, the user gets a dialog like this:
I'd go for a slightly more terse wording (and I wouldn't bother saying try or automatic) but this is an excellent idea.
This file is damaged, would you like to repair it? | Cancel | [ Repair Document ]
..at which point Inkscape would retry parsing the file with a more "permissive" XML parser, and mark the document as dirty when first loaded. Similar actions for other gross violations of validity might be nice too.
I was trying to think of something like this but you figured out the improtant part about marking the document dirty (or alternatively giving it a whole new name).
One important property of the "permissive parser" would be to preserve anything it doesn't understand as an XML comment (rather than throwing it away), to permit further hand-recovery if the automatic recovery isn't sufficient.
that sounds like an excellent feature.
- Alan H.
Quoting Alan Horkan <horkana@...44...>:
I'd go for a slightly more terse wording (and I wouldn't bother saying try or automatic) but this is an excellent idea.
This file is damaged, would you like to repair it? | Cancel | [ Repair Document ]
Some extra explanation is needed to manage expectations. Given an arbitrary corrupt document, here's no guarantee that whatever heuristics the permissive parser applies won't still produce garbage or simply fail outright in nontrival cases.
From a user's perspective, it's a matter of:
"Hey, I can't load this file because it's damaged, but I might be able to recover some data for you. Do you want me to try?"
versus
"Hey, this file is damaged but I can magically fix it for you. Do you want me to fix it?"
Per most HIGs, "This file is damaged, try to repair it?" should probably be bold heading; the remainder of the explanatory text would be presented in smaller text at normal weight.
-mental
participants (4)
-
unknown＠example.com -
Alan Horkan -
bulia byak -
Christian Fredrik Kalager Schaller