Interaction issue: PGF/TikZ's 3.0 dvisvgm driver
(For anyone else reading this in in the future, this in connection with http://
I suppose you didn't expect that someone would take what you probably envisioned as the exceptional case of dvisvgm specials and generate DVI using only those specials, i.e. transforming them into a common use case. That usage basically bypasses most if not all other processing done by dvisvgm itself, i.e. uses it a thin layer to output SVG almost directly. I guess PGF driver's authors expected that the processing you do for PostScript specials (like bbox calculations) would also apply for dvisvgm specials.
You already have most of the hard work done for computing the bounding boxes for other parts of the document, so it's probably not too difficult to accommodate their driver's assumption in your code. Honestly, PGF has lots of open bug reports currently that nobody has even looked at (including some very easy to fix ones), so I'm not optimistic they'll fix/change their driver anytime soon in the direction of actually obeying the current design contract for dvisvgm's specials. I did notice that cutting out one "middle man", i.e. ghostscript, does improve performance of dvisvgm by something 3x, 4x times, so it might be relevant for someone converting/
So to actually ask some question here: are you aware of any software depending on dvisvgm's specials as they are now, i.e. with the expectation of "manual"/input bboxes required? Even if that's the case, you could add a new, non-default flag to treat both PostScript and dvisvgm's specials as "the same" kind of input. I haven't looked at dvisvgm's code at all, but given that you do treat other, more obscure specials like tfig's or emTeX's as input, I assume there's some level of abstraction/
I did file a bug report to PGF's author about their current assumption/