#67 Error in SVG format

[Murilo Neto]

This bug is related to the bug https://sourceforge.net/p/texmaths/bugs/31/, that was corrected for earlier versions of LibreOffice.

In Kubuntu, from the 4.2 version of LibreOffice, the formulas in SVG format are rendered with a size larger than the size selected. For example, a size of formula 12pts being rendered corresponds to a size 13 or 14pts approximately.

This effect is random.

In other versions of Linux (Ubuntu Mate, Linux Mint) formulas are rendered but incorrectly (even in older versions of LibreOffice).

The formulas are with incorrect vertical alignment. They also can not be edited, resulting in the following error when we try to do it:

"The selected object is not a TexMaths equation...
Please unselect it and call the macro again..."

I explored for a long time the nature of the bug, without success.

I realized that if we add a new page to LibreOffice Writer 5.1.5.2, the problem stops occurring. But in LibreOffice 5.2.2 this palliative works, but the formulas are rendered with a larger size, as described above.

I suspect that the problem is in LibreOffice. For some reason, some of the steps of generating formulas are not running.

Formulas in SVG format continue to function normally.

[Roland Baudin]

Please send me an example of document with the problem. This will help me finding a solution.
Thanks.

[Dan Scholnik]

I'm seeing the problem with SVG math being rendered too large on LibreOffice 5.2.4.2 under Fedora 25. Sample document is attached. I can confirm that this carries over when exported as .doc and imported into Word as well. Note that I had to force the use of gtk2 instead of gtk3 to avoid the bug in the link, where some math is not later recognized.

[Roland Baudin]

I'll check tomorrow at my work but I think this problem was introduced in the 5.2.x LO version because at home I have the 5.1.x LO version and the size is OK.
So perhaps it's time to fill a new Libreoffice bug report...

EDIT: Yes, the problem was introduced in Libreoffice 5.2.x. I have no solution at this time. As a workaround, you can reduce the default font size when working with SVG equations...
The Libreoffice API constantly changes, so they introduce some regressions from time to time, this is painful!

[Murilo Neto]

Hello. Here at home 5.1 is OK too.
After some tests with versions 5.1 and 5.3 of LibreOffice, I compared the image sizes obtained in the TeXMathsEquations module of the TeXMaths macros, specifically in the MakeEquations macro.

oShapeSize.Width = oShapeSize.Width * (iEqSize / 10)
oShapeSize.Height = oShapeSize.Height * (iEqSize / 10)

The values of oShapeSize.Width and oShapeSize.Width suffer a scale of approximately 20% in version 5.3 of LibreOffice (I did not test in 5.2 but I think it is the same).

Dividing the width of the old image by the width of the new image, I got the value 0.80098039.
Doing the same with the height, I got the value 0.80208333.

In a second test, with another equation, I obtained 0.80343511 for the ratio between the widths and 0.80674847 for the ratio between the heights.

That is, there is a small variation in the ratios between measures. Even so, the values are always close to 0.8. I believe that from the third decimal place, the difference is of the order of thousandths, and ends up not being noticeable.

So to get around the problem, simply multiply the heights by 0.8. This would be a correction factor for LibreOffice versions above 5.1. We do this by replacing the original code with this (lines 756 and 757):

    oShapeSize.Width = oShapeSize.Width * (iEqSize / 10) * 0.8
    oShapeSize.Height = oShapeSize.Height * (iEqSize / 10) * 0.8

Here in Kubuntu 16.04 the solution worked correctly, even when we use different sizes of equations.

[Murilo Neto]

I recompiled the equations from Dan Scholnik's test.odt file and with this fix they were rendered correctly on my system (LO 5.3).

[Murilo Neto]

This correction also works in LibreOffice Draw, if correction factor 0.8 is also added to the part corresponding to Draw (same macro, lines 865 and 866).

oShapeSize.Width = oShapeSize.Width * (iEqSize / 10) * 0.8
oShapeSize.Height = oShapeSize.Height * (iEqSize / 10) * 0.8

[Roland Baudin]

I released today TexMaths 0.43 that fixes the issue.

[Murilo Neto]

Thank you! It works.