Inkscape Extension ‘svg2tikz’ revisited.

In this earlier posting, I had written about the low-performing 3rd-party Inkscape Extension known as ‘svg2tikz’. Nevertheless, this extension may prove useful to some users, who wish to import an arbitrary document-type into Inkscape – preferably vector-based – and who wish to convert that into LaTeX in some way. And it seems that, even though this project was abandoned some time ago, work has slowly begun to resume on its source-code. And so, I should also fine-tune some of the earlier commentary I had made about this extension.

First off, there is an important detail about how to compile and install this extension, which its devs fail to point out anywhere. It needs to be built and installed, using Python 3, while many Linux computers still default to Python 2.7. Therefore, the commands to build and install it are:


$ python3 build
$ su
# python3 install


If one neglects this detail, then Unicode support is left out, and usually, SVG Files etc., will contain some Unicode characters. Further, as the Github comment states, while the importing of raster-based images is now supported, their import as Base-64 encoded, inline data is not. Therefore, within Inkscape, for example if a PDF File is being imported, the option needs to be unchecked, to ‘Embed’ graphics. And when Saving a Copy to TiKz Format, the option should also be unchecked, to ‘Indent Groups’.

But this last detail leads me to an important, additional observation. I have always known that the export of Text with the Figure has been dodgy. But lately, either because I’ve become more observant, or, because the behaviour of the latest version of the extension has improved, I’ve noticed what, exactly, goes wrong with Exporting Text along with the Figure.

(Updated 2/11/2020, 1h05 … )

(As of 2/8/2020 : )

Within Inkscape, different bodies of text could all have different font-sizes, some 30-point fonts, and others, 8-point fonts. When ‘svg2tikz’ exports them, it gives them all the same, default font-size, that they’d have within the LaTeX / LyX Document. What this means in practice is, that if the Scale of the document is decreased below 1.0, or, if much text was included in a very small font, the text will fail to align properly with the figure. Effectively, the extension is trying to align the text, which is often too large to be aligned.

This can look like an explicit problem with the extension, even though it is not. It’s a problem with default, LaTeX-compatibility.



Further, the devs have disabled the feature, when installing ‘svg2tikz’, to install it as an Inkscape Extension in addition to installing the command-line. Therefore, it must be installed as an actual extension, explicitly by the user, after he has installed it to his System Directories.

In my case, this would not have been necessary because:

  • The actual extension works with Inkscape 0.92 now, and
  • I tend to use the command-line anyway, because I like to give the option ‘--notext‘.

In any case, I’m hoping that work will continue on this extension.

Meanwhile, what some readers may be asking themselves would be, ‘Why bother to import a PDF File as a TiKz-based, TEX File, that is a Child Document to a bigger TEX File? After all, the original PDF File can also first be imported into Inkscape, and then Exported as a plain SVG File, which can just be inserted into modern LyX Documents as such – before which we should place the SVG Image in some sort of Box.’

And the answer which I would give is, the fact that to insert an original document into a LaTeX document, that is really just a graphical image at that point, fails to parse the original contents of the image, which might be desirable. This is yet another reason, why I’d sometimes hesitate to generate an HTML File with inline Base-64 images. Those Base-64 images are rasterized, when in some cases I’d want analytical correctness.

And so, Yes, I’ll sometimes make the effort to edit the actual TiKz File, in order to get results that are approximately correct, such as:


In the TiKz-based, child document / TEX File:


\def \globalscale {1.000000}
\begin{tikzpicture}[y=0.80pt, x=0.80pt, yscale=-\globalscale, xscale=\globalscale, inner sep=0pt, outer sep=0pt]


\def \globalscale {0.500000}
\begin{tikzpicture}[y=0.80pt, x=0.80pt, yscale=-\globalscale, xscale=\globalscale, inner sep=0pt, outer sep=0pt, every node/.style={scale=0.2, text width=0.5*\columnwidth}]

Replace every occurrence of:
'above right' -> 'below right'


And then, this was the LaTeX-derived, PDF File that I obtained:


OTOH, If I were to accept the concept for a moment, that I’m actually going to edit LaTeX by hand (using a text-editor), then I can reform the picture in question to an approximate 4-column format, as shown here:



In case the reader should be curious, as to what LaTeX Files gave rise to the second PDF above, the demo project can be found in this gopher-hole on my server:

