<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Replacement of SVGFilter by SVGIO still causing regressions and breaking extensions (e.g. TeXMaths)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=119332#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Replacement of SVGFilter by SVGIO still causing regressions and breaking extensions (e.g. TeXMaths)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=119332">bug 119332</a>
from <span class="vcard"><a class="email" href="mailto:sergio.callegari@gmail.com" title="sergio.callegari@gmail.com">sergio.callegari@gmail.com</a>
</span></b>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>