Ghostscript error on macOS: Unrecoverable error: limitcheck in .putdeviceprops

[tkabzinski]

Hi,

I'm trying to use IguanaTeX on macOS with PowerPoint 2016. Unfortunately, I receive the following error:

Unrecoverable error: limitcheck in .putdeviceprops

when the last command called is

'/usr/local/bin/gs' -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=IguanaTex_tmp_tmp.pdf -g50040002x45000003 -dFIXEDMEDIA -c "<</PageOffset [-148949994.9 -707021977.9]>>setpagedevice" -f '/Users/abc/tmp/IguanaTex_tmp.pdf'

to generate an equation. It seems to me as if the values after -g, which are supposed to be in unit of pixels, are quite large. If I manually execute the command in the terminal and reduce the pixel values by a factor of 100 or so, the error message vanishes. Maybe there is a problem with the unit conversions in LatexForm.frm for macOS?

I appreciate your help.

[Jonathan-LeRoux]

Thanks for reporting this. Would you mind letting me know a bit more about the settings you used? bitmap/vector, which engine, whether you used a non-default Temp folder, etc. I assume you are getting this error whatever source you try to compile?

[tkabzinski]

I have tried both the default temp directory and a custom one in my home folder, where I have write access. I can see that some .tex and .pdf files are generated in there. I receive the same error for both "Latex (DVI)" and "pdflatex" when selecting bitmap.

[Jonathan-LeRoux]

Could you take a look at the .bbx file that gets created? For example, if I just type "test" in the body of the document, I get this for the .bbx: %%BoundingBox: 148 657 165 664 %%HiResBoundingBox: 148.859995 657.125980 164.231995 663.335980 I am on PowerPoint 2019, not 2016, but I don't see how that could make a difference. The corresponding string in the command you mentioned should look like -g156x65.

If you feel like debugging, I would suggest downloading the .pptm file, opening it, then opening the Visual Basic Editor (under Tools>Macro), opening the LatexForm (right-click on it, View Code), and put a breakpoint at Line 364. Run the Macro (Tools>Macro>Macros>NewLatexEquation, after making sure the .pptm file is selected in the dropdown "Macros in:" menu), it will stop at that line. Step over (Command+Shift+O), then hover your mouse over the BBString and see what's in there. If your .bbx file looks fine, but the BBString doesn't, then there is an issue in the BoundingBoxString function. You could then step into (Command+Shift+I) that function after re-running the code and stopping at Line 364, then stepping over all the lines in that function to see where things go wrong.

[tkabzinski]

Thanks for the update.

The .bbx file looks fine.

Inside the BoundingBoxString function the conversion to double seems to go wrong (s. picture).

I assume the problem is related to the fact the my language setting is "German". However, I think here this conversion problem is discussed and can probably be fixed by adding appropriate settings, such as

                Application.UseSystemSeparators = False
                Application.ThousandsSeparator = ","
                Application.DecimalSeparator = "."

I'm just not sure where I could add these lines.

[Jonathan-LeRoux]

In this case, it may be simpler to just use Val instead of CDbl, as apparently gs uses the US conventions in its output anyway, so we should NOT try to accommodate for locales. Can you give it a try, replacing CDbl by Val? You may also need to replace CStr by Str: could you see if it makes a difference with your locale? You can do so by typing "debug.print(12345.67)" in the Immediate window and pressing Enter. Hopefully you'll get "12345.67" without a comma anywhere. I'm honestly not super familiar with these functions, and I can't remember by I have a mix of Str and CStr in the BoundingBoxString function...

[Jonathan-LeRoux]

Looking into this more, it appears that I introduced the use of CDbl on March 4, as I was trying to tweak the PDF crop sizes on Mac. But I can't see any reason why CDbl would be better than Val, so I think we should just revert to Val. I don't think there is a need to replace CStr by Str, as CStr has been in the code for a long time and nobody has reported any issue. I'll add this to my list of changes for the next version, in the meantime, please do the change in your .pptm and export to .ppam to have a functioning add-in.

Thanks, Jonathan

[tkabzinski]

Using Val instead of CDbl works fine.

I did obtain a comma in the debug print output. CStr works for me while Str does not. Str outputs an additional space in front of the first digit for positive values, which causes an error in the gs call.

Thanks for the fast and detailed support, Tobias

[Jonathan-LeRoux]

Thanks for confirming. I had typed my comment a bit too fast and meant "debug.print(CDbl(12345.67))" and "debug.print(Val(12345.67))".