After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165063 - Can't import SVG paths from Illustrator (replace XML parser)
Can't import SVG paths from Illustrator (replace XML parser)
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.2.x
Other All
: Normal normal
: Future
Assigned To: GIMP Bugs
GIMP Bugs
: 603412 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-24 09:07 UTC by Felix
Modified: 2018-05-24 11:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
3 SVG files created with AI CS (7.88 KB, application/x-compressed-tar)
2005-01-24 15:10 UTC, Felix
Details

Description Felix 2005-01-24 09:07:08 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
Comment 1 Raphaël Quinet 2005-01-24 12:28:15 UTC
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.
Comment 2 Simon Budig 2005-01-24 13:36:32 UTC
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.
Comment 3 Sven Neumann 2005-01-24 15:05:57 UTC
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)
Comment 4 Felix 2005-01-24 15:10:43 UTC
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
Comment 5 Simon Budig 2005-01-24 15:22:25 UTC
(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.
Comment 6 Sven Neumann 2005-01-24 15:26:04 UTC
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.
Comment 7 Felix 2005-01-24 15:29:17 UTC
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?
Comment 8 Sven Neumann 2005-01-24 15:35:03 UTC
Felix, as we have explained already, these libraries are not involved when
importing a path. So why would you want to update them?
Comment 9 Raphaël Quinet 2005-01-24 16:03:39 UTC
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.
Comment 10 Simon Budig 2005-01-24 16:23:59 UTC
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.
Comment 11 Felix 2005-01-24 16:27:33 UTC
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.
Comment 12 Raphaël Quinet 2005-01-24 16:43:58 UTC
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...  :-(
Comment 13 Sven Neumann 2005-01-27 18:59:15 UTC
So would there be strong objections if we added libxml2 as a dependency for GIMP
2.4?
Comment 14 Sven Neumann 2005-03-05 01:30:12 UTC
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.
Comment 15 weskaggs 2006-05-21 18:15:04 UTC
This has been sitting untouched for quite some time.  Can something be done about it quickly, or should the milestone be bumped?
Comment 16 Sven Neumann 2006-06-27 18:08:50 UTC
Since noone has started to work on this yet, I am moving it to the 2.6 milestone.
Comment 17 Martin Nordholts 2008-05-28 18:10:22 UTC
No interest in fixing it for 2.6, probably no interest in fixing it for 2.8. Milestone Future it is (in Yoda-voice).
Comment 18 Sven Neumann 2009-11-30 21:12:39 UTC
*** Bug 603412 has been marked as a duplicate of this bug. ***
Comment 19 GNOME Infrastructure Team 2018-05-24 11:23:49 UTC
-- 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.