I have independently generated a simple patch that is in the direction of  solving, but does not solve, this bug. To keep things consolidated I will post here.

I have attached a patch that removes pstoedit and instead uses the libpoppler based program pdf2svg. There is still a bug in the script after the patch, that I am unable to quite figure out, however the SVG file is *generated* correctly, it just isn't imported properly. 

to manipulate the pdf files I have to use dvipdf instead of dvips. However dvipdf does not support the -E flag,  it still may be possible (strace?) to work out the ghostscript command that dvipdf uses (I think it uses GS... I'm not an expert in this area).

I have attached the diff for eqtexsvg.py -- although this file seems to differ slightly between releases, so line numbering may be out.

**SNIP***
Hello,

I use inkscape on a variety of platforms, including Fedora Linux and Mac OSX. My applications are typically engineering/scientific in nature - as such I have tried to use the "render latex formula" plugin for inkscape, which I believe is bundled with the latest inkscape in the OSX distribution, and with several other distributions as well.

The operation of this seems to rely on a python script which uses the external program pstoedit to perform an SVG conversion:

    113         os.system('pstoedit -f plot-svg -dt -ssp ' + ps_file + ' ' + svg_file + '> ' + out_file)
    114         svg_open(self, svg_file)

The problem with this is that currently the  pstoedit program does not, by default support the plot-svg by default, but rather by the use of a proprietary extension (plugin). This plugin is only available as a binary module -- thus you cannot readily port it to other platforms (eg mac), and some distrubtions wont accept proprietary plugins (fedora).

My suggestion is that recently there has been another conversion utility developed that uses libpoppler known as pdf2svg (http://www.cityinthesky.co.uk/pdf2svg.html). This is a freely available utility that is released under the GPL, and thus distributions such as fedora, could include it in their standard release. The script could be changed, with minimal effort, to use this this utility to generate the SVG output, allowing for a wider range of platforms -- particularly those that cannot use the proprietary binary object that is required for pdf2svg..


I have attached a patch to do this, but don't know where to send it, so I have emailed you directly.

Unfortunately there is a problem with this patch, the svg that is generated is not opened correctly, so all you get is a black rectangle when the scripts complete, however the SVG itself is fine -- if you manually open it it works like a charm. I am not a python programmer, and I am sufficiently unfamiliar with the SVG manipulations that the script performs to correct this error.

If you are able to provide me with some feedback on the progress for this I would also be most appreciative; I hope it may be included in future inkscape releases!

Kind Regards.


**REPLY from Aaron Spike***

mycae wrote:
> Hello,
>
> I use inkscape on a variety of platforms, including Fedora Linux and
> Mac OSX. My applications are typically engineering/scientific in
> nature - as such I have tried to use the "render latex formula"
> plugin for inkscape, which I believe is bundled with the latest
> inkscape in the OSX distribution, and with several other
> distributions as well.
>
> The operation of this seems to rely on a python script which uses the
> external program pstoedit to perform an SVG conversion:
>
> 113         os.system('pstoedit -f plot-svg -dt -ssp ' + ps_file + '
> ' + svg_file + '> ' + out_file) 114         svg_open(self, svg_file)
>
> The problem with this is that currently the  pstoedit program does
> not, by default support the plot-svg by default, but rather by the
> use of a proprietary extension (plugin). This plugin is only
> available as a binary module -- thus you cannot readily port it to
> other platforms (eg mac), and some distrubtions wont accept
> proprietary plugins (fedora).
>
> My suggestion is that recently there has been another conversion
> utility developed that uses libpoppler known as pdf2svg
> (http://www.cityinthesky.co.uk/pdf2svg.html). This is a freely
> available utility that is released under the GPL, and thus
> distributions such as fedora, could include it in their standard
> release. The script could be changed, with minimal effort, to use
> this this utility to generate the SVG output, allowing for a wider
> range of platforms -- particularly those that cannot use the
> proprietary binary object that is required for pdf2svg..

Did you know that the latest versions of Inkscape include poppler
powered PDF import? Perhaps Ted knows of a way to use our native PDF
import routines and thereby remove any dependency on external PDF to SVG
tools.

> I have attached a patch to do this, but don't know where to send it,
> so I have emailed you directly.

Please attach your patch to the Inkscape bug tracker on Launchpad.
https://bugs.launchpad.net/inkscape/
It probably wouldn't hurt to send a mail similar to this one to the
inkscape-devel mailing list to inform prospective testers that the patch
is there.

> Unfortunately there is a problem with this patch, the svg that is
> generated is not opened correctly, so all you get is a black
> rectangle when the scripts complete, however the SVG itself is fine
> -- if you manually open it it works like a charm. I am not a python
> programmer, and I am sufficiently unfamiliar with the SVG
> manipulations that the script performs to correct this error.
>
> If you are able to provide me with some feedback on the progress for
> this I would also be most appreciative; I hope it may be included in
> future inkscape releases!

I have to confess that I am very unfamiliar with latex. But removing the
dependency on pstoedit is a fantastic idea that will be a huge benefit
for many users. So please continue to pursue this.

If you search the mailing list archives you will find that there have
been a number of other latexy import/export plugins in the work. It
would be wonderful to consolidate effort in this area.

Thank you,

Aaron Spike