dvisvgm

Interaction issue: PGF/TikZ's 3.0 dvisvgm driver

Asked by Respawned

(For anyone else reading this in in the future, this in connection with http://tex.stackexchange.com/questions/194126/did-one-manage-to-get-the-new-dvisvgm-driver-from-pgf-3-0-to-work)

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/typesetting lots of figure files. (That's not me though, I was mostly checking out PGF's 3 new features.)

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/generalization in dealing with input specials from different domains implemented already.

I did file a bug report to PGF's author about their current assumption/implementation: https://sourceforge.net/p/pgf/bugs/328/

Question information

Language:
English Edit question
Status:
Solved
For:
dvisvgm Edit question
Assignee:
Martin Gieseking Edit question
Solved by:
Martin Gieseking
Solved:
Last query:
Last reply:
Revision history for this message
Best Martin Gieseking (martin-gieseking) said : 		#1

The dvisvgm:raw special was added to provide a simple method to insert arbitrary character sequences at the current location of the SVG tree being created. dvisvgm doesn't try to understand the meaning of these characters and doesn't check if the resulting SVG file is still valid either. It would be a lot of work to add a parser that analyzes the semantics and the context of the inserted SVG snippets in order to derive proper bounding box information. The SVG standard is rather complex and allows many tricky constructions that had to be supported if the intended computations should lead to correct results for arbitrary raw snippets.
At the moment, I'm reluctant to invest so much of my spare time for a feature that is barely used. As far as I know there are only few applications (e.g. Asymptote) that insert raw specials into the generated TeX files. It should be pretty easy for these applications to add the required bbox specials to get the bounding box updated correctly.

Revision history for this message
Respawned (respawned) said : 		#2

Thanks Martin Gieseking, that solved my question.