Why can't Inkscape import eps?
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
On 2007-August-20 , at 19:11 , John R. Culleton wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
Inkscape can import it... sort of. Inkscape (on Linux and OS X at least, don't know the status on Windows) can call pstoedit which converts the EPS to SVG for Inkscape to edit. There are a few glitches associated with editing files after the conversion but most are sorted by simply copy pasting the output of pstoedit into a new Inkscape instance. Pstoedit does not do a perfect job at converting EPS files but it is usually pretty good.
JiHO --- http://jo.irisson.free.fr/
On 20/08/07 19:59:43, jiho wrote:
On 2007-August-20 , at 19:11 , John R. Culleton wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
Inkscape can import it... sort of. Inkscape (on Linux and OS X at least, don't know the status on Windows) can call pstoedit which converts the EPS to SVG for Inkscape to edit. There are a few
Is there also a free / open source plugin for pstoedit that allows svg-output? Using the extra library for linux from pstoedit it says:
svg: .svg: scalable vector graphics (license key needed, see pstoedit manual) (no valid key found) (/usr/local/lib/pstoedit/plugins_linux.3.42.so)
By the way: Would pstoedit allow to import a vector graphic from a pdf-file to svg/inkscape?
Lynx
On 8/20/07, lynx.abraxas@...1631... <lynx.abraxas@...1631...> wrote:
On 20/08/07 19:59:43, jiho wrote:
On 2007-August-20 , at 19:11 , John R. Culleton wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
Inkscape can import it... sort of. Inkscape (on Linux and OS X at least, don't know the status on Windows) can call pstoedit which converts the EPS to SVG for Inkscape to edit. There are a few
Is there also a free / open source plugin for pstoedit that allows svg-output? Using the extra library for linux from pstoedit it says:
svg: .svg: scalable vector graphics (license key needed, see pstoedit manual) (no valid key found) (/usr/local/lib/pstoedit/plugins_linux.3.42.so)
By the way: Would pstoedit allow to import a vector graphic from a pdf-file to svg/inkscape?
Lynx
SVN has direct pdf import in it. Gotta love Googles Summer of Code :) Miklos has done a great job on it, works a treat.
On 2007-August-20 , at 20:35 , lynx.abraxas@...1631... wrote:
On 20/08/07 19:59:43, jiho wrote:
On 2007-August-20 , at 19:11 , John R. Culleton wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
Inkscape can import it... sort of. Inkscape (on Linux and OS X at least, don't know the status on Windows) can call pstoedit which converts the EPS to SVG for Inkscape to edit. There are a few
Is there also a free / open source plugin for pstoedit that allows svg-output? Using the extra library for linux from pstoedit it says:
svg: .svg: scalable vector graphics (license key needed, see pstoedit manual) (no valid key found) (/usr/local/lib/pstoedit/plugins_linux.3.42.so)
By the way: Would pstoedit allow to import a vector graphic from a pdf-file to svg/inkscape?
Yes there is, the pstoedit device is called "plot-svg" and the plugin is in a package usually called "plotutils".
Cheers,
JiHO --- http://jo.irisson.free.fr/
John R. Culleton schrieb:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it? Is there a technical problem in creating an import filter?
short question long answer ...
-PS/EPS is a whole programming language with loops sub-routines etc. -this makes it rather complex to generate a good converting result -all known importers (pstoedit) that inkscape uses are based on ghostscript that is known to be an good importer -that needs ghostscript installed on your system as this is not a part of inkscape -so there is no real need to invent the wheel a second time
btw there is a postscript rendering library called hieryglyph http://hieroglyph.freedesktop.org/wiki/ . Maybe this one can replace the usage of ghostscript one day
HTH,
Adib.
On 8/20/07, John R. Culleton <john@...1668...> wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it?
Because converting between vector formats is very difficult. It's nothing like converting between bitmap formats. It's more like rewriting an arbitrarily complex program from one programming language to another.
Anyway, as others mentioned, development version has very good support for PDF and AI import. Just use PDF as much as possible and avoid PS/EPS.
On Monday 20 August 2007, bulia byak wrote:
On 8/20/07, John R. Culleton <john@...1668...> wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it?
Because converting between vector formats is very difficult. It's nothing like converting between bitmap formats. It's more like rewriting an arbitrarily complex program from one programming language to another.
Anyway, as others mentioned, development version has very good support for PDF and AI import. Just use PDF as much as possible and avoid PS/EPS.
pdf is easy to make from eps. I have Inkscape 45. What version do I need?
On 8/20/07, John R. Culleton <john@...1668...> wrote:
pdf is easy to make from eps. I have Inkscape 45. What version do I need?
You need a recent development version, not 0.45.
On Monday 20 August 2007, bulia byak wrote:
On 8/20/07, John R. Culleton <john@...1668...> wrote:
pdf is easy to make from eps. I have Inkscape 45. What version do I need?
You need a recent development version, not 0.45.
Well I tried, but didn't succeed.
The most recent version August 19, doesn't show pdf on the import selection menu but does show ps and eps. But ps, eps and pdf type files won't import or open. Do I have to download or update something else to make it work?
Otherwise I guess I need to wait for a new stable release to use the pdf import feature.
Strangely enough the command line install of Inkscape worked better from a gui terminal session as a user than from a regular console session as root. The root run offered strange error messages, like: Cannot find "*".
Incksape uses autopackage, Sciribus uses Cmake, most other packages still use ./configure followed by make. We are I fear headed for a kind of tower of Babel with install methods on Open source programs.
On 8/21/07, John R. Culleton <john@...1668...> wrote:
The most recent version August 19, doesn't show pdf on the import selection menu but does show ps and eps.
Look for "Adobe PDF [via poppler]". If you don't have it in the list, it's likely that you're actually running an old version. Go to Help > About to see the date of the build you're running.
On Tuesday 21 August 2007, bulia byak wrote:
On 8/21/07, John R. Culleton <john@...1668...> wrote:
The most recent version August 19, doesn't show pdf on the import selection menu but does show ps and eps.
Look for "Adobe PDF [via poppler]". If you don't have it in the list, it's likely that you're actually running an old version. Go to Help > About to see the date of the build you're running.
Help About shows the version 45 splash screen, with this in the upper right corner: Inkscape 0.45+devel, built Aug 19 2007
I find Adobe Ilustrator in the menu but no Adobe PDF [via Poppler]
I'll check at the Inkscape home site but right now I cna't get to it. Some sort of cache problem.
Incksape uses autopackage, Sciribus uses Cmake, most other packages still use ./configure followed by make. We are I fear headed for a kind of tower of Babel with install methods on Open source programs.
I don't think we are, for two reasons.
The first is that I remember when almost every project used the same build system, and that build system consisted of editing the Makefiles by hand for your platform. If you were lucky, the project's INSTALL file gave you hints on how to correctly set the make variables, and told you what libraries it depended on. If you were unlucky, you found out when make failed, and still couldn't tell whether it needed a library you didn't have or was just looking in the wrong place. I often complain about build systems being hard to use as a developer, but for a user it's definitely got much easier. A proliferation of build systems is better than none at all.
The second reason is simply that it doesn't matter if projects use different build systems, because they very rarely need to communicate with each other. The only cost in using projects with different build systems is that you have to have all their build systems installed rather than just one.
On Tuesday 21 August 2007, Daniel Hulme wrote:
Incksape uses autopackage, Sciribus uses Cmake, most other packages still use ./configure followed by make. We are I fear headed for a kind of tower of Babel with install methods on Open source programs.
I don't think we are, for two reasons.
The first is that I remember when almost every project used the same build system, and that build system consisted of editing the Makefiles by hand for your platform. If you were lucky, the project's INSTALL file gave you hints on how to correctly set the make variables, and told you what libraries it depended on. If you were unlucky, you found out when make failed, and still couldn't tell whether it needed a library you didn't have or was just looking in the wrong place. I often complain about build systems being hard to use as a developer, but for a user it's definitely got much easier. A proliferation of build systems is better than none at all.
I disagree that multiple build systems make it easer for the user. This is I think an oxymoron. A common configure/build system is easier almost by definition.
The second reason is simply that it doesn't matter if projects use different build systems, because they very rarely need to communicate with each other. The only cost in using projects with different build systems is that you have to have all their build systems installed rather than just one.
I am a member of the user class. Multiiple install methods mean that in addition to becoming skilled at using the programs themselves one must become reaquainted with the details and the gotchas of a particular build method every six months or so. I use TeX, Scribus, Gimp, Krita, Inkscape etc. in my publishing endeavours. Six months from now will I remember that the packaging system used by Inkscape works better in command line mode from a gui window than from a console session? Will I be able to find the email that tells how to use cmake for Scribus? Is it KDE or Koffice that I have to reinstall to upgrade Krita? And so on. The genius of Unix has always been that if you knew how to manipulate one Unix you were 90% familar with running another. The genius of Open Source software has always been that you downloaded the tarball, ran ./configure, make and make install and it worked every time (barring missing libraries of course). You never even had to read the install guide.
I don't expect to change the course already decided on for Inkscape. But it comes with a cost for the user. And ultimately that will hurt acceptance of the product. There is more than one package I have downloaded where the build process and the unexpected dependencies wove such a tangle that I gave up and went on to something else.
John R. Culleton wrote:
The genius of Open Source software has always been that you downloaded the tarball, ran ./configure, make and make install and it worked every time (barring missing libraries of course). You never even had to read the install guide.
Feel free to do this with Inkscape. I create Autopackages as a convenience for people who don't want to build from source. You are certainly welcome to ./configure, make, make install. And if you read the install guide, you may not be missing any libraries by the time make comes around. :-)
Aaron Spike
On Tue, Aug 21, 2007 at 01:50:04PM -0400, John R. Culleton wrote:
On Tuesday 21 August 2007, Daniel Hulme wrote:
The first is that I remember when almost every project used the same build system, and that build system consisted of editing the Makefiles by hand for your platform. If you were lucky, the project's INSTALL file gave you hints on how to correctly set the make variables, and told you what libraries it depended on. If you were unlucky, you found out when make failed, and still couldn't tell whether it needed a library you didn't have or was just looking in the wrong place. I often complain about build systems being hard to use as a developer, but for a user it's definitely got much easier. A proliferation of build systems is better than none at all.
I disagree that multiple build systems make it easer for the user. This is I think an oxymoron. A common configure/build system is easier almost by definition.
I wouldn't go as far as saying it's an oxymoron, but it's not what I said. Multiple build systems make it easier for the user, when the alternative is having to configure everything by hand. Obviously, having one Platonic ideal build system would be much easier for the user, but you might as well wish for one all-purpose programming language, or an ideal political system. Having lots, each with its own advantages and shortcomings, is a good intermediate step on the path from having nothing useful to having the perfect one.
I am a member of the user class. Multiiple install methods mean that in addition to becoming skilled at using the programs themselves one must become reaquainted with the details and the gotchas of a particular build method every six months or so. I use TeX, Scribus, Gimp, Krita, Inkscape etc. in my publishing endeavours. Six months from now will I remember that the packaging system used by Inkscape works better in command line mode from a gui window than from a console session? Will I be able to find the email that tells how to use cmake for Scribus? Is it KDE or Koffice that I have to reinstall to upgrade Krita? And so on.
If you have to remember all of that in order to compile the software, the build system obviously isn't working properly. What you're telling me here isn't that there are too many build systems, it's that these particular build systems are too hard to use. Maybe I should write a new one...
The genius of Unix has always been that if you knew how to manipulate one Unix you were 90% familar with running another.
Having had to run an autobuilder that compiled for various Unix-like OSes like Solaris, AIX, and *BSD, of varying ages, I'm not sure I can agree with that. Even today, as a Debian user, if a SuSE or Red Hat user comes to me for help on a system administration task, I probably can't help him.
The genius of Open Source software has always been that you downloaded the tarball, ran ./configure, make and make install and it worked every time (barring missing libraries of course). You never even had to read the install guide.
Perhaps I use different software to you, but it seems to me that as recently as five years ago I still had to hand-edit Makefiles to build from tarred sources. Having a gadget that works out all the correct settings for you is still enough of a blessing to me that I don't mind if I have to prod it a bit.
I don't expect to change the course already decided on for Inkscape. But it comes with a cost for the user. And ultimately that will hurt acceptance of the product. There is more than one package I have downloaded where the build process and the unexpected dependencies wove such a tangle that I gave up and went on to something else.
I'm sorry to hear that. Were there no binaries available for that product? I think people, on the whole, are willing to use the binaries that come with their distribution. (I exclude Windows users, of course, who have to rely on vendor-supplied binaries.) Those who aren't mostly switch to Gentoo, whose ebuilds provide a unified user-interface to build systems in the manner you seem to be longing for.
On 2007-August-20 , at 22:09 , John R. Culleton wrote:
On Monday 20 August 2007, bulia byak wrote:
On 8/20/07, John R. Culleton <john@...1668...> wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it?
Because converting between vector formats is very difficult. It's nothing like converting between bitmap formats. It's more like rewriting an arbitrarily complex program from one programming language to another.
Anyway, as others mentioned, development version has very good support for PDF and AI import. Just use PDF as much as possible and avoid PS/EPS.
pdf is easy to make from eps. I have Inkscape 45. What version do I need?
You need a development snapshot. You can get one from there: http://inkscape.modevia.com/ Beware however that these versions are potentially less stable than the official versions of Inkscape.
JiHO --- http://jo.irisson.free.fr/
On Mon, 20 Aug 2007 15:18:48 -0400, "bulia byak" <buliabyak@...155...> wrote:
On 8/20/07, John R. Culleton <john@...1668...> wrote:
EPS is AFAIK a vector format. svg is a vector format. So why can't Inkscape import it?
Because converting between vector formats is very difficult. It's nothing like converting between bitmap formats. It's more like rewriting an arbitrarily complex program from one programming language to another.
It isn't just that -- in the case of EPS, specifically, it really is a programming language. There's no way to write a general-purpose EPS importer without implementing the entire PostScript runtime to execute EPS files.
It's possible to leverage an existing runtime like Ghostscript (which is what pstoedit does), but I know from personal experience that there's still an awful lot of glue that needs to go in to make it usable.
This issue is one of the reasons that Adobe switched to PDF instead of EPS -- it's much easier to implement PDF import because it is much simpler than a general-purpose programming language like PostScript. And, indeed, PDF import is one of our SoC projects this summer.
-mental
participants (9)
-
unknown＠example.com -
Aaron Spike -
Adib Taraben -
bulia byak -
Daniel Hulme -
jiho -
john cliff -
John R. Culleton -
MenTaLguY