pgf icon indicating copy to clipboard operation
pgf copied to clipboard

Wrong Indentation with pgfsys-dvisvgm.def

Open parpalak opened this issue 1 year ago • 2 comments

Brief outline of the bug

I found a problem with border detection when using pgfsys-dvisvgm.def. In a MWE, enabling the dvisvgm option of documentclass results in excessive indentation on the left and insufficient indentation on the right:

image

Minimal working example (MWE)

\documentclass[11pt,dvisvgm]{article}
\usepackage[paperwidth=180in,paperheight=180in]{geometry}
\batchmode
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amssymb}

\usepackage{pgf-umlsd}

\pagestyle{empty}

\setlength{\topskip}{0pt}
\setlength{\parindent}{0pt}
\setlength{\abovedisplayskip}{0pt}
\setlength{\belowdisplayskip}{0pt}

\begin{document}
\begin{minipage}{0.1in}
\strut\special{dvisvgm:raw<!--start {?x} {?y} -->}.\begin{sequencediagram}
\newthread[red]{I}{Interface}{}
\end{sequencediagram}
\end{minipage}
\end{document}

I use a document template like this on my service for online image rendering for https://upmath.me/. The documents are converted with commands like latex and dvisvgm in.dvi -o out.svg -n --exact -v0 --relative --zoom=1.25.

I have been contacted by users complaining about the lack of gradients. Enabling the dvisvgm option in documentclass helped with the gradients, but problems with extra indents appeared. Through several days of reserch and experimentation, I updated TexLive to the latest version 2024, found the pull-request https://github.com/pgf-tikz/pgf/pull/1276 and replaced the contents of pgfsys-dvisvgm.def from it, but there are still indentation issues in some cases. This is one of the two examples I have found so far.

I tried to compare the dvitype output when using different drivers, but I know nothing about the internals of the system and have not understood much about the cause of the problem and how to fix it. I hope you can help me with this.

parpalak avatar Jul 17 '24 09:07 parpalak

May be related to the /tikz/drop shadow option (which ultimately reduces to /tikz/transform canvas) used by pgf-umlsd. /tikz/transform canvas doesn't update bounding box of a tikzpicture.

Similar to #1296.

Example showing /tikz/transform canvas doesn't update bounding box

\documentclass{article}
\usepackage{pgf-umlsd}

\pagestyle{empty}

\setlength{\parindent}{0pt}

\begin{document}

% \fbox{\begin{sequencediagram}
%   \newthread[red]{I}{Interface}{}
% \end{sequencediagram}}

Actual, \texttt{drop shadow}\\
\fbox{\begin{tikzpicture}
  \draw[red, drop shadow={fill=black}] (0, 0) rectangle (1,.8);
\end{tikzpicture}}

% copied from example in doc for /tikz/preaction
Actual, \texttt{transform canvas} \\
\fbox{\begin{tikzpicture}
  \draw[red]
    [preaction={fill=black, opacity=0.5,
                transform canvas={xshift=1mm,yshift=-1mm}}]
    (0, 0) rectangle (1,.8);
\end{tikzpicture}}

Expected \\
\fbox{\begin{tikzpicture}
  \fill[fill=black, opacity=.5, xshift=1mm, yshift=-1mm] (0,0) rectangle (1,.8);
  \draw[red] (0,0) rectangle (1,.8);
\end{tikzpicture}}
\end{document}

image

muzimuzhi avatar Jul 17 '24 10:07 muzimuzhi

Yes, the example from https://github.com/pgf-tikz/pgf/issues/1296 also can be reproduced in my setup. Looks like it explains insufficient indentation on the right, but does not explain excessive indentation on the left on my first screenshot.

I understand that /tikz/general shadow has limitations as described in the documentation. However, I am unclear about the mechanism for determining the bounding box in the case without the dvisvgm option in the documentclass. Without it, the shadow works fine:

image

But with it, the shadow indeed is hidden:

image

It seems that pgfsys-dvips.def (which I assume is used without the dvisvgm option) handles the bounding box differently than pgfsys-dvisvgm.def. It would be fine for me if the dvisvgm command could determine the bounding box that contains all visible elements by itself. However, I haven't been able to achieve this. I even tried removing the instruction like dvisvgm:bbox 15.51172 14.78171 from the generated DVI file entirely, but then the dimensions of the picture turned out to be completely incorrect.

parpalak avatar Jul 17 '24 13:07 parpalak