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
-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)
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
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
you should get SVG files that render correctly in almost all recent web browsers. Moreover, and in contrast to
--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 TEX environment it’s not.
- The DVI file was generated by LuaTEX which uses an extended syntax to reference fonts in a DVI file.
dvisvgm doesn’t support LuaTEX yet. In this case you get warnings like
WARNING: can’t embed font 'name:LinuxLibertineO'.
-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.
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
- 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 -hdoesn’t list option
dvisvgm -llists entry ps
- libgs was linked during build time.
- PostScript support is always enabled.
dvisvgm -hlists option
- PostScript support was enabled but the Ghostscript library must be looked up during runtime.
dvisvgm -ldoesn’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
- If you want dvisvgm to look for a different filename, e.g. libgs.so.9, set environment variable
LIBGSor call dvisvgm with option
- Alternatively, assign the path of the Ghostscript library to environment variable
LIBGS, e.g. with
dvisvgm -hdoesn’t list option
dvisvgm -ldoesn’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 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 papersize special to set the page size pdf PDF hyperlink, font map, and pagesize specials ps dvips PostScript specials tpic TPIC specials
-V1 lists Ghostscript if it’s found:
$ 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
gsdll64.dll(usually something like
- Tell dvisvgm where to find the Ghostscript DLL. There are several alternatives to do that:
- Add the path of the Ghostscript
bindirectory 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.23\bin\gsdll32.dll".
- Use the command-line option
--libgsto tell dvisvgm where the GS DLL is located, e.g.
dvisvgm --libgs="c:\program files\gs\gs9.23\bin\gsdll32.dll" ...
- Add the path of the Ghostscript
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.
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
The following images show the rendering results of the same SVG file opened in several applications.
The SVG was generated without option
this TikZ example.