Description: Text invisible when resizing a cell & wrap text automatically enabled Steps to Reproduce: 1. Open the attached file 2. Copy the text in cell B2 3. Select B2 4. Format -> Cells -> Alignment 5. Check Wrap text automatically & Press OK 6. Enlarge column B by dragging column slider to the right 7. Text invisible 8. Click a different cell -> still invisible (but not in 4.4.7.2) 9. Save & reload -> fine Actual Results: Text invisible & except when entering the cell Expected Results: Visible text Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ Build ID: 6740443311268b7d918bf4f43134d64fb78a0109 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-15_23:37:04 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 148443 [details] Example file
2. Copy the text from the document into cell B2
2. Copy the text from the document and paste it into cell B2
Text it's not invisible, it's at the bottom of the cell, resize the row, and the text it's visible. Resizing the column not too much you can see some blank rows at top of the cell.
Created attachment 148451 [details] Screencast LibO6.3
Created attachment 148452 [details] Screencast LibO4.4.7.2
(In reply to m.a.riosv from comment #4) > Text it's not invisible, it's at the bottom of the cell, resize the row, and > the text it's visible. > > Resizing the column not too much you can see some blank rows at top of the > cell. BTW, you're correct about not invisible part.. It's present, but more or less out or reach (scroll large cells issue). However, I would prefer a downsize of the cell.. Excel does this when entering the cell (after the resize)... This did work before in LibO too. However, it's probably not gonna happen I guess, bug 118729
(In reply to Telesto from comment #7) This did work before in LibO too. However, it's probably not > gonna happen I guess, bug 118729 bisected to b505bc823706dd51e2652098fabb911cbcdd77e1 is the first bad commit commit b505bc823706dd51e2652098fabb911cbcdd77e1 Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 22:45:22 2015 +0800 source-hash-dca01def7885ad69cf66edd75cf8207a5adb64f9 commit dca01def7885ad69cf66edd75cf8207a5adb64f9 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> AuthorDate: Thu May 7 14:18:37 2015 +0900 Commit: Jan Holesovsky <kendy@collabora.com> CommitDate: Thu May 7 09:57:50 2015 +0200 refactor ListBox/ComboBox to use RenderContext
I'm a bit confused. If bug 118729 is for the behavior that there is no automatic row height calculation after a column resize, then what should we fix here? Should this be closed as a duplicate of bug 118729?
Nothing can be fixed here.. However, I still think that automatic row height calculation after a column resize *should* happens. Hench it did work this way before the given commit. And it does work the same way in Excel (if i remember correctly). The argumentation in bug 118729 is not convincing. But battling the mighty UX-advise division is a lost cause in this case. And sadly not to many reports for this issue either.. The midway solution would be an on/off switch for automatic row high calculation. But that will create a whole new problem of to many settings (and the question about the default setting). sigh Closing as duplicate of bug 118729.. *** This bug has been marked as a duplicate of bug 118729 ***
(In reply to Telesto from comment #10) > Nothing can be fixed here.. Something could be "fixed", to quote myself from bug 118729: "I tested with Excel 2013 and there the behaviour is: 1) Change the width of a wrapped cell, text gets cropped vertically (like with LibO) 2) Double-click to the cell from step 1) and click away: the height adapts to display the full text (LibO does not do this)" So we could implement the behaviour of Excel, which would not be such a big annoyance.