Generate SVG output with dvisvgm

[DavidPowell]

In my fork I added a new output method for generating SVGs, using latex and dvisvgm (instead of pdflatex and imagemagick). It has the following advantages and issues:

• Elements in the SVG output can now have SVG ids (via the --svgid option). This is enables parts of the figure to be manipulated with javascript to animate them etc.

• Text in the image now appears as selectable text in the output, instead of SVG paths

• Imagemagick is not needed (one less dependency to deal with, esp on Windows)

• The output image is sized automatically according to the size of the contents

  • A given element will always have the same size in different images
  • The dimensions specified in TikZ now corresponds to the screen size in cm
  • Unwanted whitespace is avoided (a problem with current SVG backend)

• Note that to achieve this, I had to change the bounding box size from px (pixels) to pt (physical points)

  • Will this be an unexpected change for existing users? (it could be made specific to the dvisvgm backend)

• The scale parameter to the tikzpicture{} environment does not scale all objects

  • An --imagescale parameter has been added (for dvisvgm only) to rescale the whole image
  • This parameter might also be useful for other cases

• Tikz actually has a specific dvisvgm driver, which can be specified with \usepackage[dvisvgm]{standalone}. I originally used this, but dropped it as it seemed to cause strange aliasing/rounding errors, with lines not quite joining perfectly.

• To enable easily modifying the SVGs with javascript, I removed them from iframes. This seemed to be okay with all examples I tried, because fonts are no longer turned into glyphs which could clash with each other. There may be some unknown edge case where isolation with iframes is still desirable.

You can see some generated output in my example notebook. Notice how the text is now selectable, and the box moves when mousing over due to the javascript below.

My changes to the codebase can be found here https://github.com/DavidPowell/ipython-tikzmagic/commit/d5b25b6d0d1e5f70a45f0e95534348e42b33d40a

I decided to create this issue before generating a PR, since after my changes there is definitely more spaghetti code than I would like. Note that a lot of new options were needed to get the full benefit of this approach, and some options (like the size) are now ignored. As far as I can tell the existing functionality is preserved, but I haven't tested extensively.

Is this something that would make sense to integrate into ipython-tikzmagic?

The alternative would be for me to create a cleaned-up fork project which only has the dvisvgm mode.

[parthi2929]

Hi David your fork is still active because this base looks not being updated any more? (no replies for many recent issues)

[DavidPowell]

@parthi2929 I made some changes to incorporate dvisvgm support. I am currently using this on an almost daily basis, but I have not needed to make many changes to the code.

You may wish to try out my fork. Using the --dvisvgm option (assuming you have dvisvgm installed), the output file now scales much more logically, and it probably solves your issue #27.

Please understand that this is just a volunteer project created for the dev's on needs. Resolving everyone else's issues requires time and commitment that not everyone has.

[parthi2929]

this @mkrphys base has an svg option, but when i try it fails.

[DavidPowell]

The standard SVG conversion option is based on generating a PDF, then extracting an SVG with imagemagick. Imagemagick needs to be installed, also this extension needs to know where to find it. Under windows the default executable name is different to what the extension is expecting, so I added a -i option to allow the filename and path of imagemagick to be specified.

The approach I added in this issue is quite different. It generates a dvi, then converts to svg using dvisvgm (which should be already installed on any modern latex distribution). I found the output is much better quality, and scaling works better. Also, this approach enables SVG ids to be added to elements of the drawing, for making them interactive with javascript.