Description: If you change the default font size for the Formula editor, certain mathematical symbols and expressions are not initially affected by the change. Steps to Reproduce: 1. Open Writer 2. On the menu bar, click Insert, Object, Formula... 3. On the Formula Editor menu bar, click Format, Font Size... 4. Change the font base size to a non-default value (not 12). Setting it to a very large value, such as 80, demonstrates this bug more clearly. 5. Click the "default" button and click "yes". 6. Click "Ok" 7. Exit Writer, do not save the document. 8. Open Writer again 9. On the menu bar, click Insert, Object, Formula... 10. Type "sum a" without the quotes. If you had set the font base size to a relatively large value, you should clearly see that the summation symbol is much smaller than it should be. It appears to be the original default size of 12. The "a" character is the correct size, though. 11. Click on the white page in the Formula editor to exit back into Writer. 12. Save the document as an .odt file. 13. Exit Writer. 14. Open Writer again and open the saved document. 15. Double click on the "sum a" Formula object, thereby entering into the Formula editor. 16. Observe that the size of the summation symbol has been automatically corrected. Try repeating the above steps, but instead of typing "sum a" in step 10, type in the following: left[ matrix{ a#b ## c#d } right] The vertical size of the matrix appears to be correct, but the horizontal size is wrong. The matrix is too narrow. If you go all the way through to step 16, you will see that the matrix's size will widen to the correct amount. Actual Results: Expected Results: Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 2; OS: Windows 10.0; UI render: GL; Locale: en-US (en_US); Calc: group threaded
Thank you for reporting the bug.I cannot reproduce both the bugs. As you said in step 10, the summation symbol is in the correct size of default value 80. The size of the matrix also is displayed correctly on the first time only even before saving the file and opening it again.
Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL Version: 6.3.0.0.alpha0+ (x64) Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10 Locale: en-US (en_US); UI-Language: en-US Calc: CL
I can't reproduce this issue in Versión: 6.2.2.2 Id. de compilación: 2b840030fec2aae0fd2658d8d4f9548af4e3518d Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded nor in Version: 6.3.0.0.alpha0+ Build ID: f8ca6e0a59bff51fcb09af4fa6d9cd458b32f223 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Does it work if you disable OpenGl ? -> https://wiki.documentfoundation.org/OpenGL I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
No repro Version: 6.3.0.0.alpha0+ (x64) Build ID: 218916eb47e35fd14832d8f52225bf1d4d9c80a6 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-17_04:56:25 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 66b21521a95f7b2053aa99a23e0a4c34438af6c7 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 22 March 2019
(In reply to Xisco Faulí from comment #5) > Does it work if you disable OpenGl ? -> > https://wiki.documentfoundation.org/OpenGL > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present The bug still occurs when OpenGL is disabled.
I'm also getting the bug in the portable version of LibreOffice. Version: 6.1.4.2
Do you see the same in a master build? https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
(In reply to Buovjaga from comment #9) > Do you see the same in a master build? > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/ I installed the April 7th master build today, and the bug is occurring in it. Version: 6.3.0.0.alpha0+ (x64) Build ID: 421e6fc3cd2e6fe37afbef341e2d0ad7b8edde37 CPU threads: 2; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-07_01:12:58 Locale: en-US (en_US); UI-Language: en-US Calc: threaded When you tried to reproduce the bug, did you close and then re-open Writer after changing the default font size (steps 7 and 8)? The reason I ask is because when I don't perform those steps, and I type "sum a" right after I change the default font size, the fonts are the correct size. The bug only appears after I restart Writer.
(In reply to k-riley from comment #10) > When you tried to reproduce the bug, did you close and then re-open Writer > after changing the default font size (steps 7 and 8)? The reason I ask is > because when I don't perform those steps, and I type "sum a" right after I > change the default font size, the fonts are the correct size. The bug only > appears after I restart Writer. Yes, I closed it.
Created attachment 153327 [details] Impress file to show the two differen appearances of the formula I have also hit this bug of the formula editor in Impress (LibreOffice 6.3.0.4). I will attach a slide that shows my two formulas, one generated only with the changed default font size, the other corrected afterwards by changing the formula font size twice.
(In reply to hardy from comment #12) > Created attachment 153327 [details] > Impress file to show the two differen appearances of the formula > > I have also hit this bug of the formula editor in Impress (LibreOffice > 6.3.0.4). I will attach a slide that shows my two formulas, one generated > only with the changed default font size, the other corrected afterwards by > changing the formula font size twice. Ok, let's set to NEW. Are you using Windows or Linux or macOS?
My observations in comment #12 were done under (Ubuntu) Linux.
Dear k-riley, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
As proposed in the mass ping (last comment) I have re-tested this bug. Result: This bug is STILL PRESENT. Following the steps from the very first comment of this bug report, this bug can still be easily reproduced. I used the following LO version to check this: (7.1.5.2 under Linux) Version: 7.1.5.2 / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
Dear k-riley, 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
Once again, and as proposed in the mass ping (last comment) I have re-tested this bug. Result: This bug is STILL PRESENT. Following the steps from the very first comment of this bug report, this bug can still be easily reproduced. I used the following LO version to check this: 24.8.2.1 under Linux detailed version information: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 16; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded