Misalignment in fraction numbers

[tautomer]

Hi Jonathan,

Thanks for you wonderful work! I'm having problem in rendering equations with IguanaTex 1.59 combined with dvisvgm package.

Environment

Powerpoint version: Microsoft® PowerPoint® for Microsoft 365 MSO (Version 2110 Build 16.0.14527.20270) 64-bit 
IguanaTex version: 1.59
Tex Live version: 2021

IguanaTex Configuration

pdflatex engine + dvisvgm for vector output

Code

\documentclass{article}
\usepackage{amsmath}
\pagestyle{empty}
\begin{document}
\begin{align}
\ln \frac{k_\mathrm{i}}{T} = -\frac{\Delta H^\ddagger_\mathrm{i}}{RT} + \frac{\Delta S^\ddagger_\mathrm{i}}{R} + \ln \frac{k_\mathrm{B}}{h}
\nonumber
\end{align}
\end{document}

The svg file in the temp folder looks great

The pdf file in the temp folder looks great as well

Inserting the svg file directly to my slides also works, but the one generated from IguanaTex is misaligned

If I renegerate the display with dvisvgm, the vincula are frequently gone. Again, the svg and pdf files in the temp folder are correct.

I'm not sure what happened. TeX2img and pdfiumdraw doesn't mess up with the alignment, though.

Also, I found TeX2img, pdfiumdraw and dvisvgm all seem to generate different font sizes though they are all supposed to be 20 pt. TeX2img and pdfiumdraw roughly gives the same size with tex2img being a littile bit larger. I wonder if there is an easy to know the right size in points to keep the generated eqautions the same size?

[tautomer]

Just an update.

I found that if I use latex(DVI) as the engine, I can get the correct display with dvisvgm.

Any idea on why all other engines fail?

[Jonathan-LeRoux]

What a mess 😃

