On Fri, Sep 23, 2005 at 06:47:40PM -0300, bulia byak wrote:
And one more simple to fix but critical bug is that ill2svg.pl has been broken for a long time - there were lots of bugs on that, here's the latest one:
https://sourceforge.net/tracker/index.php?func=detail&aid=1302072&gr...
Any Perl experts willing to have a look?
I have spent much of the day looking into all of the ill2svg.pl issues. I have been able to close a number of them.
There are actually two completely different Illustrator file formats. One is an EPS-based format used in Illustrator version 7 and earlier. The other is a PDF-based format used in version 8 and later.
ill2svg.pl will ONLY support the EPS-based format. The way it is written it will _never_ be able to parse PDF-based files. Several of the bugs are about failures to load the newer Illustrator files. It looks like one particular branch of code gets hit most often when loading the binary PDF files, so I've added a better error message with a reminder that ill2svg does not work on PDF-based files. Hopefully this will at least make future bug reports more clear as to their cause.
I also added a bit of error handling to prevent the errors encountered in a couple of the other bugs. This doesn't actually solve the root cause but at least will eliminate some of the confusing "Use of uninitialized..." errors and replace them with something more tangible - "This file is not supported by ill2svg..."
I've also read through the ill2svg.pl program. This code is really fragile, and the fact that it works at all is surprising. It is a brute force Postscript parser, and while it may well work for certain Postscript files, I cannot imagine it would work for all files.
I'm rather dismayed at the extensive lack of error checking in this file. There are LOTS of cases that will cause errors, incompatibilities, incomplete feature support, and so forth. This script is very high-maintenance. If we want to continue to use ill2svg.pl I would recommend it be massively redesigned to be more robust.
Honestly, I think it would be better for us to discard ill2svg.pl and seek out some other alternative for importing Illustrator files.
Since Illustrator files are basically just EPS or PDF files, I think if we had good tools for reliably importing EPS and PDF files, we would be set. Since we need better support for those two formats anyway, I think this would pay off several times over.
Next, I searched online for existing EPS and PDF conversion programs. Ideally would be eps2svg and pdf2svg converters. The former does not exist afaik; the latter exists but doesn't produce svg that will work with inkscape. There are commercial tools that promise to perform these conversions; I did not test them and do not consider them options.
I also tested Scribus. Scribus has **very good** EPS and PDF import support, and an SVG export capability that works **very well** with Inkscape. This was the only option that produced acceptable results.
Unfortunately, Scribus does not have commandline import/export capabilities, so it is not a drop-in replacement for ill2svg.pl. However, I was able to close a number of bug reports that simply needed capabilities that could be obtained through use of scribus.
I then investigated the feasibility of adding commandline import/export capabilities to Scribus. I think it can be done, however I don't know enough about its plugin architecture to implement it myself. I submitted a patch to Scribus to sketch out what we need; I am hoping that completing the feature will be more straightforward for them than it is for me.
Earlier we had also considered the option of extracting the pdf code from scribus for use in inkscape directly. I also investigated this. They have placed the pdf code in a libpdf/ directory that in theory should be extractable; it still depends on Qt, however, so I don't think it would be trivial to port it, as we'd need to convert it to use STL and so forth. Also, even if we did this, it would impose a dependency for inkscape on scribus. If we used the cmdline extension mechanism, then it would be a soft, optional dependency, like we have to skencil. If the user needed the functionality, they could install scribus; if they can do without, they would not need to install it.
I notice they implement all of their import/export code as DLL plugins. In theory I suppose we could dynamically link to these. However, they also have some Qt-isms built in, so I'm uncertain it would be feasible to link against them.
Anyway, to summarize:
1. Ditch ill2svg.pl. It sucks. 2. Encourage scribus to implement -i / -e and add it as an extension. Scribus kicks ass.
Bryce