Render Latex Equation fails in Linux distributions

[Bug Importer]

The Render Latex equation Extension fails.
The python file eqtexsvg.py fails in two places:

1. This escript calls latex with -output-directory
option wich does not exist in common Latex Linux
distributions.
It can be solved easily avoiding the -output-directory
option using python commands to manage the generated files.

2. This script calls pstoedit with -f svg option but
standar pstoedit for Linux distributions do not include
a svg driver!! This driver must be installed
separately, and seems to be quite hard to find it out
for free.

Good work.

Raul Durand.
<email address hidden>

[Fbreuer (fbreuer)]

First of all I would like to say: There is interested in a
working Linux version of this feature!

Apart from that: Is a linux SVG plugin for pstoedit only
"hard to find" or nonexistent? The only page regarding SVG
plugins for pstoedit I was able to find is
http://www.pstoedit.net/plugins and that one contains only
shareware for Windows as well as Linux.

[Tovrstra (tovrstra)]

There is an additional problem with the temporary filename
creation. The temporary directory is located correctly, but
the the same filename is used every time the script is run.
This is problematic in the following situation:

* user Alice logs in and tries to use the latex extension,
but it fails and some files are not removed correctly.
* consequently user Bob logs in and also tries to use the
latex extension. It will always file because the temporary
files of Alice can not be removed/overwritten.

[Bug Importer (bug-importer)]

The script calls pstoedit with the "-f svg" option, which
doesn't work on any of the various Fedora installations I've
used it on. But it *does work* with the "-f plot-svg"
option. The only problem is, the script doesn't process the
resulting svg file correctly. So, if I make a .tex file with
an equation in it, latex that file, call dvips the same way
the script would, and then invoke pstoedit (just like in the
script, but with the -f plot-svg option), the result is an
svg file that inkscape will happily import. So, it seems
like the equation plugin could be tweaked to work in Linux.

[Bug Importer (bug-importer)]

The -f plot-svg option doesn't work on FC5. The free
version of pstoedit supports many other output formats which
Inkscape already knows how to import. Perhaps that would be
the best solution.

I also want to second that there is much interest in getting
this feature to work under Linux. Currently I end up using
sklatex and skencil to create a .sk file and then import
that in to Inkscape. It would be MUCH nicer to just render
the equations directly in Inkscape!

[Bug Importer (bug-importer)]

The " -f plot-svg " option is definitely working for me in
FC5/rawhide, though it may have picked up a dependency that
I compiled and which was not included by default in FC5 or
devel. Either way, it can be made to work, and if I recall
it didn't involve installing anything like an svg plugin. If
that's the case, the plugin just needs to be reworked.

If I manually change "svg" to "plot-svg" in the plugin, I
only get the last character of the equation inserted into
the document, and it's upside-down. So somewhere in there,
where it's stripping characters or lines from the temporary
svg file that pstoedit makes, it's messing something up.
There's probably some simple difference in the svg that's
produced by "-f plot-svg", versus "-f svg".

[Wolfiq (wolfiq)]

Hi,

a debian user reported about not-rendering latex formulas
and said:

Effects->Render->LaTeX formula does not produce anything,
but prints on the
stderr/stdout the following message:

