Difference in SVG output when generated from DVI or PDF obtained from LaTeX

[Jonathan-LeRoux]

I use dvisvgm as part of IguanaTex, a PowerPoint add-in I am developing that allows user to insert LaTeX displays in PowerPoint on Windows and Mac. dvisvgm is used to create SVG files, which are then inserted and converted into PowerPoint "Shapes" (i.e., groups of freeforms).

An issue was recently reported by @tautomer on the IguanaTex repo about fraction bars not being aligned, and we found out that the problem occurred when using PowerPoint's "Convert to Shape" function on an SVG obtained from a PDF with dvisvgm. There is no problem if the LaTeX source is compiled to DVI, and then to SVG with dvisvgm. I opened the SVG files obtained from DVI and PDF in Inkscape, and the DVI one handles the bars as "rect", while the PDF one handles them as "path" (as all the other parts of the display) but that path doesn't have a height. It looks fine as an SVG, but breaks down during the conversion to freeforms in PowerPoint.

In general, bars that have straight corners tend to lead to issues, such as fraction bars or the top bar of a \sqrt sign, and I assume that's because they are (at least sometimes) handled differently than other paths. Here is an example:

Is there a way to fix this during the dvisvgm conversion?

I'm attaching a few files (.zip)
in case you'd like to take a closer look:

• PDF file compiled from LaTeX (IguanaTex_tex2pdf.pdf) and corresponding SVG file obtained with dvisvgm (IguanaTex_tex2pdf.svg)
• DVI file compiled from LaTeX (IguanaTex_tex2dvi.dvi) and corresponding SVG file obtained with dvisvgm (IguanaTex_tex2dvi.svg)

Thanks,
Jonathan

[mgieseki]

According to your SVG file, you use a rather old version of dvisvgm (2.4.2). With the current version 2.12, I can't reproduce the issue. So, if possible, please update to the latest release and the problem should go away. :-)

Edit: Sorry, I didn't read the last part of your post properly. dvisvgm converts the shapes as they are represented in the DVI, PS, or PDF file. Unfortunately, there is no easy way to replace paths by other SVG objects because that may introduce side-effects in some cases. So, I recommend to post-process the SVG files on your own and replace the desired paths as needed.

[Jonathan-LeRoux]

So the problem is with the way objects are inherently represented in DVI vs PDF in this case, i.e., DVI and PDF handle lines with straight corners in a different way, which leads them to being converted differently in SVG?

Is this post-processing (which I assume means converting paths that are not really paths but lines without contour into an actual filled path) something you could consider doing as part of dvisvgm, as an option?

I can try to handle this within PowerPoint by detecting the freeforms that have no fill, only contour, but I don't know if these are guaranteed to be lines. I could then set their height to 0 (as it should be), then convert them to contoured freeforms with a fill (which I already do when inserting EMF files). I'm just unsure if I can reliably tell which of the height and width should be set to 0. All in all, not as good as if the odd status could be handled on the SVG side directly.

Btw, I did try again with the latest dvisvgm that's available in Texlive 2021, 2.11.1, and got the same result. Not sure if there's an easy way to update to 2.12 easily within Texlive, but it doesn't sound like it will make a difference anyway.

[tautomer]

According to your SVG file, you use a rather old version of dvisvgm (2.4.2). With the current version 2.12, I can't reproduce the issue. So, if possible, please update to the latest release and the problem should go away. :-)

So I installed a MikTeX and threw the latest dvisvgm binary to the bin folder. However, I still have the problem. I'm not sure if I have done anything wrong

I ran the following command to convert a pdf to svg and still got the same problem in PowerPoint.

C:\Temp>dvisvgm.exe --version
dvisvgm 2.12

C:\Temp>dvisvgm.exe --pdf -o test.svg IguanaTex_tmp.pdf
processing PDF file
  graphic size: 597.508285pt x 845.047087pt (210.000144mm x 297.000083mm)
  output written to test.svg
1 of 1 page converted in 0.407 seconds

Probably the pdf and svg files could be useful Temp.zip?

Btw, I did try again with the latest dvisvgm that's available in Texlive 2021, 2.11.1, and got the same result. Not sure if there's an easy way to update to 2.12 easily within Texlive, but it doesn't sound like it will make a difference anyway.

