TikZ-CD rendering produces excessive whitespace / incorrect bounding box in latest version

[edl7878]

Description

When rendering tikz-cd diagrams via the [tikz] block in the latest version of Kroki, the output image contains excessive whitespace (incorrect bounding box calculation). This issue did not occur in previous versions. Adjusting \documentclass options or manually resetting the bounding box via \pgfresetboundingbox does not resolve the issue, suggesting a regression in the server-side TikZ compilation or SVG conversion pipeline.

Minimal Reproducible Example

[tikz]
----
\documentclass{standalone}
\usepackage{tikz-cd}
\begin{document}
\begin{tikzcd}
    &&& \\
    &&& {Watch\ Band} \\
    {*} &&& {Watch\ Front\ Cover} \\
    &&& {...} \\
    &&&
    \arrow["f_1", from=3-1, to=2-4]
    \arrow["f_2"', from=3-1, to=3-4]
    \arrow["f_i"', from=3-1, to=4-4]
\end{tikzcd}
\end{document}
----

Expected Behavior

The rendered SVG/PNG should be tightly cropped around the diagram content with minimal padding, consistent with the behavior of standalone document class and previous Kroki versions.

Actual Behavior

The output image has significant extra whitespace surrounding the diagram. The bounding box appears to be calculated incorrectly, ignoring the actual content boundaries of the tikzcd environment.

ps. kroki 0.28.0 docker image works correctly.

[ggrossetie]

Thanks for the detailed report! I dug into this and can confirm the root cause.

This is a side effect of #1926 ("Fix bad tikz render due to bad documentclass"), which made tikz2svg always overwrite the user-supplied \documentclass{...} with \documentclass[tikz,dvisvgm]{standalone}. That change was needed to fix #1870, where PGF shadings/gradients (e.g. ball color) rendered as a blank page because the dvips driver (used by default when no dvisvgm option is set) emits PostScript specials that dvisvgm can't interpret.

I reproduced both behaviors in a texlive/texlive container using the diagram from this issue:

documentclass	SVG size (dvisvgm graphic size)
\documentclass{standalone} (pre-#1926 behavior)	175.9pt × 65.3pt — tight crop
\documentclass[tikz]{standalone}	175.9pt × 65.3pt — identical, tikz has no effect on the bbox
\documentclass[dvisvgm]{standalone}	184.4pt × 116.2pt — matches the reported bug
\documentclass[tikz,dvisvgm]{standalone} (current kroki behavior)	184.4pt × 116.2pt — identical to dvisvgm alone

So tikz is not the culprit.
It's specifically the dvisvgm driver option (which #1926 correctly added to fix gradients).

Under the dvips driver, dvisvgm derives the SVG bounding box from the actual ink on the page. Under the dedicated pgfsys-dvisvgm.def driver (loaded via the dvisvgm class option), PGF instead tells dvisvgm to honor the bounding box it computes internally for the picture. For a tikz-cd matrix, that includes empty rows/columns used purely for spacing, even though they contain no ink. This diagram has an empty first row and an empty trailing row, which is exactly what inflates the bounding box.

Removing just those two empty rows from the matrix (keeping [tikz,dvisvgm]) brings the height down from 116.2pt to 72.9pt.

So this isn't a simple regression to revert. dvisvgm is required for correct shading/gradient support (#1870), and the looser bounding box is a side effect of PGF's own driver behavior with matrix-based content, not a kroki-specific bug in the strict sense.

Workarounds

1. Remove genuinely empty rows/columns in the matrix if they're only there for spacing — this alone gets you most of the way to a tight crop.
2. Explicitly set the bounding box at the end of the tikzcd content, e.g.:

   \begin{tikzcd}[name=M]
     ...
     \path[use as bounding box] (M-2-1.west) rectangle (M-3-4.east);
   \end{tikzcd}

   Note: \pgfresetboundingbox alone (as tried in the description) won't help. It clears the box but doesn't define a new one. With the dvisvgm driver, an explicit use as bounding box path is honored, unlike with dvips.
3. As a last resort, post-process the output SVG/PNG with an external trim tool (svgo, ImageMagick -trim, etc.).

A proper kroki-side fix would likely mean adding an auto-trim/crop post-processing step to the tikz2svg pipeline, which is more involved than a one-line change. Happy to discuss if that's a direction worth pursuing.

[edl7878]

It seems that \path[use as bounding box] cannot be used inside a tikzcd environment.

I tested the "remove empty rows" approach on the Kroki website, and there still appears to be extra whitespace (at the top, bottom).

I think our primary goal should be backward compatibility: the whitespace behavior in the new version needs to remain consistent with the old one. In my testing, the new version sometimes adds excessive whitespace, while other times it crops too aggressively.

Essentially, we have two options:

1. Maintain compatibility: Keep the old behavior and accept that shadows and gradients are a known issue.
2. Break compatibility: Support shadows and gradients, but require users to either modify their TikZ code or post-process the output images.

Given that Kroki 0.28.0 already works very well, I believe it is more worthwhile to stick with the legacy behavior until a complete solution is ready.

[edl7878]

Users typically author their diagrams elsewhere and then paste the code into a TikZ block for rendering. Ideally, users should have precise control over every aspect of the output via their TikZ code, with Kroki acting solely as a faithful renderer. While optional cropping is a good idea, it inevitably introduces additional complexity.

The core issue right now is that users cannot effectively control the output through their TikZ code alone. Due to underlying driver dependencies or the rendering pipeline, users are forced to adapt their code specifically for Kroki. However, Kroki should ideally be a transparent layer that renders content as-is without any side effects.