GNOME Bugzilla – Bug 165063
Can't import SVG paths from Illustrator (replace XML parser)
Last modified: 2018-05-24 11:23:49 UTC
Please describe the problem: I can't import paths in .svg format exported from Illustrator CS I work on MAC OS X (10.3.7) I use Gimp 2.2.3 I tried exporting RGB and CMYK, I also tried ISO8859, UTF8 and UTF16 encodings. It always fails. Steps to reproduce: 1. Create a closed path in Illustrator and save it as .svg 2. Try to import from Gimp 2.2.3 3. Gimp fails to import it Actual results: Gimp error message: "entity 'ns_svg' at line 7 unknown" or similar Expected results: Import 1 or more (merged) paths Does this happen every time? I downloaded some SVG samples. Sometimes Gimp import them correctly, some others it fails (i.e. "entity 'st4' unknown) Other information: I believe Gimp should skip unnecesary information in .svg files Thank you
This looks like a problem in librsvg (the library that reads SVG files). What version of librsvg are you using? You should have at least version 2.8.0.
Importing Paths does not use librsvg. SVG paths get imported by a subset-of-XML-parser which AFAIK can not handle entity references completely. Unfortunately the SVG files created by illustrator make heavy use of Entities. It actually doesn't surprise me that Gimp has trouble importing these files. Felix: Please attach a sample of a problematic file.
I cannot handle entity references at all. We would have to port this code to a real XML parser. There are two possible ways to fix this: - let GIMP depend on libxml2 (or another full-featured XML library) - add the vectors PDB API that is needed and implement vectors import in a plug-in (which would then depend libxml2)
Created attachment 36450 [details] 3 SVG files created with AI CS The file name indicates the codification: TEST_01_ISO.svg TEST_02_UTF8.svg TEST_03_UTF16.svg
(the attachment actually is a tar.gz archive of the three mentioned files, please use three separate attachments in the future). When looking at these files the interesting thing is, that the path itself is represented by a regular "polygon" tag. So it might be possible to handle these with a bit more generous handling of unresolved entities.
Simon, what is wrong about attaching a tar.gz archive? As long as the mime-type is specified properly (which is the case here), that's the preferred way to attach multiple files.
My librsvg: Package: librsvg Version: 1.0.3 Revision: 13 My librsvg2: Package: librsvg2 Version: 2.4.0 Revision: 4 Do you need more details? How can I upgrade those libraries? With Fink?
Felix, as we have explained already, these libraries are not involved when importing a path. So why would you want to update them?
It should not be too hard to let the parser handle the entities: just push them in a glist and substitute when needed. I have done similar tricks in my XMP parser, based on gmarkup. (By the way, thanks Felix for the second file, which contains XMP metadata with an encoding of the thumbnail that I had not found before. That will help me to test my metadata editor.) I don't think that it should be too hard to implement some basic support for entities. Sven, do you want me to hack on this? Re comment #6: When the number of files is small (2 or 3) and the file format is supported by some browsers, then it may be better to attach the files separately. Putting them in a tar file requires some extra steps for viewing. Re comment #7: Sorry for introducing the confusion. You do not need to change your libraries.
Raphaël, unfortunately I learned that it is not easy. The code is in glib/glib/gmarkup.c and there is no way to hook into the gmarkup code to resolve the entities. And adding such a hook is not possible since it would break binary compatibility for glib.
When Raphaël wrote that I should at least have version 2.8.0 I understood I should better upgrade it, but if importing Paths does not use librsvg, I understand that it is not neccesary.
Simon: you are right. Detecting and remembering the entity declarations is easy because gmarkup provides a hook for that. Unfortunately, the problem is that gmarkup does not provide any hook for decoding unknown entities. I overlooked that minor detail... :-(
So would there be strong objections if we added libxml2 as a dependency for GIMP 2.4?
It seems that expat would be completely sufficient for our needs and we already depend on it, by means of fontconfig. So it appears that expat would be an even better choice unless someone comes up with something that absolutely needs a DOM interface.
This has been sitting untouched for quite some time. Can something be done about it quickly, or should the milestone be bumped?
Since noone has started to work on this yet, I am moving it to the 2.6 milestone.
No interest in fixing it for 2.6, probably no interest in fixing it for 2.8. Milestone Future it is (in Yoda-voice).
*** Bug 603412 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/121.