Fix PowerPoint slide import across different locale settings

[RSchwan]

Hi,

When opening PowerPoint files created with different locale settings (e.g. German using 1,2 vs English using 1.2), I was getting type mismatch errors due to inconsistent decimal separator handling (it just reads it as a string). I added sanitization for numeric values during import to handle both formats, i.e., ignoring it when there was a conversion error. This fixes it on my end.

[Jonathan-LeRoux]

Thanks for bringing this to my attention, I hadn't thought about the fact that the Tags were Strings, and that the String conversion was locale-dependent. This may require a larger fix, so please allow me to think a bit more about it.

[Jonathan-LeRoux]

I addressed this slightly differently, by converting numbers with a "," decimal separator to have a "." decimal separator when appropriate. This will be part of the next 1.62.1 release.
Here is a pre-release candidate: IguanaTex_v1_62_1_20250128.zip
Could you please see if it works for you?

[RSchwan]

It now works on my machine, i.e., I can edit files from my college with a German locale. But the other way around doesn't work anymore. The problem is now that it's stored with a ".", but on a German locale machine it expects a "," and you get a type mismatch.

If you are running macOS you can actually test it quite easily. PowerPoint is taking the system settings from the "Language & Region" tab. So changing the number format from e.g. 1'234'567.89 to 1 234 567,89 breaks editing formulas from a saved PowerPoint file for me.

[Jonathan-LeRoux]

Thanks for testing. Could you point me to a line in the code that breaks with the new version?
I thought I had left everything that is handled in a locale-dependent way untouched, but I clearly got something wrong.
Thanks for the tip!

[RSchwan]

The problem arises in this line giving a type mismatch error:

If I set my number format setting to 1 234 567,89, PowerPoint tries to convert the string returned from NormalizeDecimalNumber in this format and it throws a type mismatch error. In your new code, NormalizeDecimalNumber returns always in the format with a .. The original problem was that the string stored might not match the expected number formatting. Hence, in my fix, I try to parse the string and on a failure I just set it to a default value. To do it properly, you want probably something like along these lines: https://stackoverflow.com/a/27925034.

[Jonathan-LeRoux]

I think we just need to add a val() around that and it should work (same for width).
My goal was to get everything to "." format so that functions such as val() behave as expected.

[Jonathan-LeRoux]

I think my solution is more robust than all the solutions on that post actually😂
None of them handle "1,000.01" for example.

[RSchwan]

I think we just need to add a val() around that and it should work (same for width). My goal was to get everything to "." format so that functions such as val() behave as expected.

This seems to work 👍
You can send me a new pre-release candidate and I can test it on my side to make sure everything works as intended.

[Jonathan-LeRoux]

Here is an updated version: IguanaTex_v1_62_1_20250129.zip.
I tried to save everything with "." decimal separator and read it back with a local-dependent one whenever a number is displayed (mainly the "pt" size of the display and the DPI).

[RSchwan]

The updated version works on my side and fixes the bug 👍 .

[Jonathan-LeRoux]

Thanks a lot for testing! I have released it as v1.62.1 and will thus close this PR.
Thanks for your help!