When inserting math formulas in writer, the command window becomes by itself full of brackets
when the relevant math formula icon in the writer is slighly changed for instance by adding a space.
How to avoid one for ever this noisy and confusing automated feature?
I enclose two images: Math1 shows command window and math icon when formula is inserted from the command window without touching the icon
Math 2 shows the command window full of brackets just after touching the icon: a letter ‘a’ has been inserted. Of course the command window becomes useless.
Although ‘auto close brackets, …’ is unset, the automated feature persists.
Vesion 24.2.3.2 (x86_64), Windows 11.
Added images
Re-open your question by clicking on … below it, then the “pencil” icon. You’re now in edit mode. Simply drag your image file (JPEG or PND) over the edit window. You can also click on the “Outbox with up arrow” in the toolbar to open a file browser.
Are you writing the formula from scratch or have you copied the formula from somewhere and now want to edit it?
Is the document in odt file format or do you have opened a docx document?
Could you please attach a short document with a formula that has these tons of brackets?
You took a snapshot of your screen and this is unusable because it results in Moiré pattern between the pixel grid of your screen and the sensor of the imaging device. All I can tell (unable to read the scripting description) is this looks like nested functions but i don’t identify the usual Math macros, apart from stack { }.
Follow @Regina’s advice and attach the original file (reduce it to the problematic page to avoid uploading a big file).
I enclose a purpose odt page with two formulas from scratch:
the top one changed in the icon shows useless brackets in the command window
the bottom has not been changed and the comamnd window is the original.
Thanks for your assistance.
Tale into account that the issue already occurred with past LibreOffice version.
I have just downloaded the last version hoping in the issue solution.
E.Canuto
FormulawithBrackets.odt (31.7 KB)
I see nothing unusual in the XML. From superficial examination, Both XML representations are the same. The only difference is on the <annotation> element which contains the Math user-modifiable script. In the first case, the curly brackets are present in the script while the second has none.
Curly brackets are used to delimit arguments for a function, e.g. bold { … } applies bold to everything inside the brackets.
In your case, most of the brackets are superfluous, if not semantically wrong because some of them have an illogical extent (see the extent for the second opening bracket covering (t), which is the variable for the derivative, and simultaneously = -k, which the operator and only the beginning of the right side.
If I remove the extraneous brackets, save, close and reopen, the modification is persistent. I don’t think there is a Math malfunction. What is the edit history of your formula? Have you copy/pasted it from some intenet source or other alien document?
The brackets are introduced, when you have enabled “Enable visual editing” and then change the formula not in the command window but directly in the preview.
Enable visual editing is not enabled in my configuration. This is why I could not reproduce this issue.
I found this about visual editing by @RGB-es, a very respectable AskLO contributor and book author.
1 Like
Thanks to Regina and ajlittoz.
I followed the advice of @RGB-es, and the issue looks solved, but of course I have to
test in more complex documents with hundreds of formulas.
By the way, I cannot understand why ‘visual editing’ works in this absurd way and why I found it enabled.
Regards
E.Canuto
Because the visual editing was made enabled by default in version 24.2.
And I expect that only now, when it was enabled by default, it will finally (after many years of its existence, hidden under experimental status) get some attention, where users find and file bugs, and developers may fix them.
Thanks for the news.
From my side, now the issue evolution is clearer, as in the past I was fond of LibreOffice Math,
but recently disppointed and annoyed.
ECanuto
Oh glad I’m not the only one! Thought I was doing something wrong. One of those annoying “let us help you because we know better” features.
1 Like
One of these “I claim nonsense as if I know why features are introduced” comments from a user who doesn’t realize that features get introduced because other users demanded that; and indeed, “if I don’t need it, it must be developers’ stupidity, because no one needs it”.
“It has been experimental for as long as LibreOffice existed, lets make
it non-experimental but add an option to disable it. If it turns to be a
disaster, we can flip the option and disable it by default.”
Doesn’t sound like a user-demanded feature from the above, rather more, let’s push the change and see if people complain.
Well, count me in as a complainer at suddenly finding a default I didn’t need, found confusing when it suddenly appeared and caused me no end of frustration when it looked like Math would no longer behave in the way I’d been used to for the last 20 years.
Khaled worked on the huge problems of Math for RTL, which are real problems for real users. That change was required to solve specific problems of real users. Additionally, it was already enabled (by myself) for Collabora Online, because users needed it, and Khaled saw that it is already a default in one product. The commit message doesn’t tell you the full story.
And the original implementation (from a GSoC long ago) was already intended to address demands of real users. It was never polished to become the default (and I made some work to improve it, before the Khaled’s change), but that doesn’t make the feature itself not wanted by users - so you simply chose to skew the story, as if something not needed was enabled, instead of seeing the whole picture.
Let me just quote one link from this site: