tikzpictures which set `overlay` are invisible

[stuebinm]

While playing around with the latest git (3a6236016505d8377f6b7f9f162d812cd66a0c74), I stumbled across an interesting (though in practice, probably not often relevant) divergence between pdf & html output:

Here is a box:
\begin{tikzpicture}
\draw (0,0) -- (1,0) -- (1,1) -- (0,1) -- cycle;
\end{tikzpicture}

produces a box in the html:

but if the tikzpicture has the overlay option set:

Here is a box:
\begin{tikzpicture}[overlay]
\draw (0,0) -- (1,0) -- (1,1) -- (0,1) -- cycle;
\end{tikzpicture}

then the box is gone:

In the html, the svg it was translated to is actually still there — but with width & height set to 0, and hence invisible. I'm not sure how much can be done about it (the tikz manual states that setting overlay turns off computation of the bounding box, which it seems would be needed here), and tbh I was beyond impressed that anything tikz-related works at all; but I still thought I'd let you know in case you're not aware of it already / it is something that can be fixed by someone more familiar with RusTeX's internal workings.

(as a short postscript: this was discovered when someone asked me 'but does the coffeestains package work?' — the answer turned out to be yes, but only by using the 'internal' \stainA, \stainB by hand in a tikzpicture; \coffeestainA & friends as given in the documentation set overlay & hence fail)

[Jazzpirate]

Oh dear! That is very interesting to know, but difficult to solve... if overlay does indeed not provide a properly sized bounding box, chances are that it's virtually impossible to recover it. It's also quite possible that the solution is almost trivial if one knows pgf better than I do, though... I can't take too much credit for tikz working as well as it does though - I largely reused the existing svg backend for pgf used in (primarily) tex4ht, with some tweaks to get rid of everything being twice mirrored via transform matrices, and moving some complexity to rust directly (rather than indirectly via tex macros). That also means that some unsupported tikz features such as fadings would in principle be possible, if someone knew how to do that in svg and how the pgf mechanism works that generates those... it's all one giant rabbit hole that would be interesting to dive into if it wasn't as time consuming as it is :/