Description: When I enter a formula in the "old"?? way and touch it later, suddenly LO changes the format to a Tex like?? format, what I find less user friendly (as I am used to the old format). I would expect the system not to touch my input. (of course if there is a way to convert between formats that is always good, but it should not be automatic) Steps to Reproduce: In LO Writer start a new formula (Shift-Alt-E) - Already a small change from the past - earlier an empty formula box had zero length, now it is a third of the line) Enter: c sub {H sup "+"} = K sub W over c sub {OH sup "-"} and exit the box. The formula is nicely rendered and if you open it again (double click on it), it is still the same input. Change it in the bottom section of the screen (i.e. the input area) and it is still OK. Double click again on the formula, but this time make the change in the rendered formula (e.g. selecting and changing W to w). The formula in the bottom section changes to { c _ H ^ "+" = { K _ w over c _ OH ^ "-" } } Actual Results: The formula is changing its language to { c _ H ^ "+" = { K _ w over c _ OH ^ "-" } } Expected Results: Not to change it but keep c sub {H sup "+"} = K sub w over c sub {OH sup "-"} Reproducible: Always User Profile Reset: No Additional Info: N/A
It seems the problem is even larger. I have now a formula already changed by LO from {%delta c sub {OH sup "-"}} over {%delta t} to { %delta c _ {OH ^ "-" }} over { %delta c } This you can enter into the formula editor and it still renders normally, i.e. the minus sign is above the OH in the sub index of c. You can also copy the text version from the editor section to a new formula and it is still OK. However, if you copy the formula from the rendered text (while the formula editor still must be open!), and paste it either into the editor at the bottom or directly into the rendered formula it turns bad, into { { %delta c _ OH ^ "-" } over { %delta c } }, i.e. it rearranges the curly brackets as well, making the formula useless as the - sign is now in the superscript of c and not of OH. To me it is a major bug, as for really large formulas it is standard to copy parts to the next line, and if the formula editor randomly changes the brackets it a serious issue as errors might get into the equations if left unnoticed. I would suggest to even increase the priority of this problem, if possible.
Yeah this happens in visual editing (which is when you try to change the formula directly). It actually does not change the "language" but rather regenerates the formula "code" from the edited object. I'm pretty sure it has always been this way, but I don't have older versions here to test.
Current releases have Visual Editing enabled by default. From Formula editor session: Tools -> Options -> LO Math uncheck the 'Enable visual editing' box and apply. That will put you back in the legacy mode via the Command Window.
I am actually happy to have visual editing enabled. Honestly I hadn't known that this feature existed so making "enabled" default is actually a good thing. Still that is a problem (to me a bug) if LO unilaterally changes the syntax in the code of the object (not only the sub to _ and the sup to ^, but also the number of brackets and the spaces and line breaks in between) even if the generated formula is the same, but I can imagine it can be argued to be a feature rather than a bug. I often write very complex formulas formatted in the editor window with line breaks and indentation. Once touching it, it becomes something totally unreadable. E.g. "a <CRLF> b <CRLF> c" turns into "{ a b c }" when touched (the line breaks are gone, brackets and spaces appeared). It is also a problem (again arguable) that if I remember well when using the right mouse button Formats point in previous versions then superscript and supscript were generated as "sub", and "sup" (this is where I learned it from). Now even the pop-up menu is changed to ^ and _ and I do not see why. However the error that I mentioned in my Comment #1 (i.e. that the formula changes to something meaningless) is definitely a bug and in my view a rather serious one. If touching a formula in the visual editor changes the formula into something else, that makes the use of it extremely dangerous. It is a question of taste, it is a bug. So, please do not make it "RESOLVED NOTABUG".
When in the now default sm Visual edit mode dev decided to add the additional bracketing to resolve bug 130741 [1] Some talk of reverting default use of the Visual edit mode as there are many facets of the editor that now need attention that no dev has cycles to tackle. Meanwhile this is NAB as it works (sort of) as intended, i.e. to no longer edit the sm formula in the command window--so the additional bracketing of the sm syntax is considered benign. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/156640
(In reply to jollytall from comment #4) > Still that is a problem (to me a bug) if LO unilaterally changes the syntax > in the code of the object (not only the sub to _ and the sup to ^, but also > the number of brackets and the spaces and line breaks in between) even if > the generated formula is the same, but I can imagine it can be argued to be > a feature rather than a bug. Math works in either of 2 ways: 1) You write the formula code and it is rendered in the window or 2) You edit the formula directly in the window in a more visual manner, and then it gets converted into code When you do (2), it is natural that your code will change. I don't even see how we could implement it in a way where all spaces, line breaks and different choice for commands are kept. Although it could be technically possible, it would be a huge development effort with very small benefit. And also, NAB means that there's nothing breaking here, so I guess this is the right choice for this ticket.
Sorry, but I still disagree. I tried to do, as suggested above, i.e. to use only one mode or the other. If I use only the command window then it works, but using only the rendered window, I could not make even after an hour of trying the simple formula of the concentration of hydrogen ion. I tried the following keyboard sequences in the editor window: c_H^+ but then the ? remains there indicating that after the + sign it would need something. c_H^"+" but then the " marks remain there various combinations with {, but then it is immediately understood as a visual lbrace, rbrace. So, unless there is another trick to make it happen, my conclusion is that it is not possible to do what you suggest, i.e. either use the rendered window or the command editor but never mix them. The only way, how I could remove the ? after the + sign was to go to the command window and add an extra space at the end of the line, what also can be removed immediately. Then the ? goes away, although the command seems to be the same after adding and removing the space. Then, I tried to extend my formula (again strictly in the rendered window!) to the difference of the hydrogen and hydroxide ion. So, I went to the end of the formula and typed: -c_OH^- Again the question-mark was there after the - sign (not after the + sign, that is gone by now). So, just like above, I have to go to the command window, and add a space at the end. Then the disaster happens. Although the command does not change (other than the extra space typed) and the ? disappears after the - sign, also the so-far correct first part of the rendered formula changes; the + sign of the H superscript jumps to the superscript of c. That is wrong. To make it even worse undo (Ctrl-Z and alike) do not make it back. I think this is definitely an error. A bit of fun fact. So, I try to fix the H+ in the rendered window (as suggested not touching the command window when possible). Deleted the + sign from the superscript of c and went to H and typed ^+ adding back the + sign to where it should be. Then again the ? appeared, so I had to go to the command window and add an extra space to remove the question mark. That goes and now the - sign of the OH jumps. And so on. So, there is a bug from a user point of view. If you can make the above only using the rendered window, please let me know, although even then I would think that it is wrong if the two windows cannot be used mixed. As the original bug report was about the change of the syntax, you might want to have a separate bug reported for the above, but I think it is all interlinked.
(In reply to jollytall from comment #7) Entering chemical formulas in StarMath syntax via the command window have always been a kludge: https://help.libreoffice.org/latest/is/text/smath/01/chemical.html Hints there for using the command window; while documentation of working with the Visual mode editor is lacking. Though I do reproduce your observations working with keyboard entry of exponential notations with Visual edit mode enabled. Return to status quo of disabling Visual mode editor is your best option with these formulas and your work flow.