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.
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.:
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:
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
dvisvgm -hlists option
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 PATH.
LIBGSor call dvisvgm with option
LIBGS, e.g. with
dvisvgm -hdoesn’t list option
dvisvgm -ldoesn’t list entry ps
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)
processing of PostScript specials has been disabled permanently
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
-V1 lists Ghostscript if it’s found:
$ dvisvgm -V1 dvisvgm 1.9 (x86_64-pc-win64) ----------------------------- clipper: 6.2.1 freetype: 2.5.5 Ghostscript: 9.15 MiKTeX: 2.9 potrace: 1.11 zlib: 1.2.8
gsdll64.dll(usually something like
bindirectory to environment variable PATH, e.g. with
PATH=%PATH%;"c:\program files\gs\gs9.15\bin". See here for more information on how to set the PATH variable permanently.
set LIBGS="c:\program files\gs\gs9.15\bin\gsdll32.dll".
--libgsto tell dvisvgm where the GS DLL is located, e.g.
dvisvgm --libgs="c:\program files\gs\gs9.14\bin\gsdll32.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:
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.
The SVG standard allows to define clipping paths by intersection like so:
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.