I had to create a series of mathematical formulae for a translation in a Writer document (ODT) and then save the document as DOCX to pass on to a client.
When I opened the DOCX document in Word, I was surprised and understandably rather annoyed to discover that the equations were no longer displayed as they appeared in Writer.
I am enclosing a sample of the formulae as entered in Writer and as exported to DOCX along with screenshots.
Steps to Reproduce:
1. Open the Writer document containing the formulae and sample text.
2. Save as DOCX.
3. Open in Word and compare the difference between the Writer document display and the Word document display. Note how the lower limit of the sum symbol has been displaced to right hand side of the sum symbol.
Incorrect display of the equation when exported to docx.
Identical display of the formulae both in Writer and Word.
User Profile Reset: No
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 140796 [details]
Test Writer document with formulae
Created attachment 140797 [details]
Test docx export of Writer document containing formulae
I reproduce too with
LO 184.108.40.206 Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut;
Locale : fr-FR (fr_FR); Calc: CL
There is a better renderer with a .doc format.
Export to Word 97/2000 format with OpenOffice321 shows a correctly displayed formula when opened in a current version of Word.
Given comment 4, this is also a regression
Created attachment 143172 [details]
DOCX exported with 3.5.0 (oldest of 43all repo)
Alex: can you open this in Word? If it shows the problem, bibisectRequest can be changed to preBibisect.
Created attachment 143249 [details]
How testformuladisplay.docx is displayed in LibreOffice 6.2
Created attachment 143250 [details]
How testformuladisplay35.docx is displayed in LibreOffice 6.2
Created attachment 143251 [details]
How testformuladisplay.docx is displayed in Word 2016
Created attachment 143252 [details]
How testformuladisplay35.docx is displayed in Word 2016
um, can you make the same equation if you create it from scratch entirely on Word 2016?
Steps A(for comparison)
a-1. Open Word 2016
a-2. Click Insert tab
a-3. Click Equation in Symbols group
a-4. Click "Large Operator"
a-5. Click the icon with "Summation with Lower limit" tooltip
a-6. Take a look at the equation. entry area for the lower limit is correctly placed under the Σ sign
b-1. Open Word 2016
b-2. Click Insert tab
b-3. Click Equation in Symbols group
b-4. Click "Fraction"
b-5. Click the icon with "Stacked Fraction" tooltip
b-6. Click the numerator entry area in the equation.
b-7. Click "Large Operator"
b-8. Click the icon with "Summation with Lower limit" tooltip
b-9. Take a look at the equation. entry area for the lower limit is NOT placed under the Σ sign but is placed like subscript, and this is consistent with the attached image "How testformuladisplay.docx is displayed in Word 2016"
so, I'm guessing this as NOTABUG
Microsoft introduced new Equation editor in Office 2007 I guess, throwing away legacy MathType ones.
If I load the attached docx, save the file in doc format, and load in Word 2016, the lower limit is placed under the Σ sign, probably because MathType supports such placement.
(In reply to Alex Thurgood from comment #4)
> Export to Word 97/2000 format with OpenOffice321 shows a correctly displayed
> formula when opened in a current version of Word.
I think "Export to Word 97/2000" is different from "Export to docx", and I don't think the mechanism worked in the past version of Libreoffice. so, not a regression.
(In reply to Buovjaga from comment #6)
> Created attachment 143172 [details]
> DOCX exported with 3.5.0 (oldest of 43all repo)
> Alex: can you open this in Word? If it shows the problem, bibisectRequest
> can be changed to preBibisect.
I can open it in Word 2016, but there is no summation symbol displayed at all, so I'm not sure I understand the value of this test document.
Hmm, if I've understood the MS volunteer moderator's response here:
It would seem like this is/was a known problem with Microsoft's fantastic new equation engine.
If that is true, then they have really shot themselves in the foot...the workaround is to place it in a separate cell in a table ? Jeez
Feel free to mark this as notourbug then.
I would add that the exported docx file provided by LO always seems to code the equation as "inline" when surrounded by other text characters on the same line. In theory, it should be possible to use "Professional" from the dropdown display tool in Word 2016 to allow the formula to be displayed correctly, however, this action does nothing with the docx file created by LO.
See this thread for information on how it is supposed to work:
Switching between Inline and Display mode in Word 2016 also changes nothing with regard to the exported formulae. They remain unchanged irrespective of the entry chosen.
Why is LO exporting these formulae as Inline and unmodifiable ? Is there some attribute missing in the exported XML ?
What this does mean, irrespective of where the problem really lies, is that writing mathematical equations of this type in LO and exporting documents containing them to DOCX is a no-go, which IMHO is a pretty big interop issue.
Created attachment 144278 [details]
Created attachment 144279 [details]
>Why is LO exporting these formulae as Inline
>Is there some attribute missing in the exported XML ?
probably because LibreOffice is not outputting m:oMathPara element.
see the attachments "Display" and "Inline". These are the files extracted from docx files from Word 2016
Dear Alex Thurgood,
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible with
Build ID: e04b6f3c0cdacf2a3cdcd3f34bad54c8764ff1ed
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx;
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US