Incorrect tikzpicture size when using dvisvgm output driver (PGF/TikZ)

[csevast]

Brief outline of the bug

I want to produce an SVG file with a node shape, e.g. rectangle. I use the following LaTeX code:

\def\pgfsysdriver{pgfsys-dvisvgm.def}
\documentclass{article}
\usepackage[usenames]{color}
\pagestyle{empty}
\usepackage{tikz}
\usetikzlibrary{shapes.geometric}
\begin{document}
\pagecolor{white}%
\begin{tikzpicture}
  \node (start) [draw, rectangle, minimum width=24mm, minimum height=16mm] {How are you?};
\end{tikzpicture}
\end{document}

and then I use xelatex and then dvisvgm to produce the SVG file:

xelatex -no-pdf -interaction nonstopmode -output-directory .\ test1.tex & dvisvgm -n -o .\test1.svg test1.xdv

Unfortunately, the produced SVG file has a background object with larger width than the width of the rectangle, resulting in a TikZ picture with larger width. The width is depended on the text width, i.e., if the text is short, the resulting background object width is not longer than the rectangle width, and there is no problem. But when the text width is longer than some critical length, the tikzpicture width is not the same as the drawn object width. Also, I noticed the same problem with the height. In the following example, the problem appears on the top of the tikzpicture:

\def\pgfsysdriver{pgfsys-dvisvgm.def}
\documentclass{article}
\usepackage[usenames]{color}
\pagestyle{empty}             % do not remove
\usepackage{tikz}
\usetikzlibrary{shapes.geometric}
\begin{document}
\pagecolor{white}%
\begin{tikzpicture}
  \node (point1) [coordinate] {};
  \node at (0,-3cm) (start) [draw, color=black, rectangle, minimum width=24mm, minimum height=16mm] {How are you?};
  \draw (point1) -- (start);
\end{tikzpicture}
\end{document}

with the following command to be executed:

xelatex -no-pdf -interaction nonstopmode -output-directory .\ test3.tex & dvisvgm -n -o .\test3.svg test1.xdv

I am using: Windows 11 MiKTeX-XeTeX 4.10 (MiKTeX 23.5) dvisvgm 3.0.4 pgf 3.1.10

Minimal working example (MWE)

\def\pgfsysdriver{pgfsys-dvisvgm.def}
\documentclass{article}
\usepackage[usenames]{color}
\pagestyle{empty}
\usepackage{tikz}
\usetikzlibrary{shapes.geometric}
\begin{document}
\pagecolor{white}%
\begin{tikzpicture}
  \node (start) [draw, rectangle, minimum width=24mm, minimum height=16mm] {How are you?};
\end{tikzpicture}
\end{document}

[csevast]

I attach the TEX and SVG files ziped
files.zip

[hmenke]

XDV is not DVI and dvisvgm does not support XDV.
mgieseki/dvisvgm#109

[muzimuzhi]

It seems the problem is reproducible with pdflatex + dvisvgm driver. dvips driver works as expected.

% test5.tex
\documentclass[dvisvgm,tikz]{standalone}

\begin{document}
\begin{tikzpicture}
  \node[draw, rectangle, minimum size=20mm] {xxx};
\end{tikzpicture}

\begin{tikzpicture}
  \node[draw, rectangle, minimum size=20mm] {xxx xxx};
\end{tikzpicture}
\end{document}

Run

pdflatex -output-format=dvi test5.tex
dvisvgm --page=- test5.dvi

The stdout of dvisvgm already shows the difference: the svg converted from second page (test5-2.svg) is wider than expected.

pre-processing DVI file (format version 2)
processing page 1
  graphic size: 57.30548pt x 57.30548pt (20.140573mm x 20.140573mm)
  output written to test1-1.svg
processing page 2
  graphic size: 63.652901pt x 57.30548pt (22.371436mm x 20.140573mm)
  output written to test1-2.svg
2 of 2 pages converted in 0.758255 seconds

PS: I'm still on dvisvgm 3.0.3 (poor macOS users).

PS2: dvisvgm understands XDV format (and treats it as "versions 5 to 7"), only it doesn't understand pdf (graphical) specials written to XDV.

[agrahn]

Here is a possible fix. The issue has to do with forced bbox adjustment by the pgfsys-dvisvgm driver and automatic computation by dvisvgm. See https://tex.stackexchange.com/a/695821.

For comparison: SVG with driver fix and SVG without driver fix.

\def\pgfsysdriver{pgfsys-dvisvgm.def}

\documentclass{article}
%\usepackage[usenames]{color}
\pagestyle{empty}
\usepackage{tikz}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%   fix bounding box setting of inserted tikz objects   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\makeatletter
\def\pgfsys@typesetpicturebox#1{%
  \pgf@ya=\pgf@shift@baseline\relax%
  \advance\pgf@ya by-\pgf@picminy\relax%
  %
  %
  \advance\pgf@picmaxy by-\pgf@picminy\relax% maxy is now the height
  \advance\pgf@picmaxx by-\pgf@picminx\relax% maxx is now the width
  \setbox#1=\hbox{\hskip-\pgf@picminx\lower\pgf@picminy\box#1}%
  \ht#1=\pgf@picmaxy%
  \wd#1=\pgf@picmaxx%
  \dp#1=0pt%
  \leavevmode%
  \pgf@xa=\pgf@trimleft@final\relax  \ifdim\pgf@xa=0pt \else\kern\pgf@xa\fi%
  \raise-\pgf@ya\hbox{\ifpgf@sys@svg@inpicture\box#1\else\special{dvisvgm:bbox \pgf@sys@tonumber\pgf@picmaxx\space\pgf@sys@tonumber\pgf@picmaxy}\special{dvisvgm:bbox lock}\box#1\special{dvisvgm:bbox unlock}\fi}%
  \pgf@xa=\pgf@trimright@final\relax \ifdim\pgf@xa=0pt \else\kern\pgf@xa\fi%
}
\makeatother
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\usetikzlibrary{shapes.geometric}
\begin{document}
\pagecolor{white}%
\begin{tikzpicture}
  \node (start) [draw, rectangle, minimum width=24mm, minimum height=16mm] {How are you?};