The most important of those files, named ‘Leviton-DZPA1-installation-instructions.tex’, arose not because I write such good, voluminous LaTeX, that takes advantage of TiKz, but rather, because the ‘svg2tikz’ extension, which this blog is about, was essentially able to export it from ‘Inkscape’, but in a sufficiently botched state, that I needed to invest a whole day to patch it up.


(Update 2/11/2020, 1h05 : )

There is an observation which I should add, for anybody who would like to get full use of this extension, in the way it exists right now. The way its devs undertook their project, if the extension is to include linked raster-based images, it also wants to convert their filenames to relative URLs, even though the Inkscape Extension API initially offers absolute filenames. While this would be an honourable thing to do, the way the API works on some installations of Linux, does not allow it to be done.

One reason is the fact that when, within an Inkscape application window, the user decides to export an SVG File using an extension, that extension has no way to receive the full path-name of the original SVG File. What Inkscape does is, to create a temporary copy of the SVG File in some hidden folder, and to offer that to the extension, after which the temporary file is deleted again.

To be able to grab the full path-name of the original SVG File would be essential in some form, if any of its includes are to be converted to relative filenames, as seen from the location of the original SVG File, or, as seen from the location of the TEX File that’s to result.

This limitation does not exist, when ‘svg2tikz’ is run from the command-line.

And so, the devs have left some incomplete code in their extension, which will actually end in an error message, that takes place near line 1039, of the Python script ‘svg2tikz/svg2tikz/extensions/‘. However, an extension that leaves full path-names in its exported files, is still preferable to one, which just fails to export any file at all. And so, what I did was, to edit the Python file in question as follows (Linux Only):


    from urllib.parse import urlparse,  unquote
except ImportError:
    from urlparse import urlparse
    from urllib import unquote


        if (self.options.latexpathtype and isvalidhref):
            #href = href.replace(self.options.removeabsolute, '');
                if'^file://', href) is not None:
                    href = unquote(urlparse(href).path)
            except AttributeError:
                if'^file://', href) is not None:
                    href = unquote(urlparse(href).path)
                href = os.path.relpath(href);


What my code will do is, first to try reading the filename from the object, and, if there is one, to forego trying to convert it to a relative path. Yet, if there is no filename associated with the object, my modifications will simply use the Python semantics of ‘os.path.relpath(href)‘. Those basic semantics will work from the command-line, because from there, a PWD follows that is actually correct.

But, even with my modifications, when I run the extension from within Inkscape, the full path-name remains, that Inkscape already linked to. And the extension is workable.


The reader might be asking himself what happens, if only the plain Python semantics are tried, to compute a relative filename from the absolute one, of the included filename, when the extension is being used from within Inkscape. Because I tend to test my code, before being sure that it works, I did in fact try this, and the result was the following ‘relative’ filename:




What might be wrong with this result?

  • While the URL might work ‘accidentally’, it actually has one too many ‘..‘ entries. Three double-dots should lead to the root directory, but the path-name received four. Now, the way Linux works, typing ‘cd ..‘ when within ‘/‘ will in fact lead back to ‘/‘. But the reason for the excessive double-dots at the beginning was the fact, that the PWD from which the script was being run, within Inkscape, was not/home/dirk/tmp‘ (even though, that was where the master SVG File resided).
  • A path-name that has been made ‘relative’ in this way would have no advantages over an absolute one, even if it did work, because it will always be longer than the absolute path-name already was. The one shown above must contain ‘/home/dirk/tmp/‘ anyway, and to precede it with four double-dots is not an improvement.


There is a further avenue which I explored. According to Gitlab, there exists an elaborate package named ‘inkex’, which should in fact also implement the static class function ‘svg_path()‘. The problem with that? At least on my Debian / Linux distributions, the version of ‘inkex‘ that ships with ‘Inkscape’, does not match what Gitlab indicated. The version that gets implemented on my machines, is defined by the Python File:




Logically, this is where Python would look for the package, when run under Linux, within Inkscape. But simply pointing my file manager at this system directory, and opening the Python File in read-only mode, revealed that only a small subset of the functions was defined, that Gitlab wrote about above. If the reader finds that for some reason, he has a complete implementation of the ‘inkex‘ (Python) package on his computer, he can try to design a patch, that will work on his computers, but not on Debian 9 / Stretch computers. BTW, There is no Debian package that installs this, separately from what ‘Inkscape’ already installs.


Print Friendly, PDF & Email

One thought on “Inkscape Extension ‘svg2tikz’ revisited.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>