On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote:
Up spake Ben Crowell:
I don't know if AI's output is standards-compliant in this situation or not. If omitting the type is legal according to the SVG standard, then maybe Inkscape should allow it on input.
Inkscape should probably allow it regardless, since being compatible with AI is nearly as important as being compatible with the spec. We don't have the clout to force AI to fix its mistakes, yet :-)
Yep. If Inkscape allows the user to read noncompliant AI SVG output, and change it into standards-compliant Inkscape SVG, then that's a win for standards. If Inkscape won't let the user do that, then the user has no way of switching to a standards-compliant format. It's not like the situation with browsers, where bug-for-bug compatibility arguably just encourages web sites to use nonstandard HTML. Visiting a broken site with my standards-compliant browser doesn't fix the broken site :-)
I have to agree with that, though upon reading the RFC it's clear that the missing mimetype is interpreted as text/plain by default. So I think Inkscape is correct in its ignoring such images because technically, they're not images but texts. I'm not sure how to "fix" this because we probably use some library call to retrieve images from URIs.
Should just be a question of reading the first four bytes of the file to find out the magic number, and then closing it and calling the appropriate library for that type of file. Does anyone know where in the source code I should look? This is something I'm motivated to try to fix, since I have 660 AI SVG files I'm trying to get working with Inkscape, and many of them have this problem.