@Jonathan-LeRoux So it looks like both MikTeX and TeXLive ship 2.11.1 right now, but as dvisvgm.exe is a standalone binary (I think so?), I just dropped the binary file into the bin folder of either distribution overwriting the original one, then I can get the latest 2.12 running with both distributions. Still I'm having the same problem. Not sure why.

Though I gnored the dll (ttfautohint.dll) in the released zip, dvisvgm seem to be running fine (converting dvi works). I'm not sure if there will some other hiden problem doing so.

[mgieseki]

So the problem is with the way objects are inherently represented in DVI vs PDF in this case, i.e., DVI and PDF handle lines with straight corners in a different way, which leads them to being converted differently in SVG?

Yes, that's right. DVI uses "rule" commands to place solid rectangles at certain positions. TeX creates them for fraction bars, root lines, long brackets, braces, parenthesis, and so on. dvisvgm converts these rules to rect elements. In PDF files, these lines are represented by (open) paths drawn with a certain line width, and dvisvgm converts them accordingly.

Is this post-processing (which I assume means converting paths that are not really paths but lines without contour into an actual filled path) something you could consider doing as part of dvisvgm, as an option?

At the moment, I'm a bit reluctant to implement this because the proper detection and replacement of all line-only path elements requires quite some work, especially to treat transformed paths correctly.
Furthermore, Ghostscript introduced a new PDF interpreter which is currently still optional but will replace the old one as of the upcoming version 9.56.0. This will completely break dvisvgm's PDF support since there's no longer a way to interact with the interpreter. Therefore, as it stands right now, I don't plan to invest more time into PDF features.
Isn't using DVI instead of PDF an option in your case? As PowerPoint seems to treat the SVG files created from DVI correctly, this could be an alternative, couldn't it?

Btw, I did try again with the latest dvisvgm that's available in Texlive 2021, 2.11.1, and got the same result. Not sure if there's an easy way to update to 2.12 easily within Texlive, but it doesn't sound like it will make a difference anyway.

Yes, correct. Nothing has changed in this area because there was nothing to be fixed. ;-) The SVG files are converted correctly and can be rendered properly, so it's mainly an issue with PowerPoint here. If you open the SVG files in a web browser or a dedicated SVG viewer, like Apache Batik, they are rendered as expected.

So I installed a MikTeX and threw the latest dvisvgm binary to the bin folder. However, I still have the problem. I'm not sure if I have done anything wrong

No, you did everything right. My first comment was a bit hasty because I only had a look at the conversion results of dvisvgm which are actually all correct for the given examples. The problem seems to be the proper conversion of all SVG components to PowerPoint's object model which – as I must confess – I don't know at all.

[Jonathan-LeRoux]

Thanks for your clear response.

Isn't using DVI instead of PDF an option in your case? As PowerPoint seems to treat the SVG files created from DVI correctly, this could be an alternative, couldn't it?

So far, I've given users the option to choose how they want to compile the code: (pdf)latex to dvi, or pdflatex/xelatex/lualatex to pdf. I'm not sure whether forcing the use of dvi (or xdv for xelatex) would limit what users can do: do you know of any situation where forcing a compilation to dvi/xdv would be limiting?

[mgieseki]

At the moment, I can't think of a situation where converting PDF files always leads to better or more correct results. There might be situations, though, where the DVI files doesn't contain the correct data, e.g. because a package driver creates incomplete or wrong code. Since the DVI command set is pretty limited on its own, all advanced features must be realized in terms of \special statements forwarded to the DVI processor. Especially embedded PostScript fragments allow for a lot of flexibility but can also lead to wrong results if not properly combined with the DVI positioning and text commands.

Personally, I haven't encountered a lot of examples that didn't work with DVI but they do exist, as there are also files that work with DVI but have issues with PDF.

[Jonathan-LeRoux]

Thanks a lot for your input. It sounds like the best option for me is to give the option to the user to choose between DVI and PDF as intermediate steps towards SVG, letting them know about the potential downside of the PDF route.
I will close this issue as we concluded this wasn't a problem with dvisvgm.
Thanks for your help!