Background: PGF 3.0 added a new, direct way to create SVG. It now has a dvisvgm driver (pgfsys-dvisvgm.def) which has fewer (claimed) limitations than the pgfsys-tex4ht.def driver. Except it doesn't seem to work at all with the current version (1.8) of dvisvgm itself.

The PGF/TikZ manual gives the following example:

Hello \tikz [baseline] \fill [fill=blue!80!black] (0,.75ex) circle[radius=.75ex];

This doesn't render any graphics for me with MikTeX. Only the "Hello" word appears in the output SVG. I did check that the dvi file generated contains actual dvisvgm specials like dvisvgm:raw <g fill="rgb(0.0%,0.0%,80.0003%)"> which is probably the color for the blue dot/circle.

If I remove [dvisvgm] from the code above, I get the blue circle in the resulting SVG, but the intermediate DVI is using PostScript specials instead; it's full of grestore, gsave and so forth. And of course you need ghostscript for it to actually get processed properly by dvisvgm, whereas the new, direct dvisvgm driver doesn't need ghostscript.

So, question: did anyone manage to get the PGF 3.0 dvisgm driver working with the actual dvisgm? If so, how? If not, does anyone have a clue where the interfacing bug is?

For the experts, here are the "disassembled" dvi files (with DVItype):

Fairly important update:

Another interesting issue is that although the DVI using PostScript specials is considerably longer than the one using dvisvgm specials (as you can probably tell from disassemblies above), the working SVG that results via PostScript that is actually a bit shorter then non-working one using the new, direct driver...

And the diff between these two: http://pastebin.com/NZxu9bpR

It seems the viewBox and viewport are different, smaller for the direct method and there's some extra "junky" stuff generated by the "direct" method.

  • PS/old viewbox ends with: 32.0864 6.89265' width='32.0864pt'
  • direct/new viewbox ends with: 22.3323 6.89265' width='22.3323pt'

Luckily the junky stuff doesn't matter, if I just copy the old viebox and width over the new, direct-method SVG it displays fine the blue dot/circle! But I still don't know if it's the driver that resulted in the bad (too short) viewbox or if it's a bug added in a newer version of dvisvgm itself, and if so in which version... I did see the comment below that the older version from TeXLive 2014 works fine, so I'm guessing this is most likely a regression in dvisvgm itself.

By the way, you have to be careful how interpret what Inkscape shows, because unlike web browsers, it displays stuff in SVGs that's outside the viewbox too! But Inkscape does draw the viewbox. Compare the two screenshots here: https://i.sstatic.net/4UEVf.jpg

Attepted --bbox workaround

Given that the only real issue turned out to be the SVG viewport (only width in this example) and view box (viewBox), the fix with the current version of dvisvgm (1.8) would seem to be to invoke it with --bbox=none, which omits adding width, height and viewBox to the resulting SVG, so all of it gets displayed in web browsers. However this only works if you display the SVG separately. If you include it in a web page with other elements, all browsers I tried (IE 11, Chome 36, Firefox 31) leave large amounts of space around it, while that doesn't happen with the SVGs that have a specified vieport & viewBox; those get tightly packed.

None of the other options for --bbox do any better. --bbox=min seems to be the default and gets the same results as no parameter, with or without --exact. The other choice, --bbox=dvi puts a huge box around the output, so it's basically centered on the page. I googled a bit, but i haven't found any easy way to get the SVG viewport/viewbox right with other software. Inkscape for instance doesn't even let you edit/specify the viewbox unless you use a plug-in that doesn't even ship with it (http://pernsteiner.org/inkscape/viewbox/). And that's not really an automated solution.

**Update again (after Martin's reply) ** Yeah, I've now noticed that the dvisvgm's manual says that dvisvgm:bbox needs to be updated by the DVI when using dvisvgm's own specials. But the DVI output of PGF using its dvisvgm driver doesn't output any dvisvgm:bbox calls (see the DVI linked above for exmaple). So the driver couldn't possibly work right as it stands, unless Martin decides he wants to treat uniformly dvisvgm and PostScript specials for the purpose of calculating bboxes. I was actually typing this as a feature request on his launchpad when I noticed he replied here. If dvisvgm treated both dvisvgm and PostScript specials uniformly as input, that would also allow him to do some optimizations on the incoming dvisvgm specials instead of just passing them though, because PGF's output is rather more verbose...

  • 2
    There is no dvisvgm in miktex but if I compile your document with latex and then use the dvisvgm from TL14 it works fine: Inkscape shows the hello and a blue circle. Commented Jul 31, 2014 at 11:58
  • The viewbox problem is also reproducible with the older dvisvgm and so I would suggest that you make a bug report at the pgf-site. According to the author of dvisvgm there is probably a special missing github.com/mgieseki/dvisvgm/issues/41. Commented Jul 31, 2014 at 16:22
  • 1
    dvisvgm doesn't evaluate the SVG portions created by PGF so it doesn't expand the bounding/view box automatically here. Therefore, PGF should also create dvisvgm:bbox specials which tell dvisvgm that there's further stuff to be considered when computing the bounding box.
    – Martin
    Commented Jul 31, 2014 at 16:23
  • For anyone else reading this, Martin explained in a bit more detail why he is reluctant to make dvisvgm treat its own specials the same way as the PostScript ones over here. I've also filed a bug report on pgf.tikz's tracker. Commented Aug 10, 2014 at 5:28

1 Answer 1


Although this is an old question, maybe there now seems a solution.

Since dvisvgm-1.16, which was released in 2016-07-04 (Release Note), it supports papersize-special.

standalone package automatically sets the papersize, so use it as document class instead of minimal.

Hello \tikz [baseline] \fill [fill=blue!80!black] (0,.75ex) circle[radius=.75ex];

to use papersize as bounding box of SVG, add -b papersize option to dvisvgm command (Manpage)

$ latex mydocument.tex
$ dvisvgm -b papersize mydocument.dvi

Here's the screenshot of the SVG image in my browser, which was created with/without -b papersize.

screenshot comparison

Note that image border is added by CSS for clarify. You can see that blue circle is displayed correctly with -b papersize.

Edit: if you are using luatex or xetex, the standalone document class does not set papersize-special, so you might have to add following code to standalone.cls.

% in next row of \global\paperheight=... in \def\sa@placebox{ ... }

the path of standalone.cls can be find using following command

$ kpsewhere standalone.cls
  • Hi, I get this output:use Commented Aug 15, 2019 at 7:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .