This is probably caused by changes in Ghostscript. Ghostscript 9.55.0 introduced a completely rewritten PDF interpreter, which is now implemented in C instead of PostScript. This has a lot of advantages besides the performance improvements. For third-party applications like dvisvgm, however, this change has significant impact on the functions that can be provided. dvisvgm relies on the possibility to overwrite PostScript and PDF operators in order to directly communicate with the interpreter. This is no longer possible with the new PDF interpreter.

As of Ghostscript 9.56.0 the new PDF interpreter is activated by default. Therefore, older dvisvgm releases can’t process PDF files any longer. For the time being, Ghostscript still offers an option to reactivate the old PDF interpreter which dvisvgm does as of version 2.13.4.

Please check the output of dvisvgm -V1. If you use a dvisvgm version prior to 2.13.4 together with Ghostscript 9.56.0 or later, you should update to a more recent version of dvisvgm.

Alternatively, you can set environment variable GS_OPTIONS to value -dNEWPDF=false which tells Ghostscript to use the old PDF interpreter. Depending on operating system and command shell, the syntax to set the variable differs slightly, e.g.

• export GS_OPTIONS=-dNEWPDF=false (Linux, bash)
• set GS_OPTIONS=-dNEWPDF=false (Windows command line)

Since Ghostscript 10.01.0 this workaround doesn’t work any longer because the old PS-based PDF interpreter was finally removed from Ghostscript. To keep the PDF functionality of dvisvgm alive, a new PDF handler was introduced with dvisvgm 3.0 which is based on mutool (part of the MuPDF package).

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 (also see the screenshots). 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.

As of version 2.0, dvisvgm provides the command-line option --font-format that allows to change the format used for embedded fonts from SVG to WOFF, WOFF2 or TrueType. If you call dvisvgm with option --font-format=woff, you should get SVG files that render correctly in almost all recent web browsers. Moreover, and in contrast to option --no-fonts, all text properties are retained.

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.

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 T_EX environment it’s not.
• The DVI file was generated by LuaT_EX which uses an extended syntax to reference fonts in a DVI file. dvisvgm doesn’t support LuaT_EX yet. In this case you get warnings like WARNING: can’t embed font 'name:LinuxLibertineO'.

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

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

Therefore, depending on the configuration options your dvisvgm binary was built with, there could be problems to find or access the Ghostscript library. 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.9 (Linux), or set LIBGS=c:\gs\gs9.56\bin\gsdll64.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

$ 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
papersize  special to set the page size
pdf        PDF hyperlink, font map, and pagesize specials
ps         dvips PostScript specials
tpic       TPIC specials

$ dvisvgm -V1
dvisvgm 2.4 (x86_64-pc-win64)
-----------------------------
brotli:      1.0.4
clipper:     6.2.1
fontforge:   20160721
freetype:    2.9.1
Ghostscript: 9.23
MiKTeX:      2.9
potrace:     1.15
ttfautohint: 1.8.1
woff2:       1.0.2
xxhash:      0.6.5
zlib:        1.2.11

• 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.
• As of version 1.9, dvisvgm should find the location of the Ghostscript DLL automatically. If it does not, proceed with the following steps.
• Look up the Ghostscript directory that contains the Ghostscript DLL gsdll32.dll or gsdll64.dll (usually something like c:\program files\gs\gs9.23\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. with PATH=%PATH%;"c:\program files\gs\gs9.23\bin". 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.56\bin\gsdll64.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.56\bin\gsdll64.dll" ...

The dvisvgm binaries built for MiKTeX try to call some MiKTeX functions (e.g. those to lookup files) through the COM interface. If it’s not possible to create or access the MiKTeX COM object, dvisvgm can’t proceed and therefore aborts with the error message MiKTeX session could not be initialized. There are several reasons why the session access fails:

• MiKTeX isn’t installed on the computer.
• You use the MiKTeX Portable edition. Portable applications don’t touch the Windows registry and thus don’t register any COM objects either. Therefore, it’s not possible to use the external dvisvgm binaries together with MiKTeX Portable. Instead, install the dvisvgm package provided by MiKTeX.
• The registration of the COM object failed or was skipped during the installation of MiKTeX for some reason. You can try to register the components manually as described here (thanks to Ulrike Fischer and Christian Schenk). Run the following commands with administrator privileges:

  regsvr32 MiKTeX209-core-PS.dll
  regsvr32 MiKTeX209-core.dll
  regsvr32 MiKTeX209-packagemanager-PS.dll
  regsvr32 MiKTeX209-packagemanager.dll

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/gradient fills are implemented partially. Function-based (type 1), axial (type 2), and radial (type 3) shadings 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.

Firefox, Opera, and IE

Google Chrome

Apache Batik

Inkscape