Download it now!
Bug 82377 - Shrink to fit cell cuts off cell contents in display/print/export
Summary: Shrink to fit cell cuts off cell contents in display/print/export
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.5.0 target:4.4.2
Keywords: bibisected, regression
: 84012 85914 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-08-09 02:25 UTC by tmacalp
Modified: 2015-12-17 08:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2014-08-09 02:25:18 UTC
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.
Comment 1 crxssi 2014-08-09 17:30:58 UTC
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.
Comment 2 Joel Madero 2014-08-11 17:08:19 UTC
This is not major - this is normal.

Normal - can prevent high quality/professional work
High - regression so bumped up from medium
Comment 3 tmacalp 2014-08-12 04:02:56 UTC
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
Comment 4 Matthew Francis 2015-01-01 11:06:28 UTC
*** Bug 84012 has been marked as a duplicate of this bug. ***
Comment 5 Matthew Francis 2015-01-01 11:09:09 UTC
(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
Comment 6 Matthew Francis 2015-01-01 11:12:15 UTC
*** Bug 85914 has been marked as a duplicate of this bug. ***
Comment 7 Andras Timar 2015-03-05 12:55:53 UTC
It's been fixed, see commits at bug 84012.
Comment 8 Robinson Tryon (qubit) 2015-12-17 08:29:42 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]