Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong Indentation with pgfsys-dvisvgm.def #1353

Open
parpalak opened this issue Jul 17, 2024 · 2 comments
Open

Wrong Indentation with pgfsys-dvisvgm.def #1353

parpalak opened this issue Jul 17, 2024 · 2 comments

Comments

@parpalak
Copy link

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 #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.

@muzimuzhi
Copy link
Member

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

@parpalak
Copy link
Author

Yes, the example from #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants