Frequently Asked Questions

Here you find answers to a couple of questions that have frequently been asked in the past.

I converted a simple math formula but get garbage when displaying the SVG. What's wrong?

The generated SVG is most likely valid but your SVG viewer/editor probably doesn't support embedded fonts. Actually, only few SVG renderers, e.g. Batik evaluate embedded fonts properly. You can run dvisvgm with option --no-fonts to replace the fonts with path elements. Most viewers should render the resulting SVG file correctly. As a drawback, you get bigger files, and the information about the text (characters, baselines, ...) gets lost.

The bounding box of the generated SVG is too small so that some characters are clipped. What can I do?

Run dvisvgm with option --exact. By default, dvisvgm uses the character dimensions (height, depth, width, italic correction, etc.) stored in a font's TFM file to compute the bounding boxes. However, as the TFM bounds are optimized for TeX's character positioning, and as the actual glyphs may exceed their TFM bounds, clipped SVG files are the result. Option --exact tells dvisvgm to analyze each glyph and to compute the exact bounding rectangle.

Why do I get warnings like can't embed font 'FOO'?

There are several reasons that could cause these warnings, e.g.:

• The DVI file was generated on a different computer where the mentioned font was available, but in the current TeX environment it's not.
• The DVI file was generated by LuaTeX and references a font located outside the TeX environment. These fonts can't be found using the kpathsea library. In this case you get warnings like WARNING: can't embed font 'name:LinuxLibertineO'. dvisvgm doesn't support external fonts yet.

Even if I call dvisvgm with option -n the results of some files look wrong. What can I do?

Perhaps you run dvisvgm with PostScript support disabled. See below how to check this and how you can enable the processing of PostScript specials.

Why is dvisvgm's PostScript support disabled on my machine?

dvisvgm requires access to the Ghostscript library in order to process PostScript specials. In contrast to the other third-party libraries needed to build dvisvgm (which are always linked directly), Ghostscript can be attached to dvisvgm in three different ways:

• direct linkage of libgs.so or libgs.a during build time
• no direct linkage but dynamic lookup of the Ghostscript library and its functions during runtime via dlopen()
• no Ghostscript support at all

The latest versions of dvisvgm print a message if PostScript support is disabled because Ghostscript can't be found. In this case, tell dvisvgm where to find the Ghostscript library, e.g. by assigning its location to environment variable LIGS. For more information see below.

Depending on the configuration options, the dvisvgm binary can therefore be built in three different flavors. You can determine the variant used to build your binary by checking the output of dvisvgm -h and dvisvgm -l:

1. dvisvgm -h doesn't list option --libgs but dvisvgm -l lists entry ps
   • libgs was linked during build time.
   • PostScript support is always enabled.
2. dvisvgm -h lists option --libgs
   • PostScript support was enabled but the Ghostscript library must be looked up during runtime.
   • If dvisvgm -l doesn't show entry ps, verify whether the directory containing libgs.so (Linux), gsdll32.dll (Windows, dvisvgm 32 bit binary), or gsdll64.dll (Windows, dvisvgm 64 bit binary) is present in the library or program search path, respectively. On Windows, check environment variable PATH.
   • If you want dvisvgm to look for a different filename, e.g. libgs.so.9, set environment variable LIBGS or call dvisvgm with option --libgs.
   • Alternatively, assign the path of the Ghostscript library to environment variable LIBGS, e.g. with LIBGS=/usr/lib/libgs.so (Linux), or set LIBGS=c:\gs\gs9.06\bin\gsdll32.dll (Windows)
3. dvisvgm -h doesn't list option --libgs and dvisvgm -l doesn't list entry ps
   • dvisvgm was built without PostScript support. There's no way to activate it. Try to get a binary with PS support enabled.

How do I enable PostScript support on a Windows computer?

• Download and install Ghostscript. The 32-bit version of dvisvgm requires the 32-bit version of Ghostscript, the 64-bit dvisvgm requires the 64-bit Ghostscript.
• Lookup the Ghostscript directory that contains the Ghostscript DLL gsdll32.dll or gsdll64.dll (usually something like c:\program files\gs\gs9.07\bin).
• Tell dvisvgm where to find the Ghostscript DLL. There are several alternatives to do that:
  • Add the path of the Ghostscript bin directory to the environment variable PATH, e.g. by appending ;c:\program files\gs\gs9.07\bin to the existing entry. See here for more information on how to set the PATH variable permanently.
  • Assign the location of the Ghostscript DLL to the environment variable LIBGS, e.g. with set LIBGS="c:\program files\gs\gs9.07\bin\gsdll32.dll".
  • Use the command-line option --libgs to tell dvisvgm where the GS DLL is located, e.g. dvisvgm --libgs="c:\program files\gs\gs9.07\bin\gsdll32.dll" ...

DVI files containing PostScript code are not converted properly. Are you going to fix this?

PostScript is a pretty complex language and its interaction with the DVI operations is rather tricky, especially, if plain PostScript snippets are supposed to change the current graphic position or the current font.

• Defining and/or changing fonts via PostScript is not supported yet.
• Shading fill patterns (also known as gradient fills) are not supported yet.

Clipping issues

The SVG standard allows to define clipping paths by intersection like so:

  <clipPath id="clip1">
    <rect x="0" y="0" width="50" height="50"/>
  </clipPath>
  <clipPath id="clip2" clip-path="url(#clip1)">
    <circle cx="50" cy="50" r="20"/>
  </clipPath>

While clipping path clip1 is the outline of a square, clip2 is defined as the intersection of the square with a circle at the given position. Thus, we get a quadrant here. All following drawing operations restricted to clip2 should produce visible results inside the quadrant only. Unfortunately, merely a few SVG viewers render these intersections properly. Since dvisvgm creates SVG files containing this kind of path intersections, the results might look wrong.

Here's an example: The following images show the rendering results of the same SVG file opened in several applications. The SVG was generated with dvisvgm 1.0.8 out of this TikZ example.

Opera 12 Firefox 20 (Linux) and IE 9/10

Chrome 26 Firefox 20 (Windows)

Batik 1.7

Inkscape 0.48