#104 Texmaths scaling issues with svg equations on LibO 6.1

[Sergio Callegari]

Looks like, after bug 98, there is another blocking issue for using texmaths with svg mode in LibO6.1.

Specifically, the change in the management of the svg import in LibO6.1 is now causing a severe scaling issue with svg math produced by TeXMaths.

In practice, if you insert an equation in draw/impress in svg mode with LibO6.1, it renders into a much smaller (scaled down) item than it should.

You can see this by trying texmaths with both LibO6.0.x and LibO6.1 on the same document. Insert the very same equation twice, once with LibO6.0 and once with LibO6.1. The one produced with LibO6.1 will render as a much smaller item. Alternatively, open with LibO6.1 a draw/impress document with a texmaths svg equation made with LibO6.0.x and try to re-render the equation. The equation will appear much smaller.

The issue can be verified also staying in LibO6.1 only, by rendering the same equation first in png and then in svg mode. The size of the rendered equation will be completely different.

The issue makes it impossible to edit documents with equations prepared with LibO < 6.1 with LibO 6.1, because the equations will get mismatched sizes and is thus a blocker IMHO.

Interestingly, when inserting svg images from files, LibO respects the image sizes exactly in the same way in LibO 6.0 and 6.1, so the issue may not be (completely on the LibO side).

In any case, I am crossposting this issue to the LibO bug tracker too.

[Sergio Callegari]

Also follow the issue on the LibO tracker at https://bugs.documentfoundation.org/show_bug.cgi?id=119332

[Sergio Callegari]

Please, follow the results on the analysis of the bug on the Libreoffice tracker.

It looks like LibO <= 6.0 was miscaling svg images when they were inserted "programmatically", while LibO 6.1 uses the same scaling both in insert->image and on an image insertion done from starbasic.

Most likely TeXMaths was internally compensating this scaling.

If this diagnosis is correct, I suppose that:

• the issue cannot be considered a regression in LibO 6.1. Rather LibO 6.1 is doing right something that previous versions were doing wrong.
• TexMaths needs to check whether it is running on LibO <= 6.0 or >= 6.1 and apply different scaling compensations in the two cases.

[Roland Baudin]

OK, thanks a lot for your investigation. I'll fix the issue in TexMaths, this should be simple.
I'll post here a pre-version so you can test it.

[Murilo Neto]

I also noticed this problem with this version of LibreOffice.
Using on Manjaro Linux.

No problem with png rendering.

In SVG rendering, in addition to the scale problem, there is also an error in the alignment with the base line.

[Sergio Callegari]

Just a quick question (not an attempt to push), to make sure about the test version. Is it going to appear here as an attachment or a link? Asking because: (i) I am not that used to the sourceforge issue tracker and (ii) I would not like the test version to remain pending and untested while I am not aware it is there. This message is also for testing that I am getting email notifications for this bug.

[Roland Baudin]

It will appear here as a link, so you can download it.

[Roland Baudin]

Here is the test version: http://roland65.free.fr/texmaths/releases/TexMaths-0.46.2.oxt
Could you test it please?
Thanks,
RB

[Sergio Callegari]

Hi, looks certainly better than before, but I am still encountering a scaling difference wrt LibO 6.0.

For instance, in a sample document, an equation size goes from 29.37x6.75 when the document is edited in LibO 6.0 to 29,17x6.24 when it is edited in LibO 6.1. Typically, the larger the equation, the more noticeable the difference.

A nice way to see the difference is to open with LibO 6.1 a document with an equation rendered by LibO 6.0 and to reprocess the equation via TeXMaths. Then, if you "undo" pressing CTRL-Z multiple times, for some reason you get both the old and the new svg images overlapped one on top of the other with the left-top corner aligned. Hence you can immediately visually see if the image sizes are the same or not.

Unfortunately the procedure above also exposes a bug (which is most likely in LibO 6.0 and 6.1 rather than in TeXMaths) that makes LibO immediately crash if you try to perform any operation after undoing some TeXMaths rendering by multiple CTRL-Z.

As a final note, observe that there is also a difference when going from svg to png, but this is not such a big issue, because: (i) you are likely to decide once and forever whether to stay with svg or png for the equations in your docs and (ii) some of the difference seems to be related to the clipping of the png.

[Roland Baudin]

Unfortunately, the scaling factor is not constant for all equations... It slightly changes, so I used an averaged value of 1.2 for both width and height.
A value of 1.25 would perhaps be slightly better, but not perfect for all cases...
The test version above is updated with the 1.25 scaling factor. Give it a try if you want...

[Sergio Callegari]

Thanks for the explanation. Can you hint at where is the corresponding code with the constant in the package? I am a zero in StarBasic, but still I think that I should be able to experiment a little with the 1.2 and 1.25 values.

Furthermore, out of curiosity, could you get an idea of what has really changed from LibO 6.0 and 6.1? Is 6.1 indeed correcting an inconsistency that was going on when importing an svg image from the GUI and programmatically?

[Roland Baudin]

The code is lines 642 and 643 of the TexMathsTools module.
I don't know anything about the changes in LibreOffice between versions 6.0.x and 6.1.x, but this is not the first time they make such a change. There was already one in version 5.2...

[WC Leung]

