Description: Until LO 7.6.4 Equation editor objects, when placed inline with text with anchor "as text", had a perfect vertical alignment: i.e. the main line base of the equation was just aligned with the baseline of the text. Now with 24.2.0.2 any equation inserted in a text line is place way too low, completely inconsistent with the text. See attachment to visualize the problem. DANGER! In any Writer doc already created with LO 7.6 or previous releases with equations inline with text, any editing of equations with 24.2 will cause them to move down, damaging the document irreparably: even if you open the file back with 7.6 the equation remains out of alignment!!! Steps to Reproduce: 1.Create a writer doc with LO 24.2. Write a line of text and insert any equation inline, with Anchorage "as text". The equation objext is wrongly placed too low, and cannot be moved up so to align it to the text line 2. The equation objext is wrongly placed too low, and cannot be moved up so to align it to the text line 3.In previous LO releases, such operation resulted in an equations placed with the correct vertical alignment (see attached image to visualize the difference Actual Results: Wrong alignment of equation editor object anchored "as text" within a pragraph Expected Results: Equations with the appropriate vertical alignment with respect to the line of text as in LO 7.6.4 and before Reproducible: Always User Profile Reset: No Additional Info: ATTENTION: editing previously created docs can damage them irreparably!
Created attachment 192074 [details] Here the eqaution is too low (LO 24.2)
Created attachment 192075 [details] Here the alignment os correct (LO 7.6.4)
Confirming a change in vertical centering of an inline formula, between 7.6.4.1 release and looking at a current master against 24.8. Vertical alignment of the formula is not centered against paragraph text. OLE Formula with either sm 'Text mode' formatting or as just a formula in its OLE Frame. Looking at Properties for the OLE Frame holding the formula, the calculated position 'Vertical' with default 'From bottom' is different between the builds. With current 24.2 and 24.8 builds, seems the off sets are too low and the formula's frame is not being centered on paragraph text. =-testing-= Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b8e393686c4ab6a69b091240065f440eadfff230 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one? Thanks d2575c3ead80bd3952b16690cf5ea4d817138dcd is the first bad commit commit d2575c3ead80bd3952b16690cf5ea4d817138dcd Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Sep 19 14:35:48 2023 +0200 source 9e92a17cb6e03beedeeca40bfc8524c2623d31eb 157044: starmath: Improve glyph positioning | https://gerrit.libreoffice.org/c/core/+/157044
Update: if you involuntarily moved equations too low editing a previously created doc with 24.2, you can restore their correct placement re-opening the doc with 7.6 and editing the equations again there (it suffices to open them for editing and then closing, no need to actually change anything)
Just to update on how to live with the problem: working as I do with documents very often containing math formulas, in the end I had to give up 24.2 and regress to installing back 7.6. Let's hope this is easy to correct!
Another update: I tested the problem with freshly available 24.2.03, alas it is still there as it was in 24.2.02
*** Bug 159497 has been marked as a duplicate of this bug. ***
Good test doc in attachment 192340 [details] from dupe bug 159497 Open its zip archive, to review the settings.xml for each of the OLE sm objects holding sm "{p}({t}_{i})", extracting these stanzas: Object9's formula with new map units <config:config-item config:name="ViewAreaWidth" config:type="long">482</config:config-item> <config:config-item config:name="ViewAreaHeight" config:type="long">308</config:config-item> <config:config-item config:name="BaseLine" config:type="int">220</config:config-item> Object1's formula with the original map units <config:config-item config:name="ViewAreaWidth" config:type="long">841</config:config-item> <config:config-item config:name="ViewAreaHeight" config:type="long">541</config:config-item> <config:config-item config:name="BaseLine" config:type="int">387</config:config-item> Suggests the map unit change from 100ths of MM to twips did not get fully applied for rendering to document canvas.
Bumping to critical, the original formula placments and scaling is lost corrupting existing documents as each sm OLE formula is touched.
*** Bug 159609 has been marked as a duplicate of this bug. ***
*** Bug 159589 has been marked as a duplicate of this bug. ***
*** Bug 159627 has been marked as a duplicate of this bug. ***
I'm worried about fixing this bug. The formula alignment issue was fixed with version 3.4 a long time ago. Version 24.2 is unusable for scientists. It is therefore a regression that must be corrected as quickly as possible. Where are we ?
Increasing importance also, based on comment 10 and the speed of new bug reports regarding the issue
@Mike K. is a similar solution as for bug 157965 possible for the OLE formula positioning?
https://gerrit.libreoffice.org/c/core/+/163333
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b6ef30d1b049977beb23d28a07d77012fa1daf47 tdf#159302: Another UNO property "BaseLine" needs to use mm/100s It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fb35c64d5b7bb3c6763d09af613d9c79c657f7a9 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded @Mike, thanks for fixing this issue!!
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/df41d922ef7e6c99f72d65dad04b56c82a79ae30 tdf#159302: Another UNO property "BaseLine" needs to use mm/100s It will be available in 24.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #10) > Bumping to critical, the original formula ... scaling is lost Is scaling affected? I only saw incorrect baseline when reading here. If so, that would need separate addressing. In general, it would be good to audit the UNO code in math proactively - but I can't do it now. The function where I made this last change is a good starting point - looking through it, and checking if every size returned from it works OK (e.g., case HANDLE_RELATIVE_SPACING - so it would be good to define it, and check if asking formula spacing in macros gives the expected value).
(In reply to Mike Kaganski from comment #21) > Is scaling affected? No that was a _poor_ characterization on my part. Checked values from example in comment 9 width & height scaling 841/482 x 541/y --> 310 ~ 308 baseline placement 841/387 x 482/z --> 221 ~ 220 so the values for formula look to be scaled the same, and just the positioning for the baseline was off.
Hello everybody, I tried with : Version: 24.2.2.0.0+ (X86_64) / LibreOffice Community Build ID: 39fa034db32fa07a7f2a7afe77f7d1c047b5cad8 CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded All seems ok. Thanks for your work.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2-1": https://git.libreoffice.org/core/commit/a224f85c9bb9ab0a2e5a833dcb5ebb3eab4d7ea3 tdf#159302: Another UNO property "BaseLine" needs to use mm/100s It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have now installed 24.2.1.2 and the vertical alignment of math formulas in text has back to normal. Good! However, as I am now trying the formula editor in itself, I was faced with a puzzling behaviour: after creating a formula object, the space for the code corresponding to the formula appears below, but now while I type the characters needed, a lot of other unwanted characters are automatically inserted so as to corrupt the formula itself! Check the video I am uploading, where I show myself trying to write a very simple expression: bar x = y over z sqrt 2 Then, while I am typing a lot of braces and space symbols "~" are inserted totally corrupting the expression! In the end I then have to re-edit the cod eliminating these unwanted characters to obtain what I had written in the first place... what the earth is happening here?!? Notice that while editing the formula I a typing EXCLUSIVELY the characters you see in the line of code above! All others are inserted by the program arbitrality
Created attachment 192880 [details] Check what happens when I try to create the simple formula quoted in my last comment
(In reply to Andy from comment #25) Do you see a label here on this bug tracker, telling you that this is a general discussion forum? If not, then please try to abide to the "1 bug report per one issue" principle, snd avoid messages that don't relate to the original problem of this bug report. You are always welcome to create a new report on the new issue that you discover. There, you may briefly mention, that you discovered it when testing a fix to bug X. Thank you.
(In reply to Andy from comment #26) You're working in the now default Visual formula editor mode, which can be disabled if you prefer. But you can by entering the StarMath OLE with an enclosing { }, that seems to prevent inadvertent interpretation of input as text. Otherwise Visual mode required expanded use of {} brackets, and the ~ and ` are established sm spacing. See the help. But as Mike notes, use the Ask site or user mail list for general help, otherwise one issue per BZ.
Ok, I am really sorry for that, but I do not know if it makes sense to file a bug report for this.... I googled "disable new visual formula editor mode libreoffice" to go back to the old style, or simply "new visual formula editor mode libreoffice" to get some info and found nothing. So how do I disable this new mode??? How do I find clear documentation on the vast changes implemented? You write "see help" which of course I did, but I must say I did not find such info there. Thanks
(In reply to Andy from comment #29) > Ok, I am really sorry for that, > but I do not know if it makes sense to file a bug report for this.... > I googled "disable new visual formula editor mode libreoffice" to go back to > the old style, or simply "new visual formula editor mode libreoffice" to get > some info and found nothing. > So how do I disable this new mode??? How do I find clear documentation on > the vast changes implemented? You write "see help" which of course I did, > but I must say I did not find such info there. > Thanks With the sm Formula editor module open. main menu: Tools -> Options -> LibreOffice Math -> Settings panel Miscellaneous Options uncheck the checkbox toggle for 'Enable visual editing' apply and OK out. That will revert to the previous formula edit bar input that is fully documented. Documentation of the now default 'Visual editing' mode (exposed by graduation from experimental feature) is lagging.
(In reply to V Stuart Foote from comment #30) > With the sm Formula editor module open. > > main menu: > Tools -> Options -> LibreOffice Math -> Settings panel > > Miscellaneous Options > > uncheck the checkbox toggle for 'Enable visual editing' > > apply and OK out. > > That will revert to the previous formula edit bar input that is fully > documented. Documentation of the now default 'Visual editing' mode (exposed > by graduation from experimental feature) is lagging. Notice that this only works if you start Math as a standalone application (which is not the way to use Math, but I'm digressing): is you insert a Math object in, let's say, a Writer document, that menu option is not available. Later I'll fill a separated bug report for that.
(In reply to RGB from comment #31) > Notice that this only works if you start Math as a standalone application > (which is not the way to use Math, but I'm digressing): is you insert a Math > object in, let's say, a Writer document, that menu option is not available. > > Later I'll fill a separated bug report for that. Yes but once the attribute is set from the sm Formula module's Options, it is persistent. The legacy formula edit bar mode will be used until toggled back. Otherwise can confirm, the Tools -> Options links don't follow the formula OLE and rather remain from the target module--that of Writer in this case. Please file a BZ issue against the Formula Editor module.
(In reply to V Stuart Foote from comment #32) > Yes but once the attribute is set from the sm Formula module's Options, it > is persistent. The legacy formula edit bar mode will be used until toggled > back. > > Otherwise can confirm, the Tools -> Options links don't follow the formula > OLE and rather remain from the target module--that of Writer in this case. > > Please file a BZ issue against the Formula Editor module. Filled as Bug 159987
(In reply to RGB from comment #31) > (In reply to V Stuart Foote from comment #30) > > > With the sm Formula editor module open. > > > > main menu: > > Tools -> Options -> LibreOffice Math -> Settings panel Thanks a lot. Regarding the "visual editor", I'll postpone trying it when some documentation will be available. Right now, without any guidance, its workings appear to be quite messy, especially in relation to the fact that the code editor still exists but if you do use it things seem to go berserk. But of course it could be just a matter of understanding its logic.