When work wrap is enabled for a cell (or cells), the row height is automatically increased or decreased to fit the content. However, if the column width is modified (increased / decreased), the row height of filled cells does not update automatically. Becomes a problem when the column width is reduced and the contents gets hidden. Issue reported in a wiki post @ ask.libreoffice.org http://ask.libreoffice.org/question/8225/cannot-wrap-text-in-cells-in-calc/
Confirmed the behavior for LO 3.5.7 up to LODev 3.6.5.
(In reply to comment #1) > Confirmed the behavior for LO 3.5.7 up to LODev 3.6.5. Therefore 'NEW'. Is it still reproducible using LibreOffice 4.0? Kind regards, Joren
(In reply to comment #2) > Is it still reproducible using LibreOffice 4.0? Sorry for my change, but therefore I'll set Bug Status to NEEDINFO. I know there are made some changes in 4.0 quite related to this issue. Therefore I ask this to retest. Thanks for your time. Kind regards, Joren
reproduced on Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) on WinXP. Recalculation of row height is not done until a new line wrap (forced by a word passing the right border of the cell) is done. Steps to reproduce: 1. in Calc select a cell and format it with automatic word wrap (Format - Cells - Tab:Alignment - wrap text automatically: Check). 2. Add text that floats over the right border of the cell. 3. Result: Text is wrapped to fit cell width, row height is adapted to fit the content. 4. Reduce the width of the cell (just move the right border of the column header a bit to the left) until word wrap forces a new line of text. 5a. Expected result: Similar to 3. 5b. Present result: Text floats to a new line in the cell, but row height stays the same. The new line is not visible, but a red triangle on the right border of the cell indicates that there is more text in the cell. 6. Add more text to the cell without forcing a new word wrap. 7a. Expected result: Similar to 3. 7b. Present result: Similar to 5b. 8. Add more text, so a new line is necessary. 9. Result: Similar to 3. HTH - if this info is sufficient, please change status. Thanks Bernhard
(In reply to comment #4) > reproduced on Version 4.0.0.3 (Build ID: > 7545bee9c2a0782548772a21bc84a9dcc583b89) > on WinXP. Well done Bernhard! Thanks for your clear steps. I didn't test them yet, but because you can reproduce it I mark this as NEW for now. I'm currently building, so I'll test later. Kind regards, Joren
Just to add: Still the same behavior in version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) on Win XP. And we could include the lack of reducing the height when you broaden the cell in order to reduce the number of text lines: In this case the row stays too high and the text is positioned according to the standard vertical alignment (in my case: at the bottom of the cell). (if you want me to, I'll probably can provide a step-by-step description for this case too)
Being triggered by http://ask.libreoffice.org/en/question/38096/wrap-is-inconsistent/?comment=38100#comment-38100 I confirm the bug still exists in Version: 4.2.6.2 Build ID: 185f2ce4dcc34af9bd97dec29e6d42c39557298f running on XP Pro / SP3 It is actually a pretty annoying bug when task lists need to be created. It slows down productivity a lot.
(In reply to comment #4) > 5b. Present result: Text floats to a new line in the cell, but row height > stays the same. The new line is not visible, but a red triangle on the right > border of the cell indicates that there is more text in the cell. Reproduced in LO 4.3.1.1, 3.3.0.4 - Ubuntu 12.04 x86 Also in AOO 4.1.0, looks inherited from OOO
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Tested on Version: 5.0.0.5 Build-ID: 1b1a90865e348b492231e1c451437d7a15bb262b Windows Vista Business SP 2 Reproducing in comparison to comment #4, there is a different behavior in Step 7: > 1. in Calc select a cell and format it with automatic word wrap (Format - > Cells - Tab:Alignment - wrap text automatically: Check). done > 2. Add text that floats over the right border of the cell. done > 3. Result: Text is wrapped to fit cell width, row height is adapted to fit > the content. same > 4. Reduce the width of the cell (just move the right border of the column > header a bit to the left) until word wrap forces a new line of text. done > 5a. Expected result: Similar to 3. same >5b. Present result: Text floats to a new line in the cell, but row height > stays the same. The new line is not visible, but a red triangle on the right > border of the cell indicates that there is more text in the cell. same > 6. Add more text to the cell without forcing a new word wrap. done > 7a. Expected result: Similar to 3. same > 7b. Present result: Similar to 5b. DIFFERENT: When the cell content is updated, line wrap is recalculated an height adjusted -> similar to 3. > 8. Add more text, so a new line is necessary. same > 9. Result: Similar to 3. same So the bug is still present, but only when the column width is modified. If you enter any text in this cell or in another cell with automatic word wrap that needs recalculation (text longer than cell width or removal of a character), row height is recalculated. Best regards Bernhard
*** Bug 99118 has been marked as a duplicate of this bug. ***
Ubuntu 14.04 Version: 5.1.1.2 Build ID: 1:5.1.1~rc2-0ubuntu1~trusty0 Can confirm the following (from Bernhard Dippold from comment #10): > Reproducing in comparison to comment #4, there is a different behavior in > Step 7: > > > 1. in Calc select a cell and format it with automatic word wrap (Format - > > Cells - Tab:Alignment - wrap text automatically: Check). > done > > > 2. Add text that floats over the right border of the cell. > done > > > 3. Result: Text is wrapped to fit cell width, row height is adapted to fit > > the content. > same > > > 4. Reduce the width of the cell (just move the right border of the column > > header a bit to the left) until word wrap forces a new line of text. > done > > > 5a. Expected result: Similar to 3. > same > > >5b. Present result: Text floats to a new line in the cell, but row height > > stays the same. The new line is not visible, but a red triangle on the right > > border of the cell indicates that there is more text in the cell. > same > > > 6. Add more text to the cell without forcing a new word wrap. > done > > > 7a. Expected result: Similar to 3. > same > > > 7b. Present result: Similar to 5b. > DIFFERENT: When the cell content is updated, line wrap is recalculated an > height adjusted -> similar to 3. > > > 8. Add more text, so a new line is necessary. > same > > > 9. Result: Similar to 3. > same > > So the bug is still present, but only when the column width is modified. > > If you enter any text in this cell or in another cell with automatic word > wrap that needs recalculation (text longer than cell width or removal of a > character), row height is recalculated. > > Best regards > Bernhard As well as (from Bernhard Dippold from comment #6): > And we could include the lack of reducing the height when you broaden the > cell in order to reduce the number of text lines: > In this case the row stays too high and the text is positioned according to > the standard vertical alignment (in my case: at the bottom of the cell).
*** Bug 99459 has been marked as a duplicate of this bug. ***
I confirm this bug and tested on Version: 5.4.0.0.alpha0+ Build ID: 5d0e485e827057eee9fb2c997685690b710e7f34 CPU threads: 8; OS: Linux 4.7; UI render: default; VCL: gtk3; Locale: en-IN (en_IN.utf8); Calc: group Also, I would like to work on this bug. Thanks.
Dear Kumar Thangavel, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Happens when cell width is adjusted or when text data is entered into a cell and Calc automatically wraps the text. When new lines are added the row height should be adjusted. Version: 5.4.4.2 Build ID: 5.4.4.2-1.fc27 Workaround: Format --> Cells --> Alignment tab: Click the wrap text automatically box off and back on.
@Buovjaga I'm getting a little confused here. The cell height is adjusted when reducing the column width in 4.3.7.2 and 4.4.7.2 (except for a trigger is needed to adjust the column height). Clicking a different cell - which triggers the resize - is broken since LibO 5.0 (see bug 118729). Looks like the same issue as reported by bug 99118 and bug 99459
*** This bug has been marked as a duplicate of bug 118729 ***
Reopening again. While indeed the issue seems to be similar/identical, the other issue has been closed and the issue not fixed. Looking at the timeline, bug 118729 is rather a duplicate of this one (not vice versa). This one should be kept open until fixed.
(In reply to noreply from comment #19) > Reopening again. While indeed the issue seems to be similar/identical, the > other issue has been closed and the issue not fixed. Looking at the > timeline, bug 118729 is rather a duplicate of this one (not vice versa). > > This one should be kept open until fixed. To make it clear, the design team rejected this change, so this will never happen. Closing as such.
Really? That's an interesting decision. Is it not considered a bug per se, then? (Do you know where I can read about the motivation?)
(In reply to noreply from comment #21) > Really? That's an interesting decision. Is it not considered a bug per se, > then? (Do you know where I can read about the motivation?) Everything I know about it can be read in bug 118729. Personally, I would have liked to get the automatic height adaptation per width change, but if the design folks believe it would cause annoyance for others, I will not fight it. That said, we might still become like Excel, where if you double-click inside the wrapped & width-reduced cell, the height increases.
Related problem that definitely is a bug is: PDF export and print (preview too) look different to what's on screen when editing. - Following steps in comment 4, export/print have a larger row height to accommodate the overflowing wrapped text; - in some other cases, the overflowing text overlaps onto the next row in the export/print. See bug 112569 and its "see also"s. Another issue: if a cell has such a "wrapped text overflow", the row height does update when applying e.g. a border to the cell. Surely we can't justify not updating the row height on resizing a column, but updating it when applying a border... But all these issues need breaking into precise reports with simplest steps, if not already reported. The more I test this area, the more I see inconsistencies between canvas and export/print, and use of the overflow indicator, depending on steps and their order.