\end{tikzpicture}
\end{document}

Should I prepare a pull request? The problem is, I don't know how to run the tests.

[muzimuzhi]

Should I prepare a pull request? The problem is, I don't know how to run the tests.

@agrahn It's always welcome, despite the whole processing is blocked by #1116 for (quite) a while.

You can run l3build save -e latexdvisvgm pgf001 pgf002 to update required testfiles, then run l3build check to (double) check all tests pass.

[agrahn]

Thank you, @muzimuzhi !

l3build save -e latexdvisvgm pgf001 pgf002
l3build check

This is what I get:

$ l3build check
Running l3build with target "check" with configuration build
Running checks on
  gh-issue-1102 (1/4)
  gh-issue-1131 (2/4)
  pgf001 (3/4)
  pgf002 (4/4)

  All checks passed

Running l3build with target "check" with configuration config-gd
Running checks on
  tikz-gd-gh1087 (1/1)

  All checks passed

[muzimuzhi]

Also I wonder if this is a long-existing problem.

For now what I found is, the new specials dvisvgm:bbox lock and dvisvgm:bbox unlock used in agrahn@f7fb424 were added by mgieseki/dvisvgm@63b5bba and shipped with dvisvgm v2.7, 2019-04-13 (no chance to be packed to the TeX Live 2019 image, released on 2019-04-10).

Update: These two new specials were then used in graphics/x drivers, since graphics-def 2020-03-24, see latex3/graphics-def#23.

[agrahn]

Also I wonder if this is a long-existing problem.

For now what I found is, the new specials dvisvgm:bbox lock and dvisvgm:bbox unlock used in agrahn@f7fb424 were added by mgieseki/dvisvgm@63b5bba and shipped with dvisvgm v2.7, 2019-04-13 (no chance to be packed to the TeX Live 2019 image, released on 2019-04-10).

Yes, these specials were once added on my request. I needed them for the correct working of the dvisvgm driver for the graphics package (dvisvgm.def).

[josephwright]

I wondered if this affected l3backend, but we don't seem to use bbox at all :) At some point, I'll check why!

[agrahn]

I wondered if this affected l3backend, but we don't seem to use bbox at all :) At some point, I'll check why!

I made use of them when working on dvisvgm.def for pkg graphics/x

[muzimuzhi]

@agrahn I noticed the new commit b9c09af still failed the CI. You need to add and commit (and push, of course) the new changes caused by l3build save -e latexdvisvgm pgf001 pgf002, then the CI will be satisfied.

[agrahn]

@agrahn I noticed the new commit b9c09af still failed the CI. You need to add and commit (and push, of course) the new changes caused by l3build save -e latexdvisvgm pgf001 pgf002, then the CI will be satisfied.

@muzimuzhi Did this with a git commit --amend and git push --force to my forked repo, branch dvisvgm-bbox. Hope this is ok?

[muzimuzhi]

@agrahn It seems more-than-required changes were added: unneeded file pgf/tlpkg/texlive.tlpdb and reverted 945df97 (possibly caused by an local, outdated luaotfload package).

[agrahn]

@agrahn It seems more-than-required changes were added: unneeded file pgf/tlpkg/texlive.tlpdb and reverted 945df97 (possibly caused by an local, outdated luaotfload package).

@muzimuzhi : Sorry, I had loaded the wrong TL (last year's one). Will try again with TL-23.

[agrahn]

@muzimuzhi : Sorry, I had loaded the wrong TL (last year's one). Will try again with TL-23.

@muzimuzhi : I think it is ok now. Would you please check?

[josephwright]

I wondered if this affected l3backend, but we don't seem to use bbox at all :) At some point, I'll check why!

I made use of them when working on dvisvgm.def for pkg graphics/x

Right, yes - I'll need to think about that, as the 'native' expl3 code doesn't (but is only very lightly tested in this area).

[csevast]

I replaced pgfsys@typesetpicturebox definition in the pgfsys-dvisvgm.def file of my MiKTeX installation with the definition introduced by @agrahn. All my codes —not only the ones I presented in the issue— are working as expected. I hope all the tests to be OK and the correction to be merged in the repository. I'm waiting for the new official version to synchronize my installation.
Thank you very much for your fast response and effective action.

[muzimuzhi]

As for testing, perhaps for some cases we need svg-based tests. Currently graphics-def/graphics has no dvisvgm tests [1] and pgf and l3kernel/l3backend [2] uses log-based tests (through \showbox) to test their dvisvgm drivers, respectively.

[1] https://github.com/latex3/latex2e/tree/develop/required/graphics/testfiles
[2] https://github.com/latex3/latex3/tree/main/l3kernel/testfiles-backend