maybe this is something like #64905 but it is not closed yet. fill two cells. first one "10", second one "10 20 10", where the numbers are the size of the text and the text itself does not matter. press CTRL + A and enter a new font size, e.g. 8 the cells will be like "8" and "8 20 8"
I can reproduce with Version: 5.0.0.0.alpha0+ Build ID: 89f5c1516fd3cf96488d97f62065b1ae0bdb9efa TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-18_10:10:39 LibreOffice 3.5.0 Build ID: d6cde02
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
This bug is still present in the latest version. (Windows tested)
*** Bug 108041 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #4) > *** Bug 108041 has been marked as a duplicate of this bug. *** 2015? How can you leave such an embarrassing bug in force for so long. It simply can't be that hard to fix something this basic. Did you see my comment with the error log from Excel? When Excel opens a file created in this way it detects and repairs errors. Why can't Calc do this? It's an absolute disgrace.
(In reply to Buovjaga from comment #4) > *** Bug 108041 has been marked as a duplicate of this bug. *** The "even simpler" version of 108041 is now fixed in 5.3.4. The main 108041 bug is still active.
Created attachment 138394 [details] File to reproduce I have attached a small ODS file which could be used to reproduce this issue. The file contains two cells with content. B1 contains three lines, with the second lined formatted with font size 20. Now select all cells (Ctrl+A) and choose e.g. size 8. You will see that everything is changed to the new font size except for the line that has font size 20. I'm not sure if this is the desired behavior or a bug. Maybe this is related to #99920 ?
** Please read this message in its entirety before responding ** 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! Warm Regards, QA Team MassPing-UntouchedBug
Version: 6.1.2.1 Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU-Threads: 8; BS: Windows 6.1; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL If only one cell is selected, the cell with different font sizes, the size of all the text is changed correctly. If more than one cell is selected, the behaviour is still wrong; the text size is not changed for all text in the mixed cell. => stil open
Dear Alex, 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
Works as expected in version Version: 6.4.6.2 (x64)
Yes, I can confirm, too, that this bug is fixed :-) Tested with LibreOffice 6.4.7.2 with Debian Linux. Thanks to the developer!
Following the OP steps, I only see it fixed in 7.5 as a side-effect of commit ac859a4c6a7fce4efee9cdd45821a0c9e40e9e9a, which reduces the Ctrl + A selection to only cells with data. It made me realise that results depend on the selection. Up to LO 7.4, with attachment 138394 [details]: - Ctrl + A: bug - Row 1: works - Columns A:B (or even just column B): bug - Cell range A1:B1: works ... which might be relevant to other bugs in meta bug 108662. This is unrelated to the number of cells selected, because there is no bug when the change is applied to selected rows 1:200 (more than 3 million cells) whereas the bug is present when the change is applied to column B (just above 1 million cells). Described behaviour same in OOo 3.3, so inherited.