Description: There are several cases when some strings that are Math operators are used as single chain strains or even variable emphasis. Some examples are: 1) "bar" = common unit of measure for pressures, is also a command for overline variables 2) "cicle", "square", may be single words inside an equation. 3) "+", "*" and other operators are used for emphasis, like, for instance, a reference value. In the attached DOCX file, there are several examples of that are not well imported. Steps to Reproduce: 1. Open attached file 2. 3. Actual Results: Equations 2 to 3 have been lost. If the file is saved by LO, and then opened and saved by MS Word, there will be data loss. Expected Results: All equations are correctly imported. Reproducible: Always User Profile Reset: No Additional Info: I don't know how "circle" and "bar" emphasis are handled within MSO, but I think that "bar", "circle", and other strings that matches Math operators should be imported as quoted text. On the other hand, "+" and "*" should have been imported also as quotated text, although I'm not sure on how to solve this case. Maybe, when Math detects an error when importing from Word, it should import all as quoted text?
Created attachment 177512 [details] example file with broken text Look at equations 2 to 4: all of them are wrong or simple broken
Created attachment 177513 [details] Side by side comparison Comparison with LO 7.2.5.2. The import from older versions may be a little different for Eq. 4, but wrong anyway.
Hi Francisco, this is a real problem while importing formulas from MS Office files. For example, the circle area formula was imported as: circle area = π {r} ^ {2} But it should have been imported as: italic "circle area" = π {r} ^ {2} So whenever a formula from MS Office contains a reserved word for Math, it should be imported as italic quoted strings. I am setting this to NEW.
Thank you, Rafael. Just one comment (In reply to Rafael Lima from comment #3) > > But it should have been imported as: > > italic "circle area" = π {r} ^ {2} > It should be imported as "cicle area" without italics; look at the original DOCX file. But this is actually a different bug, bug 146726.
(In reply to Francisco from comment #4) > It should be imported as > > "cicle area" > > without italics; look at the original DOCX file. But this is actually a > different bug, bug 146726. Thanks for the pointer... indeed this should not be italic.
@Dante you worked with the MathML parser some time ago. Do you have any good code pointer for this one?
(In reply to Rafael Lima from comment #6) > @Dante you worked with the MathML parser some time ago. Do you have any good > code pointer for this one? I can't help you much with this. I lack knowledge about how the information is encoded on MS Word. About mathml, if you wanted to insert some stuff such as operator which are decorative you would add them as <mtext>=</mtext> which on LO should be "=". The bug 1: Formula: {v} ^ {+} =C {left ({y} over {R} right )} ^ {α} Should be: {v} ^ {{}+{}} =C {left ({y} over {R} right )} ^ {α} | | As you can the operators have not been escaped. This is a feature of LO I dislike because forces me to write much useless code. The bug 2: Formula: ln {{p} ^ {vap} left[ bar right] =A- {B} over {t left [°C right ] +C}} Should be: ln {{p} ^ {vap} left[ "bar" right] =A- {B} over {t left [°C right ] +C}} | | As you can see a keyword has been treated as a variable name. This one is more tricky because it would be necessary add a command of the style mi "variable name" if you want to ensure the safety of variable name text. The bug 3: Formula: circle area = π {r} ^ {2} Should be: "circle area" = π {r} ^ {2} | | As you can see here we have double bug. First text information has been treated as variable names. Secondly we have fallen victims to bug 2. I hope this information has been useful to you. https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtext https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mi
Dear Francisco, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug