Equations being cropped

[magicbycalvin]

First of all, thank you very much for building and maintaining such a wonderful tool.

I have used IguanaTeX for a while now and haven't run into issues until today. When I try to generate certain functions, the resulting image will crop part of the equation. Here are a few examples along with the code I used to generate them (I am including the bounding box drawn by PowerPoint in case that information may also be helpful): `\documentclass{article} \usepackage{amsmath} \usepackage{amssymb} \pagestyle{empty} \begin{document}

$$ p \begin{pmatrix} \mathbf Y \ \mathbf y^* \end{pmatrix} $$

\end{document}`

`\documentclass{article} \usepackage{amsmath} \usepackage{amssymb} \pagestyle{empty} \begin{document}

$$ a^2 + b^2 = c^2 $$

\end{document}`

`\documentclass{article} \pagestyle{empty} \begin{document}

$$ f(x) = \sum c_i \phi (x) $$

\end{document}`

I initially ran into this issue using version 1.57 but continue to experience it after installing the most recent version, 1.58. Here is a screenshot of the settings I am using:

Please let me know if I can provide any more information to help resolve the problem. Thank you for your time!

[Jonathan-LeRoux]

Hi,

My guess is that it's an issue with Ghostscript. Can you try upgrading Ghostscript to the latest version? If that doesn't work, you can try downgrading. I use 9.26 and it works fine.

Thanks, Jonathan

[magicbycalvin]

Looks like that was the problem. Reverting to 9.26 and even using the most recent 9.53.3 version worked. I will be sticking with 9.26 though.

Thank you very much for the quick reply and solving my problem so fast!

[Jonathan-LeRoux]

Great, I'm glad it was an easy fix. Someone else had reported a similar issue on the mailing list.

[agrawalprash]

@Jonathan-LeRoux I think I am also seeing the same issue, but switching to Ghostscript version 9.26 does not help (also tried with the latest version Ghostscript 9.55.0).

Here is the LaTeX code I am trying to render: `\documentclass{article} \usepackage{amsmath} \pagestyle{empty} \begin{document}

$|m_1|$

\end{document}`

And this is what my main settings dialog looks like:

This is how IguanaTeX renders it (notice the missing right bar):

The problem is only with the vector mode and does not appear with bitmap mode.

Can you please help me figure out what's going wrong? Thanks.

[Jonathan-LeRoux]

I'm not sure this is the same issue, and could be because the last bar is dropped when inserting in PowerPoint. We sometimes have issues, ironically, with the simplest shapes which only use a straight line, such as the top bar of a square root sign, an equal sign, etc. Have you observed this cropping behavior with other symbols? Could you look in your temp folder to see at which step it got dropped? I will try on my end later today.

[agrawalprash]

@Jonathan-LeRoux Thank you very much for such quick reply.

I tried rendering square root ($\sqrt{3}$), equal sign ($=$), single bar ($|$), and $|f|$ (all separately). All of them were rendered as expected. However, rendering $|h_1|$ leads to the same cropping behavior as above.

Interestingly, $|m_1|${\color{white} x} acts as a workaround and it shows the right bar but $|m_1|\ $ (with a forced whitespace) does not work and it shows the same cropping behavior. Perhaps related: when I try to edit the display generated by $|m_1|${\color{white} x} and "regenerate" without making any change to the LaTeX code, the white color is ignored and x appears in black!

I do not know how to read items from the temp folder. Sometimes I see an image file containing a very pixelated version of "m_1". Other times, I see nothing in it.

Please let me know if you would like me to provide any other information. Thanks much for your help.

[Jonathan-LeRoux]

Adding something white is only a workaround, and it will indeed break when editing, as by default IguanaTeX applies the formatting of the original display to the regenerated one, and in the case of a vector shape, it takes that formatting from the first element of the shape, usually the left most one... Not ideal, but I can't think of a better way to do this as the regenerated display may have completely different content from the original one, so we need to pick a single formatting (or none at all, but that's not great either because typically a user may have added a lot of formatting to a shape and only wants to slightly modify the LaTeX display).

Could you send me a zip of all the temporary files that get generated when you compile the $|m_1|$ example?

[agrawalprash]

@Jonathan-LeRoux Thank you for that insight about the behaviour on edit. That explains it.

I am attaching the zip file containing the generated temporary files (I switched on 'debug' and generated a fresh LaTeX display to capture them in the temp folder). iguanatex-tmp.zip .

[Jonathan-LeRoux]

I see, you're using EMF, and the problem is already in the EMF file. I'm guessing it's an issue with Tex2img, so you may want to try a different version of that software. Or, you could try using IguanaTex v1.59 (see https://github.com/Jonathan-LeRoux/IguanaTex/releases): it also has a slightly different way to generate EMF using Tex2img's pdfiumdraw, and can generate SVG (if you have Office 2019 or 365) instead of EMF.

[agrawalprash]

Yay, that worked (IguanaTex v1.59 on Office 2019)! Thank you very much for such great support. And thank you for building such a useful tool. Cheers!

UPDATE: Adding the results I obtained with other settings on IguanaTex v1.59 (so yes, only EMF via TeX2img is broken):

[Jonathan-LeRoux]

Thanks for posting the comparison, this is very helpful!