Removing the 0.8 scale factor appears to be good to me (I've edited the extension code myself), because picture appeared to be exactly 0.8 times its original size.

BTW, since the scaling is so weird across different versions, I'd recommend writing the function GetSVGScaleFactor() to get the ratio (i.e. 0.8 or 1.0).

Anyway, the logic in the odt above does not look good. I have no reason to believe that that 1.25 multiplies with 0.8.

[Sergio Callegari]

I have finally had a chance to look at the code and make some tests. I am getting the feeling that LibO 6.1 simply reverts (fixes?) a weird scaling of svg images that was introduced in versions from 5.2.0 to 6.0.x, which compelled TexMaths to introduce a scaling by 0.8 for Val(sVersion) >= 5.2.

This is consistent with Roland's observation that a scaling factor is needed in LibO6.1 and that a value of 1.2 seems OK and a value of 1.25 might be better.

This is also consistent with WC Leung observation that merely removing the initial 0.8 factor makes LibO 6.1 work fine. It is not a case that 0.8 times 1.25 = 1!

With this situation, I suggest that rather than applying two scale factors one after the other, one simply modifies the code to be:

' If LibreOffice version >= 5.2 and < 6.1 and SVG format, 
' reduce image size to mimic the text font size
    If Val(sVersion) >= 5.2 And Val(sVersion) < 6.1 And sEqFormat = "svg" Then

        ' Get actual image size
        oImageSize = oImportShape.Size()

        ' Set image size
        oShapeSize.Width = oImageSize.Width * 0.8
        oShapeSize.Height = oImageSize.Height * 0.8
        oImportShape.setSize(oShapeSize)

    End If

[Roland Baudin]

You're right! I updated the test version with this fix:
http://roland65.free.fr/texmaths/releases/TexMaths-0.46.2.oxt

[ederag]

Indeed, the scaling is back to normal with this version.
Thanks to Sergio for the thorough investigation, and to you for this great extension !

[Oon-Ee Ng]

Any chance this gets officially released?

[liofeu]

Hello, I have a similar issue, under Mac osx 10.12, TexMaths-0.46.2, LO 6.1.4.2:

• the image is always far bigger than it should (almost A4)
• Before the math equation starts (e.g. x=y), there is always written in the image top:
  [10pt] article
  amsmath amssymb fontspec unicode-math [usenames]color
  empty document x=y

[Filip Sroubek]

I have noticed the same problem with TexMaths-0.46.1 after switching from LO 6.0.7 to 6.1.5 on Ubuntu 18.04.2. I was relieved, after seeing the solution here. I have tried TexMaths-0.46.2 from the link above, but unfortunately the incorrect scale in svg equations is still present. Maybe the problem cannot be solved so easily. I am willing to do more tests, but someone has to tell me what.

[ederag]

It seems to work here, tested again with LibreOffice 6.1.3.2, Texmaths 0.46.2.

I am willing to do more tests, but someone has to tell me what.

For instance, "rendering the same equation first in png and then in svg mode"
yield the same size here.
The size of upper case letters such as 'D' (not lower case 'n' !)
of libreoffice text (tested with noto sans)
and Texmaths (tested with package sfmath or \textsf{D})
match perfectly.

[Filip Sroubek]

This is interesting. I am using the latest LO 6.1.5.2 (Write and Impress) and I tested Texmaths 0.46.2 on both Ubuntu 18.04.2 and Windows 10. The size of equations is correct in the case of png rendering but too small in the svg mode. The behaviour is exactly the same as for Texmaths 0.46.1. Could someone else confirm that on the latest LO 6.1.5.2 the workaround in 0.46.2. does not function correctly or there is some specific problem on both of my systems.

[Sergio Callegari]

I am exactly on 6.1.5.2 with ubuntu 18.10, and things look fine at least in impress/draw...
Can you check that the macro code is OK according to the Nov comments?

[Filip Sroubek]

This is weird!?! Could you please tell me how to check the macro code? I have just installed 0.46.2. over 0.46.1. using LO extension manager. The oxt files are binary.

[Sergio Callegari]

Sorry, my fault. I should have used a bit more words. Wanted to know if you were expert enough with the macro language to check that the macro code you are running is the same as the one in the examples, to verify if the issue could be caused by something gone wrong in the extension manager update procedure (e.g. a partial upgrade). From your answer, I guess not.

New question if you can help... Can you start LibO with a clean profile, install the TexMaths extension there (so we have a fresh install) and try again? You can start LibO with a clean profile in many ways...
1) Using the -env: command line option
2) Moving your current configuration profile elsewhere from the standard location (and then restoring it back in place)
3) Creating a new temporary user in your operating system and testing there
If in doubt, 3 is probably the safest.

[Filip Sroubek]

I have tried the second option in Windows 10: moved my configuration in AppData/Roaming/LibreOffice/ to a different directory, run LO Draw and installed TexMaths 0.46.2.

The result is even more confusing. The svg mode again generates smaller equations than the png mode. What is even more disturbing is that the svg equations are now more thick compare to png, which looks as it should. When I put back my original configuration directory, the svg equations have correct thickness. They are smaller than png as before.

Can anyone tell me what is going on? Why the svg mode in a new environment behaves differently? There are no such options in the TexMaths configuration that would address this issue. There must be something in my original configuration directory that changes the thickness. So currently the only reliable and consistent way of generating equations is to use the png mode.

[Filip Sroubek]

Ok, the thickness is because the default is OpenGL rendering on in LO and this makes svg equations too thick. However, tha size issue persists.