Created attachment 144253 [details] Equation where the constant vanishes The constant below the divisor vanishes in Writer. See the attachment sample.
This is how Writer open it in 6.1.1. See the screenshot. Version: 6.1.1.0.0+ Build ID: 5a56b72413d5f555c854e36d3bd2fd50ec21644c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-08-15_02:45:13 Locale: ro-RO (ro_RO.UTF-8); Calc: group threaded
Created attachment 144258 [details] formula in 6.1.1
It's ok like this, or should be even different?
Ahhhh.. 6.1.1 seems to fix the bug! Thank you!
So let's put this one to WFM then.
Hello! While discussing this issue on IRC we noticed that the equations in Word 365 use the font "Cambria Math", while LO converts them to "Liberation Serif". In LO 6.2 alpha 0, I double-clicked in the equation and in the editor changed the font to the original and the "e" appeared. Can LO be improved to try to keep the original font in .docx equations? Thank you!
Note that the "ⅇ" in attachment 144253 [details] is not a simple ASCII "e", but a "DOUBLE-STRUCK ITALIC SMALL E" (U+2147). Can't reproduce this problem in: Versie: 6.2.0.0.alpha0+ Build ID: c658fd4609c05617c785870b00aa3a0998375cc6 CPU-threads: 4; Besturingssysteem: Linux 4.12; UI-render: standaard; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: threaded or Version: 6.0.4.2 Build ID: 00m0(Build:2) CPU threads: 4; OS: Linux 4.12; UI render: default; VCL: kde4; Locale: en-GB (en_GB.UTF-8); Calc: group My test system doesn't have Cambria Math installed, so I presume LO is forced to substitute it with Liberation Sans. Still the ⅇ in attachment 144253 [details] is rendered OK.
It is a mathematical letter: https://en.wikipedia.org/wiki/E_(mathematical_constant) "Euler's number" I hope this helps.
"e" is shown fine for me in LO 6.1.0.3 & 6.2 daily build (2018-08-17_00:41:06, 380d0fda99ff664de8443cfc33c7c86bca18134c) / Windows7, both with and without OpenGL. Note that I tested this on a computer where Office is also installed.
Though I know even Word 2016 itself insists in its context menu that the 'e' character is U+2147 ,the displayed 'e' does not look "Double-Struck"
This bug was changed to WORKSFORME based on multiple conformations that original issue is not present. Even though we didn't have conformation that it was really wrong. Marco, please don't change status asking than for something else. Especially if you're not familiar with statuses because REOPENED is for fix not working and that cannot be case here. As for equation font, I can see it's "Cambria Math" in MSO, while I don't see that LO converts them to "Liberation Serif". Please explain or attach screenshot how you saw it.
Created attachment 144409 [details] Screenshot LO 6.2 alpha 0 VS Word 365 Here are the screenshots!
What you show is Formula-Fonts. But I guess it's setting, not reading. Look that you see real font "Times New Roman" same as other text. Not sure if it's correct. See also Bug 116749. Not so simple.
(In reply to Timur from comment #13) > What you show is Formula-Fonts. But I guess it's setting, not reading. > Look that you see real font "Times New Roman" same as other text. Not sure > if it's correct. > See also Bug 116749. Not so simple. @Timur: If you place the edit cursor inside the formula in Word 365 it will show "Cambria Math" (see the screenshot: I placed a red square on the places). I am writing my thesis with Times New Roman, but every time I insert an equation, Word uses "Cambria Math" in them.
I understand. Looks like it's Bug 116749.
Marco wrote the bug is still there with a daily build from yesterday, even with safe mode. Returning status to UNCONFIRMED.
I don't know if this helps, but after a double-click in the equation, we get to the editor and I just copied the "e" from there in the formula, then pressed <ESC> and pasted the clipboard in the document body and the "e" appears in the document, but not inside the equation. Maybe this can narrow the issue to the equation itself.
Created attachment 145239 [details] Euler's number doesn't appear on equation (another example)
Here is another example (see screenshot) If we have the "e" as plaintext, it appears. If we have the "e" in an equation, we get a blank character.
(In reply to Marco A.G.Pinto from comment #18) > Created attachment 145239 [details] > Euler's number doesn't appear on equation (another example) I confirm with this and the original document on Windows from master down to version 5.4.2. Version 5.3.0 does not show the problem. *None* of the bibisect repos show the problem, which is puzzling! Not seen on Linux.
Created attachment 155257 [details] First DOCX compared in MSO and LO I don't see an issue.
Created attachment 155258 [details] Second DOCX compared in MSO and LO Also on 2nd DOCX I don't see an issue with Euler. Please explain what this bug is about. Note: image is blurred, that another bug.
With my two examples above I still get a blank "e" with LO 6.3.2. Have you tested the files with Windows 10 1903?
Marco, please make a screenshot where issue can be seen, do not edit and cover formula like attachment 144409 [details]. Please see if you can test on some other system. This is not a simple bug, always reproducible. I showed that's not on my Win7 or Linux. No point in bug staying open for the sake of bug, unless we know exactly when it happens.
Created attachment 155262 [details] Word 365 Word 365
Created attachment 155263 [details] LO 6.3.2
Here are the screenshots, both on Word 365 and on LO 6.3.2.
(In reply to Marco A.G.Pinto from comment #26) > Created attachment 155263 [details] > LO 6.3.2 I get the same result Version: 6.4.0.0.alpha1+ (x64) Build ID: 7c6226bee72805db7f0e567ca9f06c786a7d0da2 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
It should be clear when this happens, what are the prerequisites. So far it seems Windows 10 only, so I updated the title. But it may not be correct, could be some font issue, please try to find out, I don't repro in Windows 7.
Marco, please retest, Buovjaga please do bibisect or remove keyword.
Still confirmed Version: 7.1.0.0.alpha0+ (x64) Build ID: df74aef7159d7155addf78cfc4d139485945d794 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
Dear Marco A.G.Pinto, 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
Change after commit 7dd44125a9c184c21374a47005e303579179805f. Related to font handling (and the regression must be a font substitution issue). However, the real problem is indeed not importing Cambria Math font from the equation, which is why the substitution would happen in the first place. It is not a regression, but a missing functionality - similar to other attributes not read from DOCX formulas - bug 129849.
*** Bug 98886 has been marked as a duplicate of this bug. ***