When declaring a cell as line-breaking, and the contained text is displayed in two lines, the height is (depending on the width of the respective column) lost after saving the file, closing it and re-opening it. After reopeing a file in such a case, the row's height is set to the default height, and the text (which is still line-breaking) is clipped.
Steps to Reproduce:
- Using the binary LibreOffice 184.108.40.206 package on Gentoo Linux, use Liberation Sans 10 pt (the default font setting)
- Type "aaaaaaa bbbbbbbbbbbbbbbb cccccccccccccccc dddddddddddd eeeeeeeeee fffffffffffff gggggg hhhhhhh iiiiiiiiiiiiiiiiiiiiiiii" in cell A1
- Set the width for column A to 18 cm
- Enable automatic line breaking for cell A1 (the text is displayed in two lines, the "iiiiiiiiiiiiiiiiiiiiiiii" appears in the second line)
- Save the file and close it
- Open the file
Row 1's height is set to the default height, but the cell A1's text is still line-breaked. This leads to the text being clipped
The height row 1 had when the file was saved should be preserved, no text should be clipped
User Profile Reset: No
Interestingly, this only happens for specific column widths:
If one sets the width of column A to 17 cm (instaead of 18), the visible result is the same, "iiiiiiiiiiiiiiiiiiiiiiii" is displayed in a second line.
But, in this case, after saving and re-opening the file, the height of row 1 is restored correctly, and no clipping happens.
See the screenshots I'll attach!
Created attachment 177415 [details]
Example with a column width of 18 cm before saving
Created attachment 177416 [details]
Example with a column width of 18 cm after saving, closing and re-opening
Created attachment 177417 [details]
Example with a column width of 17 cm before saving
Created attachment 177418 [details]
Example with a column width of 17 cm after saving, closing and re-opening
Created attachment 177419 [details]
The 18 cm column width saved file
Created attachment 177420 [details]
The 17 cm column width saved file
PS: Maybe this is still or again the problem from Bug #49255, but this one has been filed and fixed almost a decade ago. I just found it whilst researching the possible cause for this bug here.
- Open the 18 cm column width sample file (https://bugs.documentfoundation.org/attachment.cgi?id=177419)
- Paste "1111111 2222222 3333333 4444444 5555555 6666666 7777777 8888888 9999999 0000000 1111111 2222222 3333333" in A2
- Set Wrap Text
- Change the zoom level
The second 2222222 group changes from first to second line depending on zoom level. But, after reload, Wrap Text is not lost for this cell.
Version: 220.127.116.11 (x64) / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: es-MX (es_ES); UI: en-US
Skia is not enabled.
Maybe the title must be changed. A line break in a cell is set with Ctrl+Enter (not the case here). Wrap Text is the issue here.
This is actually right ;-)
Wrong or correct cell height with wrap can be seen already on fileopen.
No repro 6.1 oldest, repro 6.1 master and 7.4+. Seems regression.
Date: Tue Oct 23 00:07:51 2018 +0200
author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2018-04-06
commit 693953dd4699887bd3f5bca2c3582b5fae1d6992 (patch)
tdf#62268: allow row height recalculation on document load
During document load rows with style:use-optimal-row-height="true"
should recalculate it's height.
* includes: Row height tolerance level increase for unittest
* tdf#118086: calc: invalid row autoheight fixed
Could be a duplicated of bug 130383 or bug 132354 but let's keep like this, because all is clear.