Bug 99304 - Multi-line text in cell causes row to collapse slightly, cutting off text
Summary: Multi-line text in cell causes row to collapse slightly, cutting off text
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Cells
  Show dependency tree / graph
 
Reported: 2016-04-14 17:46 UTC by Jim Avera
Modified: 2020-07-01 17:44 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
test1.ods (11.43 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-04-14 17:46 UTC, Jim Avera 		Details
Screen-shot showing the problem (20.23 KB, image/png)
2016-04-14 17:49 UTC, Jim Avera 		Details
Video showing steps to reproduce (.ogv) (1.80 MB, video/ogg)
2016-04-19 20:13 UTC, Jim Avera 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2016-04-14 17:46:16 UTC 
Created attachment 124343 [details]
test1.ods

If a cell contains multiple lines of tex and any edit is performed, the row height shrinks slightly.  This causes the text to be rendered closer to the upper border, and in some cases the text is truncated by the border.

My guess: A rounding bug somehwere, or the row-height is being recomputed 
 using separate/duplicate code different from what is used by the 
 "set optimal height" operation.

The row-height change is permanent (it is not just a rendering issue).  The result is that after any edit it is again necessary to do the "set optimal
height" operation to fix the row.

STEPS TO REPRODUCE:

1.  Load attached "test1.ods"  
     -OR-
        Type 10-point text into a cell, control-ENTER for embedded return, 
        and more text.   Then select the row, then Foimat->Row->Optimal Height,
        set "Add" to zero, click OK

2.  Set magnification to 80% (makes the problem more visible, at least for me)

3.  Click in the cell with the multi-line text.  Replace some characters
    with the same characters, i.e., do an edit with no net change.

4.  Click in some other cell

RESULTS:
  The row collapses slightly.  The text is rendered closer to the upper border,
  possibly touching it or being partially clipped.

EXPECTED RESULTS:
  Row height should not change due to a no-op edit
Comment 1 Jim Avera 2016-04-14 17:49:24 UTC 
Created attachment 124344 [details]
Screen-shot showing the problem
Comment 2 Jim Avera 2016-04-14 18:59:21 UTC 
I checked older builds, and the bug seems to appear with 4.1.x
(it is not in 3.6.7.2)
Comment 3 sstory 2016-04-19 16:22:34 UTC 
I attempted to reproduce these steps oo a Mac Yosemite, with version 5.0.1.2 and also on Ubuntu 14.04LTS, with Libre 4.2.8.2 and after setting row height to optimal and editing a letter or two, pressing enter, I saw no real change as reported.  I guess more information is needed.
Comment 4 Jim Avera 2016-04-19 20:12:54 UTC 
I'm attaching a video showing the exact steps I used to see the problem.

sstory - would you mind looking at the video to see if you and I are doing the same thing?   Thanks.

Jim
Comment 5 Jim Avera 2016-04-19 20:13:45 UTC 
Created attachment 124517 [details]
Video showing steps to reproduce (.ogv)
Comment 6 sstory 2016-04-20 13:14:16 UTC 
OK. I retested it, per the video on the same system as mentioned previously--with the test spreadsheet. I zoomed in to a larger value to notice it better.  I was able to reproduce the issue.  The row heights of both in the demo spreadsheet were 0.36". After following the same procedure as shown in the video, row 4 height changed to 0.33"

Doing an "Optimal Height" on either row changes it to 0.34"
Comment 7 QA Administrators 2017-05-22 13:26:48 UTC Comment hidden (obsolete)
Comment 8 Jim Avera 2017-05-22 21:07:36 UTC 
Bug is still present in master of May 22, 2017 on Linux 64-bit.

Version: 5.5.0.0.alpha0+
Build ID: 514fd7073cbed62a01c8cecfd72cd65e810d679d
Comment 9 Jim Avera 2017-05-22 21:09:17 UTC 
Note: The magnification control has changed since older releases.  

Now use View->Zoomn->150% before editing row 4 in the demo spreadsheet.  This makes the problem very visible.
Comment 10 QA Administrators 2018-06-30 02:40:46 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2020-06-30 03:41:43 UTC Comment hidden (obsolete)
Comment 12 Jim Avera 2020-07-01 17:44:22 UTC 
The problem seems to have gone away in 7.1.0.0.alpha0+ (master)