Thanks for reporting this. I can confirm that I see the same issues on my end. It looks like the SVG generated by dvisvgm from PDF is handling the horizontal bars in a strange way. When you insert the SVG directly in Powerpoint, you don't see it, but if you click "convert to shape", you'll get back to the IguanaTex behavior (because that's exactly what IguanaTex does in the back, it just clicks the button for the user).

If you click on the bar, you will see that it is a strange object: it's supposed to be a freeform with a non-zero height, but it's only displayed as a line at the bottom of what should be the shape, and actually seems to be handled as a straight connector by PowerPoint. I opened the versions 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. The PDF one also includes the whole page instead of just the portion with content.

I'm not sure why dvisvgm acts differently when handling DVIs vs PDFs, to be honest, and that's maybe an issue to be opened with dvisvgm. I'm using version 2.4.2, which seems quite old, so it may in fact have already been fixed, but it doesn't seem easy to update dvisvgm when using TexLive. If you have MikTex, you can try downloading the latest dvisvgm Windows binary and converting by hand using dvisvgm.exe --pdf -o output.svg input.pdf.

The reason why the bars disappear when using "edit" is that IguanaTex tries to preserve the formatting used in the original display, and that original display has "no outline" as the outline format: all the parts of the display are supposed to be freeforms with a fill and no outline. But because the bars are in fact (apparently!) lines with no fill and only an outline, they disappear when regenerating, unless you click "reset format".

As for the size issues, I need to look into it. Handling size is not easy because it sometimes depends on DPI. You may have a more consistent output if you first compile to bitmap (which I believe is quite robust in terms of size), and then vectorize, as that will preserve the bitmap size.

[tautomer]

but if you click "convert to shape", you'll get back to the IguanaTex behavior

Nice to know! Indeed as you said, converting svg to shape causes exactly the same result.

The PDF one also includes the whole page instead of just the portion with content.

I think the svg is same. The emf file from tex2img only has the equation part.

I'm using version 2.4.2, which seems quite old, so it may in fact have already been fixed, but it doesn't seem easy to update dvisvgm when using TexLive.

dvisvgm shipped with TL 2021 is 2.11.1, and the latest version is 2.12. There are a couple of changes since then, but I'm not sure if they are related.

The reason why the bars disappear when using "edit" is that IguanaTex tries to preserve the formatting used in the original display, and that original display has "no outline" as the outline format: all the parts of the display are supposed to be freeforms with a fill and no outline. But because the bars are in fact (apparently!) lines with no fill and only an outline, they disappear when regenerating, unless you click "reset format".

I see. That's the reason. The good news is that it seems the bars won't disappear (even without reset format) if dvi is used. With other engines or old displays generated with tex2img, I will need the "reset format" option to keep everything there.

Handling size is not easy because it sometimes depends on DPI. You may have a more consistent output if you first compile to bitmap (which I believe is quite robust in terms of size), and then vectorize, as that will preserve the bitmap size.

I never thought about doing this at all, but it indeed makes sense. I can probably try it later. Before I had to do a binary search to find the font size that could generate the same results on my laptop, since the laptop has way higher DPI than my desktop. And after I replaced the monitor for my desktop, I had to do this search again.

But for the last screenshot, I generated the equations on the same monitor, so DPI shouldn't be the factor here. I guess there is some sort of internal scaling factors when the vector image is converted by the 3 utilities. For my case, it's roughly like

TeX2img: 24 pt
dvisvgm: 16.5 pt
pdfiumdraw: 25 pt

I can get the eqautions in the same "apparent" font size (roughly) with the size above, though the one from tex2img is slightly narrower.

[tautomer]

Man... what did I type in the title 😂😂😂

[Jonathan-LeRoux]

So it sounds like this is still an issue in the latest dvisvgm versions. I'm thinking we should file an issue on their repo. Let me know if you would like to do it, otherwise I can open one with the 2 SVG files generated from DVI and PDF.

Regarding scaling when moving between machines, it's usually a good trick to recompile an existing display with desired size while preserving the original size (e.g., using the "vectorize" or "rasterize" buttons), so that the new display has the proper rescaling factors for the current machine/display.

[tautomer]

Sorry for late reply Jonathan. Looks like you hvae done it already.

I was busy preparing for my defense (hence why dealing with equations in powerpoint).

[Jonathan-LeRoux]

The conclusion from the issue I opened on the dvisvgm repo is that the misalignments are related to the way objects are inherently represented in DVI vs PDF, which lead to strange conversions once imported in Powerpoint. Quoting @mgieseki:

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.

While it might be possible to detect those ill-formed paths in Powerpoint and fix them, I'm not sure it would be 100% robust. The easy and clean solution is instead to offer the option to have a DVI/XDV output for pdflatex/XeLaTeX/LuaLaTeX, so that the user can convert to SVG via DVI/XDV, for which there is no alignment issue.

[Jonathan-LeRoux]

I'm happy to report that I have now implemented the option to generate SVG files via DVI/XDV with dvisvgm, whatever the LaTeX engine used: IguanaTex_v1_60_0.zip. I used the occasion to completely refactor the compilation process, so I'd appreciate if you could test out the new version and let me know if you see any issue. The "SVG via DVI/XDV with dvisvgm" setting needs to be set in the Main Settings. I am still working on a few other improvements before releasing v1.60.

[tautomer]

Cool! Let me test it out when I get back home.

[tautomer]

It seems SVG via PDF with dvisvgm still causes problems. SVG (on the left) works.

[Jonathan-LeRoux]

Yes, nothing has changed for SVG via PDF, I only introduced the SVG via DVI alternative for all engines (instead of just LaTeX). It is unclear whether the bad formatting due to the way some paths are encoded in PDF can be fixed a posteriori in PowerPoint, and because going through DVI doesn't appear to have a downside, I think this is an acceptable solution.

[tautomer]

I see. I have been using DVI since I found this problem. It works great. Only one catch, what's the best way to let users know to use the DVI option if such a problem shows up? Add a note to the Main Settings dialog?

[Jonathan-LeRoux]

SVG via DVI is now the default, and once it's selected in the main settings, all engines will use it. But I agree that it might be worth considering a way to let users know what to expect. I could do this using a ControlTipText, so that an explanation pops up when hovering over that selection menu.

[Jonathan-LeRoux]

With the v1.60 release, I think we can now consider this to be fixed. Thanks again for your help!