Description: Hi! After saving some formulas in .odf format, they are visually distorted, as some spacing/padding is added in several places. I will use Taylor Series example, as this is easy to reproduce, but it happens with other examples too, of course. Steps to Reproduce: 1. Open LibreOffice Math 2. Set formula from Examples/Taylor Series (penultimate example). 3. Save formula in .odf format. 4. Close LibreOffice Math. 5. Open saved .odf file Actual Results: The formula is distorted with some spaces/padding added in several places. Expected Results: The formula remains clean, as when saved. Reproducible: Always User Profile Reset: No Additional Info: After you load the saved .odf, if you create a new document (without closing LibreOffice Math), and set formula from Examples/Taylor Series in this new project, it will be distorted again, after full closing-reopening LibreOffice Math cycle.
Created attachment 200417 [details] Distorted formula
Sorry, the last sentence is wrong, it should have said: "... it will be distorted again, until a full closing-reopening LibreOffice Math cycle."
That will only happen when the Visual Edit mode of the sm formula editor is engaged. It should be disabled from Tools -> Options -> LO Math -> Settings 'Enable visual editing' disabled by default--but possibly carried over from previous release profile. Visual mode editing is known to need more dev effort. *** This bug has been marked as a duplicate of bug 160226 ***
(In reply to V Stuart Foote from comment #3) > That will only happen when the Visual Edit mode of the sm formula editor is > engaged. It should be disabled from Tools -> Options -> LO Math -> Settings > 'Enable visual editing' disabled by default--but possibly carried over from > previous release profile. > > Visual mode editing is known to need more dev effort. > > *** This bug has been marked as a duplicate of bug 160226 *** I have this option disabled. So there must be another reason. Anyways, it does not happen until you reopen LibrOffice Math and the .odf file (as indicated in Steps to Reproduce), so there are some inconsistencies somewhere.
Hi again V Stuart Foote: This bug has been marked as RESOLVED DUPLICATE: However: It is not solved. And I can´t see how it is a duplicate of bug 160226 as nothing similar is named there (as far as I can see). You didn´t answer to my previous message (I had 'Enable visual editing' disabled) Could you please justify this decision? I don't want to change the status myself without knowing your version.
(In reply to Uralion from comment #5) > Hi again V Stuart Foote: > This bug has been marked as RESOLVED DUPLICATE: > However: > It is not solved. > And I can´t see how it is a duplicate of bug 160226 as nothing similar is > named there (as far as I can see). > You didn´t answer to my previous message (I had 'Enable visual editing' > disabled) > > Could you please justify this decision? > I don't want to change the status myself without knowing your version. The example Taylor equation receives StarMath markup of: f(x) = sum from { n=0 } to { infinity } { {f^{(n)}(x_0) } over { fact{n} } (x-x_0)^n } Only when the visual editing mode is enabled (made non-default for bug 160226) will the bracketing be adjusted, and the spacing issues there be noted. You don't provide the actual command window entry for the formula, but suspect it would show: { f { ( x ) = sum to { infinity } from { { n = 0 } } { { { f ^ ( n ) ( x _ 0 ) } over fact n } ( { x - x _ 0 } ) ^ n } } } Which corrupts the node parsing for the StarMath, on reopen with Visual Mode or Command window editing. Exactly the issue of bug 160226, addressed by removing the Visual Edit mode from default. Reset user profile. Or at least from the sm Formula editor open, select Tools -> Options -> LibreOffice Math and uncheck the 'Enable visual editing'. Apply and OK. Then *restart* LibreOffice, and back into sm Formula editor. Formula node spacing should be recovered, and the legacy node edit mode correctly tracking from command window to formula node elements. Should be correct, even for formulas that had bracketing "adjusted" for Visual Edit mode. The reset and restart is needed to fully clear any residual of the Visual Edit mode.
Hi V Stuart Foote, I will say it for the third time: I have and have always had 'Enable visual editing' option disabled. The command entry is the default formula from LibreOffice Math´s Taylor example, so I did not change anything. But I will provide more evidence about this bug: I noticed that if I change 'Format/Fonts.../Formula Fonts/Variables' font to something other than 'Liberation Serif', the spacing/padding is restored to normal, and the formula looks like expected. So this is basically what happens: You open LibreOffice Math You load Taylor example with Liberation Serif as Variables font. -> The formula looks great. You save the file as .ODF. I will say it again: .ODF. You close LibreOffice Math You reopen LibreOffice Math You load the saved .ODF file. -> The formula is broken with big gaps. You change 'Format/Fonts.../Formula Fonts/Variables' to 'Arial' (for example). -> The formula looks great.
Yep you are right, thanks for pushing back. There *is* something going on with the 'InlineEditEnable' stanza and the node spacing for rendered formula nodes. Sometimes they space correctly, somtimes the horizontal spacing of nodes is stretched out. But reload of an .odf formula may or may not clear it. Deleting profile to allow rebuild with defaults, the Tools -> Options -> Advanced Open Expert Configuration dialog, a search for 'InlineEditEnable' stanza shows it is unmodified and 'false' (as expected for bug 160226). But, opening a sample formula (.odf) holding the Example Taylor Series example (either with expanded StarMath bracketing of Visual mode edit, or just the default example) will render the formula with excess spaces. If I then edit the 'InlineEditEnable' stanza from expert config and set it enabled to 'true' and restart LibreOffice. Then reopen expert config and set it to 'false' (so it records into registrymodifications.xcu) and restart LO again. The .odf will open with normal spacing. Also, seemed to do similar if I opened sm Formula editor and cycled the settings of Tools -> Options -> LibreOffice Math -> Settings 'Enable visual editing' checkbox. 1. on 2. restart 3. off 4. restart Then back to normal spacing. =-testing-= Recent master against 25.8.0 Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6869da60961a6213fc961c2ece371c0f18038cde CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded likewise on Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 28; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 200500 [details] .odf Formula of the Taylor series example with extended Visual Mode bracketing
Created attachment 200501 [details] .odf Formula of the Taylor series example with normal node layout
Confirming that using the sm Formula 'Fonts...' dialog to change the 'Variable' font to something other than default Liberation Serif (the italic is assigned by the sm UI) results in a well formatted spacing for nodes. Maybe something slipped for calculating synthetic 'italic' for the nodes with Variables font selection.
Thank you V Stuart Foote! In my case neither cycling 'InlineEditEnable' setting nor 'Enable visual editing' has worked. (I tested both of your files) The only think working for my is changing 'Variables' font. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded
I can’t reproduce any of this, but since synthetic fonts seem to be involved, it might be related to/duplicate of bug 164467.
(In reply to Khaled Hosny from comment #13) > I can’t reproduce any of this, but since synthetic fonts seem to be > involved, it might be related to/duplicate of bug 164467. Thanks Khaled, could you poke us to retest when our LO HarfBuzz is updated to 11.2.0
Created attachment 200659 [details] clip from master with HarfBuzz 11.2.0 and still issue with synthetic italic for LibreationSerif nodes (In reply to Khaled Hosny from comment #13) > I can’t reproduce any of this, but since synthetic fonts seem to be > involved, it might be related to/duplicate of bug 164467. OK, tested with the 20250503 nightly of master against 25.8.0 with HarfBuzz 11.2.0 in place. No improvement. STR of comment 8, with restart of LibreOffice and the InLineEditEnable stanza in profile. But also once the extra space manifests in the nodes--simply using the Format -> Fonts... or SB Properties -> Fonts dialog to modify 'Variables' and uncheck or check the 'Italic' Attribute (so no font change from Liberation Serif needed). It will cause the extra node spacing to assert or clear following the setting of the Italic attribute checkbox.
Thank you very much for the information and for your interest, V Stuart Foote!