Description: Shrink to fit cell size now concatenates cell contents that normally would have overflowed partially into the next cell. For some reason, this bug is only visible on screen when the cell contents begin with a number, but it seems to always cause errors with print/pdf export/preview. Steps to reproduce: 1. Open a blank calc sheet. (with the stock template) 2. Enter “1this should overflow” into any cell. The text should overflow partially into the next blank cell. 3. Enable “Shrink to fit cell” on cell containing the text. Expected: Even though the contents “1this should overflow” previously partially overflowed into the adjacent cell to the right, the entire string should now be shrunk to fit inside the cell. Actual: The contents are shrunk, but the string stops being displayed right at the line where it normally would overflow into the adjacent cell. This turns “1this should overflow” into a shrunken “1this sho”, with blank space filling the rest of the cell. Notes: Oddly enough, if you copy and paste “1this should overflow” into the cell instead of typing it, this bug doesn't trigger. Also, if you enter enough text to overflow too much(over 85% of the adjacent cell), the bug doesn't trigger. This bug showed up somewhere between LO 4.2.4.1 and LO 4.2.5.2, but I can bibisect if needed. I tested and can confirm this bug with the following environments: LO 4.2.6.2 running on 64bit RHEL6 LO 4.2.6.2 running on 32bit Fedora17 LO 4.3.0.4 running on 32bit Fedora17 LO 4.2.5.2 running on 32bit Fedora17 I tested and did NOT see the bug in the following environments: LO 4.2.4.1 running on 32bit Fedora17 LO 4.1.4 running on 64bit RHEL6 OpenOffice 3.2.1 running on 64bit RHEL6 Based on the bug prioritization flowchart, I'd say this regression would at least rank a Major-High priority.
Confirmed in LO 4.2.6 under RHEL 6 and in LO 4.2.5.2 under Fedora 20 (NOT present in LO 4.0.6.2 under Mageia 3. Changed status to NEW/Confirmed Nasty bug. This is a regression (and just marked it as such). Agree with Importance of medium/major. Not only does it screw up display, but also printing and export. Impossible to produce quality/professional work and corrupts outputs.
This is not major - this is normal. Normal - can prevent high quality/professional work High - regression so bumped up from medium
0acca754077bf74469c3e1a3c7eabbc3da795266 is the first bad commit commit 0acca754077bf74469c3e1a3c7eabbc3da795266 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon May 12 12:04:53 2014 +0000 source-hash-5e651d4084df7662b56ea980934c0428ba31b062 commit 5e651d4084df7662b56ea980934c0428ba31b062 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Tue Apr 15 21:08:13 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Apr 16 11:23:13 2014 +0100 coverity#1202948 Uninitialized pointer field Change-Id: I2764b1f9c3d50cf7ff7bd2c552a3dec93509b245 :100644 100644 42123dfbed90154f94f2f1dc8eacf21ed9bf155e 0d2db29f9ae8626eca4aa470157737cc2fffcde0 M autogen.log :100644 100644 0c1402c4f181927b2de7b580b596a19c454ff44b 76dfad2a19c6025ab1ff32510e73930f97ae063f M ccache.log :100644 100644 3c2e4c5380217c309eb8ca87b2e009760a2e4e9c c60fabab11f976674ac5611f37cba9ef49405589 M commitmsg :100644 100644 3b4121c32f82a582e7375c90656c26d59b1d9e61 645384f6ca01eb832351e51b21a3e68e798177f0 M make.log :040000 040000 e411e8188872ccf6a50816da7de0ce184071ca16 c66ac4ae3cd31ba3fa723f1ef8376310723747ec M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4 git bisect start 'last43onmaster' 'last42onmaster' # good: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e git bisect good 4fcd68ce4979f85fda4568f4b419a4b41d07345f # skip: [422186458e0b4db00c7e26b54d5b631f83bcad2a] source-hash-6948bf58ce181b17f60ef81f10205ef4dac50cc6 git bisect skip 422186458e0b4db00c7e26b54d5b631f83bcad2a # good: [a0b33bffff9c787dce71a13b344f06ae1453026b] source-hash-02e0be069e57e724c51f23e2e31b77657a6a1d3d git bisect good a0b33bffff9c787dce71a13b344f06ae1453026b # bad: [16d0a5059bce9198bfae647a72dc06b438be583f] source-hash-944c78ecb91608f4c3e9bab32fdbc90c67326525 git bisect bad 16d0a5059bce9198bfae647a72dc06b438be583f # bad: [5e7af1ea4d6ff32d05a2eb182f0b548700601784] source-hash-213571db0e69db5d8d16d16e8a5c428b824e80d1 git bisect bad 5e7af1ea4d6ff32d05a2eb182f0b548700601784 # good: [7e673c13a5ce2578df74ab1491b1ab3389e9d4cc] source-hash-cddf4bd65fb4ce5615ca770946707d0db657e8ec git bisect good 7e673c13a5ce2578df74ab1491b1ab3389e9d4cc # good: [56c2c5322acece36622b6cd89d5ee1a679a92a10] source-hash-1393ba60b1eb43b55820f74c393da04308221d97 git bisect good 56c2c5322acece36622b6cd89d5ee1a679a92a10 # bad: [0acca754077bf74469c3e1a3c7eabbc3da795266] source-hash-5e651d4084df7662b56ea980934c0428ba31b062 git bisect bad 0acca754077bf74469c3e1a3c7eabbc3da795266 # good: [465e2be02951f9645beb3024506a5212907caf5f] source-hash-674801eb4af21c9ae83c122499f15fa4f4785b0f git bisect good 465e2be02951f9645beb3024506a5212907caf5f # first bad commit: [0acca754077bf74469c3e1a3c7eabbc3da795266] source-hash-5e651d4084df7662b56ea980934c0428ba31b062
*** Bug 84012 has been marked as a duplicate of this bug. ***
(Copying relevant discussion from duplicate bug 84012. See also attachment 106455 [details] and attachment 106454 [details] from that bug) Couldn't source bisect this because builds in the bibisect range are mysteriously non-functional However, from reading the commit messages, the below looks like an extremely likely suspect: commit 087a79db1272858f107656c5ca3c6efb45680986 Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Tue Apr 15 20:47:37 2014 -0400 fdo#75665: Truncate string when clipped on screen. This improves performance of text layouting by HarfBuzz for very long strings. HarfBuzz's layout algorithm appears to be more expensive than ICU's. Change-Id: Ic9738b7b8f0f1a29c51c83b147763118939b90ef
*** Bug 85914 has been marked as a duplicate of this bug. ***
It's been fixed, see commits at bug 84012.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
*** This bug has been marked as a duplicate of bug 84012 ***