SVG in jupyter conversion with nbconvert fails

Hi all,

I’m using juypter for a school assignment (deadline coming monday) and the conversion to pdf is not working as expected. I have some programatically generated svgs that I would like to be in the pdf but somehow LaTeX/nbconvert is choking on it. I found another lost soul with similar problems on the stackoverflow below.

Is there a simple fix for this? As a last resort converting the SVGs to some other format (e.g. PNG) but that removes all the nice vectorized features that come with SVGs.

Overfull \hbox (156.02196pt too wide) in paragraph at lines 587--587
[]\TU/lmtt/m/n/10.95 gplot(sg,locs_x,locs_y,nodefillc[]=[]nodefillc,nodelabel[]
[1] [2] [3] [4] [5] [6] [7]

! LaTeX Error: Cannot determine size of graphic in full3_8.svg (no BoundingBox)

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
l.707     \includegraphics{full3_8.svg}

If I recall correctly, pdflatex understands png, jpg, and pdf files.

There is an svg Latex package that automatically uses Inkscape to convert the image as the Latex is compiling, which might be useful, but that would require I think having inkscape installed and somehow getting that command changed to \includesvg{...}, as well as including the svg package.


in case it helps, I have spent some time today trying to do this in an attempt to assess what could be doable

it appeared that

  • one needs to run latex with the --shell-escape option to allow the spawning of an external program

  • installing inkscape is not straightforward - on my macOS at least;
    I used brew install cask inkscape but then had to manually add /Applications/ to my PATH

  • as of today I could see includesvg fail to work properly; it calls inkscape with a -z option that is not supported; indeed as per this link the command line interface of inkscape has changed with release 1.0 that just went out at the beginning of May 2020

    most likely includesvg will follow suit at some point; maybe it has already and I am behind (I’m really not sure of how to update my latex distribution)

I also tried another angle using cairosvg that is a Python library that looked lighter and so, I hoped, simpler to put into place; I was thinking that if we went for this approach we could have nbconvert do the pre-processing itself, it’d be so much simpler

however, trying the 2 angles manually showed that none of them works out too well for me today; I have a handful of svg drawings - that I happen to have produced under jupyterlab thanks to the very nice drawio extension - and all of them had at least one text object wrongly converted, whether I use inkscape or cairosvg

it is a pity, it is so much nicer to create svg pictures for insertion…

I’d like to give this a try to see what does. Do you have a notebook that includes SVGs/will generate some?

it could be that the way I create these svg’s - again this specifically is through jupyterlab-drawio v0.7.0 - is the problem

I’ve been digging a little more on my side; I have tried a handful of other svg2png tools, several online, and all of them produce the same kind of artefact

My problem is the discourse instance here does not allow me to upload .svg files
Is this something that can be tweaked ?
otherwise I’ll come up with some means to publish that svg

the notebook would just have one markdown cell that does ![](f-string.svg)

in the meanwhile here are screenshots that show the svg and it’s typical png output (all tools seem to produce a similar output, so…)

Clearly fonts seem to be the problem


I have redone the svg from scratch using macSVG, my specific problem has vanished; using cairosvg allowed me to create a quite satisfactory png that I can include through includegraphics

on the other hand a visual inspection of the initial svg, produced through jupyterlab-drawio, revealed structural differences between the various text elements, and the one causing problem was indeed materialized in a <font>...</font> element instead of a `<text>…</text>’ tag for the 2 other texts that were properly translated in the png

So, bottom line for me at this point is :

  • I’ll refrain from using that extension too much; macSVG may be less convenient in certain respects but gives me great control over the produced svg, while drawio somehow has ended up with something quite messy - not that I have great expertise in using that extension either

  • this being now out of the way, it would be my recommendation that nbconvert --to latex implements the following logic when an image is included: when the included file has an .svg extension, use cairosvg to produce a png - with some kind of twisted name like thestem_nbcsvg.png - overwrite it if it is older than the target svg, and embed that through includegraphics
    this in order to avoid (1) convoluted installations and (2) the error-prone necessity to later call latex with the right option

Now, I have absolutely no knowledge of the internals of nbconvert, so I may just as well be missing something entirely, of course

A quick look around the admin interface and google didn’t find anything :-/

here’s where I can tweak that on my own instance (sorry it’s in French but hopefully it will still help)

not to worry too much though, given my latest post

cc @choldgraf or @consideRatio who are real admins

1 Like

.svg added! Thanks for the clear pointer @parmentelat!

so, here’s stuff to reproduce

  • the broken svg; again this is produced using jupyterlab-drawio, which admittedly is not the right tool for that, obviously; it does not show up properly in this discourse context either, but in a jupyter classic environment it displays fine (unless I screwed up something while writing this…)


  • the same, redone under macSVG, taking care of using a minimal set of svg tags

  • the .ipynb and .py extensions being still unallowed, I can’t upload a notebook, but one single markdown cell that does


will do the trick

@parmentelat The SVG you uploaded here only contains three rects and a few transforms, no trace of any text:

<?xml version="1.0"?>
<svg xmlns="" xmlns:xlink="" width="811px" height="71px" version="1.1">
  <g transform="translate(0.5,0.5)">
    <rect x="575" y="0" width="20" height="60" fill="#9ac7bf" stroke="#000000" pointer-events="none"/>
    <rect x="480" y="0" width="20" height="60" fill="#9ac7bf" stroke="#000000" pointer-events="none"/>
    <rect x="240" y="0" width="20" height="60" fill="#9ac7bf" stroke="#000000" pointer-events="none"/>
    <g transform="translate(92.5,6.5)"/>
    <g transform="translate(330.5,53.5)"/>
    <g transform="translate(522.5,53.5)"/>

But back to the original topic about SVG conversion: I’ve made good experiences with the tool rsvg-convert from It can be installed with conda:

That’s also what I’m recommending to use with my Sphinx extension nbsphinx, see

1 Like

first time around, my file did not look quite the same as on my laptop, but I thought it was some rendering artefact, so thanks for double checking, the thing is, my svg gets sanitized somehow when getting uploaded on discourse;
I suggest we just forget about this then, as my problem had much more to do with the way I produced that svg

Since you seem to have experience with a few different options (inkscape, imagemagick, rsvgconverter), have you gathered insights as to which of those should be the first candidate for being supported in nbconvert, in terms of their power/limitations in one dimension, and of installation pain in another ? had you given cairosvg a try ?

thanks !

I would definitely not recommend ImageMagick, because it will create bitmap images, which should only be a last resort.

Other than that, I didn’t do any thorough tests. I have mostly used rsvg-convert and haven’t found any output errors.

I’m a Linux user, so installing any of this stuff is super easy.

I guess Inkscape is quite a huge application, so it might be strange to install it just for a simple conversion task. librsvg seems more fitting for that.

Previously, it might have been difficult to install librsvg on Windows, but
I asked nicely for a conda package for Windows, and somebody created it. I haven’t tested it of course, but I assume it works.

No. I have only tested converters which already had an existing Sphinx extension.

PS: There is already an nbconvert issue about that topic: