Description: After bug 118254, there appears to be still a regression in the management of svg files following the replacement of SVGFilter by SVGIO. This results in the breakage of extensions (at least TeXMaths) and prevents ubgrading to LibO6.1. Specifically, svg images inserted /programmatically/ into a draw/impress document appear smaller than they should (and looking at the image dimension in the properties window also physically take smaller dimensions). This is strange, since svg images inserted from files take exactly the same dimensions both in LibO 6.0 and LibO 6.1. To quickly replicate the issue, please have LibO 6.1 installed and add to it the TexMaths extension (https://sourceforge.net/projects/texmaths/). Also assure that you have some Latex distribution installed on your system as TeXMaths depends on it. Check that TeXMaths is correctly configured to find the necessary LaTeX components (aka at least the latex executable, the dvipng executable and the dvisvgm executable, the latter being indispensable to deliver svg images for the equations). From LibO 6.1, open the attached sample document, which contains 2 TeXMaths equations (one looking as an A and another one looking as a B) in a box (that is there to help evaluate the relative size and alignment of the two) and which was originally prepared with LibO 6.0. Select "B" and press the "TexMaths equations" button in the TexMaths toolbar. A window should open. Just press the "LaTeX" button there, to re-generate the equation image. The "B" symbol is now much smaller than the "A" and not anymore bottom aligned with it. Now select "B" again and re-press the "TeXMaths equations" button. In the window, switch to "png" mode in the "image format" section. Press "LaTeX" again. Now the symbol "B" is back to the correct size, showing that the issue is only specific to the rendering of the svg equation. If you do the same test with LibO 6.0, you'll see that the B symbol stays in the correct size both with LibO 6.0 and LibO 6.1. Being that TeXMaths uses exactly the same code in both cases, there is evidently a regression or at least an undocumented difference in the way svg images are programmatically imported into a LibO drawing from version 6.0 to version 6.1. The bug has also been reported to the TexMaths developer at https://sourceforge.net/p/texmaths/bugs/104/ in case the different behavior in LibO is intentional and merely needing documentation so that it can be worked around in extensions such as in TeXMaths. Steps to Reproduce: See description Actual Results: See description Expected Results: See description Reproducible: Always User Profile Reset: No Additional Info: Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: it-IT (en_US.utf8); Calc: threaded
Created attachment 144255 [details] Sample document to reproduce the issue according to instructions in the report
Simple formula a+b/c-d\times e = f generates in .../TexMaths/tmp/tmpfile.svg image with <svg height ='9.96264pt' ...> that is equal to 0.3514598 cm. If we look at properties of inserted image into .odt with TexMaths we find that height is equal to 0.35 cm in libreoffice6.1 but 0.42 cm in libreoffice5.4 (and 6.0). If image inserted with writer native tool, it's height is equal 0.35 cm for any office version.
Tested with 6.1.1RC1, cannot get the same measurements. With a+b/c-d\times e = f I am also getting 9.96264pt in the temporary svg file which should be about 3.51 mm (assuming 72 pt/inch). For that formula, TeXMaths in svg mode produces in the above mentioned version of draw an image that is 4.23 mm high. For that very same formula TeXMaths in png mode produces in the same LibO draw an image that is 4.94 mm high. Interestingly, the temporary png file is 84 pixel high, at a 96 pixel/inch resolution, that is 22 mm high. If I try inserting directly those svg and png images by insert->image, they come out 3.77 and 22 mm respectively. If I do the same tests with LibO 6.0 I get that the svg image generated by TeXMath is still intrinsically 9.96264pt high, but that it gets inserted by TeXMaths as an image that is 4.93 mm high. Inserting the temporary svg file generated by TexMaths by image->insert, I still get an image that is 3.77 mm high, just as in LibO 6.1.1 RC1. My impression from these numbers is that: - The tools that TeXMaths uses to generate svg or png images result in some scalings that TeXMaths tries to internally compensate. - When inserting svg images "programmatically" rather than via insert->image LibO <= 6.0 and LibO 6.1 do different things. This may be a regression, however, the impression I am getting is that it is LibO 6.1 that does the right thing. - Because TeXMaths uses the programmatic interface and the same scaling compensation for all LibO versions, the results one gets in LibO <= 6.0 and LibO 6.1 are different. Furthermore, because TeXMaths uses the scaling compensation that works fine in LibO <= 6.0, the results look wrong in 6.1. If these considerations are right, what happens in LibO 6.1 is not a regression, rather the fixing of a bug in previous LibO versions. In this case, it should be TeXMaths to be fixed, to now use a correct scaling compensation (or possibly two, differentiating the behavior for LibO <= 6.0 and >= 6.0). Now, my knowledge of StarBasic and its LibO API is too poor to check the TeXMaths code myself. However, I hope that the TeXMaths author can have a word here before we close the bug.
I read the latest updates in https://sourceforge.net/p/texmaths/bugs/104/ and it seems things are fine now. Thanks for the help, Sergio!
Sorry I still had not closed the bug here, thanks for doing it for me!