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.
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!
So let's put this one to WFM then.
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?
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:
Build ID: c658fd4609c05617c785870b00aa3a0998375cc6
CPU-threads: 4; Besturingssysteem: Linux 4.12; UI-render: standaard; VCL: gtk3;
Locale: en-GB (en_GB.UTF-8); Calc: threaded
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:
I hope this helps.
"e" is shown fine for me in LO 188.8.131.52 & 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.
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]
Created attachment 155263 [details]
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: 184.108.40.206.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
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.
Version: 220.127.116.11.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