# dvisvgm

## A DVI to SVG converter

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. Apache Batik and the Opera web browser 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 files 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:

Output of `dvisvgm -l` showing entry ps:

```\$ dvisvgm -l
bgcolor   background color special
color     complete support of color specials
dvisvgm   special set for embedding raw SVG snippets
em        line drawing statements of the emTeX special set
html      hyperref specials
pdf       pdfTeX font map specials
ps        dvips PostScript specials
tpic      TPIC specials```

Alternatively, option `-V1` can be used to check the availability of
PostScript support too (Ghostscript entry is present):

```\$ dvisvgm -V1
dvisvgm 1.7 (x86_64-pc-win64)
-----------------------------
freetype:    2.5.3
Ghostscript: 9.14
MiKTeX:      2.9
potrace:     1.11
zlib:        1.2.8```
• 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

Depending on the configuration options, the dvisvgm binary can 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.

The latest versions of dvisvgm print one of the following warnings if PostScript support is disabled:

• `processing of PostScript specials is disabled (Ghostscript not found)`
• tell dvisvgm where to find the Ghostscript library (see above)
• `processing of PostScript specials has been disabled permanently`
• dvisvgm was built without PostScript support

### 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.
• Look up the Ghostscript directory that contains the Ghostscript DLL `gsdll32.dll` or `gsdll64.dll` (usually something like `c:\program files\gs\gs9.14\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 environment variable PATH, e.g. by appending `;c:\program files\gs\gs9.14\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.14\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.14\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:

<!-- define a rectangular clipping path -->
<clipPath id="clip1">
<rect x="0" y="0" width="50" height="50"/>
</clipPath>

<!-- define another clipping path by intersecting the rectangle with a circle -->
<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 subsequent operations restricted to clip2 should produce visible results only inside the quadrant. Unfortunately, some SVG viewers render these intersections improperly. Since dvisvgm creates SVG files containing this kind of path intersections by default, the results might look wrong. To avoid this, dvisvgm offers the option `--clipjoin` which tells dvisvgm to compute the intersections directly and not to delegate this task to the SVG viewer. More detailed information can be found here.

The following images show the rendering results of the same SVG file opened in several applications. The SVG was generated without option `--clipjoin` from this TikZ example.

 Opera 24Firefox 32 (Linux)and IE 11 Chrome 37 Firefox 32(Windows) Batik 1.7 Inkscape 0.48