Description: I am working on a docx file in Libreoffice Writer 6.1.2.1, and I have a formula that contains a vertical line such as x | y. My source code in the formula editor is "x divides y". However, when I save the document and re-open it, the formula appears as x v y, and the source code has changed to "x | y". Steps to Reproduce: 1. open Libreoffice writer 2. insert a formula (Insert -> Object -> Formula..) 3. Write in source code window: " x divides y" 4. Save document as .docx 5. close and re-open document Actual Results: The formula appears as "x v y" Expected Results: The formula should appear as "x | y" Reproducible: Always User Profile Reset: No Additional Info:
@sebastian: Is there a special reason for using docx format? Word uses OMML language for formulas in docx format, LibreOffice uses its proprietary "starmath" and common MathML in its odt format and works with an internal representation. Conversion errors are inevitable because the capabilities of the languages are different. You should discuss workarounds for conversion problems in a forum or mailing list. Nevertheless this is an error. The "divides" operator is correctly converted to U+2223 on export, but on import (not touched by Word) it is not converted back to operator "divides". As far as I have seen, MS Office seems to use a list derived from Unicode for to determine an "operator". Unfortunately the "divide" operator does not exist in the UI of the formula editor of MS Office. In case MS Office opens an odt document with e.g. "m divides k", the formula is transformed into MS Office own format, but when saving it back as docx, the "divides" is converted to U+007c, that is | the pipe character. Same happens with an docx document made by LibreOffice. OMML has a tag opEmu, which could be used here to mark the "divides" character as operator. But I do not know whether that would give better results if it goes through Word. But at least it would make the markup unambiguous for LibreOffice.
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.10; Render: default; Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
*** Bug 133217 has been marked as a duplicate of this bug. ***
*** Bug 123688 has been marked as a duplicate of this bug. ***
Dear sebastian.wolf.dk, 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
Still presents in LO 7.6 alpha under Windows 10(x64). Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-IN (en_IN); UI: en-US Calc: threaded
In Calc, if one types “x|y” (U+007C "Vertical line"), the vertical line is interpreted and displayed as "Boolean OR". If one types “x∣y” (U+2223 "Divides"), it's interpreted and displayed as…well, something, but I'm not quite sure what. It's a forward slash of some variety, but not setquotient or "Division (Slash)". In the formula the character remains U+2223, and this is what comes from Word, but I can't understand what LO Calc's trying to do here.
(In reply to bugmail from comment #7) > In Calc, if one types “x|y” (U+007C "Vertical line"), the vertical line is ------^ Please write a new bug report. This report is about writing Math-objects in Writer, when the document has docx format and about its exchange with MS Word. Please discuss the problem in the Ask forum beforehand to be sure, that it is really a bug.