(inkscape:12862): GLib-CRITICAL **: g_utf8_collate:
assertion `str2 !=
NULL' failed
Extension::Script: Unknown error for pclose
: Success

This seems to be the symptom of the bug discussed here.
pstoedit in debian supports plot-svg instead of svg. Can't
the effect changed to use this?

Thanks,

Wolfi

[Wolfiq (wolfiq)]

Ah, I forgot the link to the bug report:
http://bugs.debian.org/376558

And I think we should add this to the known problems-section
in the release notes.

Yours,

Wolfi

[Rwst (rwst)]

this error (giving you nonsense in stderr) was fixed
recently. if you're interested in the real error message,
try a snapshot or svn head.

[Wolfiq (wolfiq)]

OK, tried SVN head from yesterday, got to compile only
today. The error is:
pstoedit: version 3.44 / DLL interface 108 (build Mar 11
2006 - release
build - g++ 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)) :
Copyright
(C) 1993 - 2006 Wolfgang Glunz
Traceback (most recent call last):
  File "/tmp/share/inkscape/extensions/eqtexsvg.py", line
121, in ?
    e.affect()
  File "/tmp/share/inkscape/extensions/inkex.py", line 123,
in affect
    self.effect()
  File "/tmp/share/inkscape/extensions/eqtexsvg.py", line
107, in effect
    svg_open(self, svg_file)
  File "/tmp/share/inkscape/extensions/eqtexsvg.py", line 49, in
svg_open
    svg = open(filename, 'r')
IOError: [Errno 2] No such file or directory:
'/tmp/inkscape-latex.tmp.svg'

So it seems to me that inkscape pstoedit fails to create
inkscape-latex.tmp.svg from the ps-file. The tex-files are
there: inkscape-latex.tmp.{tex,aux,ps,dvi,log}.
This alone looks as security bug to me since I can easily
guess names of temporary files.

Thanks,

Wolfi

[Roman Dubtsov (busa-ru)]

I'm the one who reported the problem into debian bugzilla.

here's the diff for eqtexsvg.py, which
a) uses better (still silly) svg parsing technique
b) does better tmp file creation
c) uses plot-svg pstoedit driver to produce svgs
d) does not use -output-dir with latex, but the solution is
*nix only =(

diff -urNBb inkscape1.44.orig/share/extensions/eqtexsvg.py
inkscape-0.44/share/extensions/eqtexsvg.py
--- inkscape-0.44.orig/share/extensions/eqtexsvg.py
2006-07-06 23:11:01.000000000 +0700
+++ inkscape-0.44/share/extensions/eqtexsvg.py 2006-07-06
23:14:56.000000000 +0700
@@ -27,7 +27,7 @@

 """

-import inkex, os, tempfile
+import inkex, os, tempfile, xml.dom.minidom

 def create_equation_tex(filename, equation):
     tex = open(filename, 'w')
@@ -44,42 +44,28 @@
     tex.close()

 def svg_open(self,filename):
- # parsing of SVG file with the equation
- # real parsing XML to use!!!! it will be easier !!!
- svg = open(filename, 'r')
- svg_lines = svg.readlines()

-
- # trip top/bottom lines from svg file
- svg_lines.pop(0)
- svg_lines.pop(1)
- svg_lines.pop(len(svg_lines)-1)
+ def clone_and_rewrite(self, node_in):
+ if node_in.localName != 'svg':
+ node_out = self.document.createElement('svg:' +
node_in.localName)
+ for i in range(0, node_in.attributes.length):
+ name = node_in.attributes.item(i).name
+ value = node_in.attributes.item(i).value
+ node_out.setAttribute(name, value)
+ else:
+ node_out = self.document.createElement('svg:g')

- group = self.document.createElement('svg:g')
- self.current_layer.appendChild(group)
+ for c in node_in.childNodes:
+ if c.localName in ('g', 'path'):
+
node_out.appendChild(clone_and_rewrite(self, c))

- # deleting "<g... >" "</g>" "<path d=" and "/>" from
svg_lines
- nodegroup=''
- s_nodegroup_path=''
-
- for i in range(1,len(svg_lines)):
- if svg_lines[i].find("<g") != -1:
- nodegroup=svg_lines[i].split("<g")
- nodegroup=nodegroup[1].split(" >")
- nodegroup=nodegroup[0]+'\n'
- elif svg_lines[i].find("<path d=") != -1:
- s_nodegroup_path=svg_lines[i].split("<path d=")
- s_nodegroup_path=s_nodegroup_path[1]

- elif svg_lines[i].find("/>") != -1:
- s_nodegroup_path=s_nodegroup_path+'"\n'
- elif svg_lines[i].find("</g>") != -1:
- nodegroup_svg =
self.document.createElement('svg:g')
- nodegroup_svg.setAttribute('style',nodegroup)
- nodegroup_path =
self.document.createElement('svg:path')
- nodegroup_path.setAttribute('d',s_nodegroup_path)
- group.appendChild(nodegroup_svg)
- nodegroup_svg.appendChild(nodegroup_path)
- else:
- s_nodegroup_path=s_nodegroup_path+svg_lines[i]
+ return node_out
+
+ doc = xml.dom.minidom.parse(filename)
+ svg = doc.getElementsByTagName('svg')[0]
+
+ group = clone_and_rewrite(self, svg)
+ group.setAttribute('transform', 'scale(1000)')
+ self.current_layer.appendChild(gro...

[Wolfiq (wolfiq)]

Yes, tempfile handling is better now but still not good.
Instead of using the PID the best thing would be to use a
random number as part of the file names.

Thanks,

Wolfi

[Roman Dubtsov (busa-ru)]

Could you please tell me, what must be done (improved) with
this patch for it to be included upstream? I'm going to
read svg spec and improve xml parsing and within a week-or-
two. What else?

[Kraznakz (kraznakz)]

Hi everyone.

Thx for inkscape it's such a beautiful piece of software.

I got exactly the same bug and another one. If I input some
"$" in the latex equation window there is a bug after, for
example $\frac{a}{b}$. This plugin should handle latex
formatting and not only equations !!

The code used in skencil latex plugin works flawlessly, both
for normal text and equations. Maybe it could be of some use
in that case.
http://www.2pi.info/latex/sketchlatex/

This plugin is the only reason why I can't switch definitely
to inkscape and stop using 2 tools.

bye

[Stéphane Gimenez (dev-gim)]

Originator: NO

Hi,

I've included the patch from busa_ru to the svn since it's a strict
improvement over the old extension script.
It fixes many issues reported here. In particular, the original bug issues
are fixed by this patch. I'd like to close this bug as soon as the
temporary files issue is fixed. It may remain minor problems for some of
you, I guess the best is to open new specific bugs.

Thanks to busa and everybody out here.

[Stéphane Gimenez (dev-gim)]

Originator: NO

I've done some rewriting of the temporary file management code and I'd
like some testing on different platforms.
Error reporting on invalid LaTeX input was also improved.

I'm attaching the new candidate eqtexsvg.py to this bug.
The latest (revsion 13431) inkex.py script is required:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/inkex.py

Thanks for your help.

[Stéphane Gimenez (dev-gim)]

Other attachments

[Stéphane Gimenez (dev-gim)]

Originator: NO

A new version was committed, it fixes temporary files issues.
It makes no use of python 2.4 subprocess module, in order to remain
compatible with some platforms where python 2.3 is the only one available.
I'm closing this bug now.