Created attachment 67837 [details] Spreadsheet that fails to expand row height How to reproduce: Open sample spreadsheet Enter text that doesn't fit in a cell Select from the main menu: Format -> Cells... Select "Wrap text automatically" on the "Alignment" tab Press OK Expected result in LibreOffice 3.5:build-403 Build ID: 350m1(Build:403) on openSuSE 12.2 (32-bit) The text wraps on the right cell border. The row height expands automatically to show all lines of the text. Actual result in debug builds LO version 3.7.0.0.alpha0+ (Build ID: dccddcc) on openSuSE 11.4 (x86-64); LO version 3.7.0.0.alpha0+ (Build ID: 39157df) on openSuSE 12.2 (32-bit): The text wraps on the right cell border. The row height does not expand. Not all lines are shown. This is a regression, because it works in LO 3.5
Also working OK in LO 3.5, but not working in master builds: Selecting "Optimal Row Height..." in the context menu of row labels Also no automatic height change when adding a subscript or superscript to the cell text.
Confirmed and this one is strange as I started with a fresh sheet and was able to work with it no problem. How did you create this sheet? I can't confirm that it works as expected in 3.5 so not marking as regression yet Marking: New (confirmed for this particular sheet) Minor (Is annoying but there is a workaround in manually resizing row) Lowest (let us know how you made this document and we'll see how many people would/could run into the same situation, if it's something that a lot of people do then we'll up the priority.) Thanks for reporting Stephan
Hi Joel, The sheet was created with an older version of Open Office. Can't retrace the exact version, but probably 3.1.0 or 3.2.1.
Just tested with Libre Office version 3.6:build-303 (Build ID: 360m1(Build:303)) on openSuSE 12.2 (x86). Row height expands OK.
I can confirm Joel Madero's observations more or less. I terribly suffer from this problem (WIN7 LibO 3.6, LibO 4.0), but I never managed to create a sample document from the scratch.
This one is [Reproducible] with "LibreOffice 3.6.5.1 rc" German UI/ German Locale [Build-ID: 5b93205] {pull date 2013-01-18} on German WIN7 Home Premium (64bit): When I open reporter's sample I see 'A1:A2' with too small row heigt Editing these cells: 1. Add "Text wrap" to A3 2. Type some 3 lines nonsense text, <tab> Unexpectedly wrap disappears This effect is the same as in "Bug 59581 - FORMATTING: Text wrap fails in existing document.ods", bot for that document the problem starts with 3.7 Master. Mp Idea whether related to reporter's problem here. Reporter's document is NOT conformant ODF1.2: * content.xml:27 col:51 - bad value for attribute "text-position" from namespace "urn:oasis:names:tc:opendocument:xmlns:style:1.0" * styles.xml:144 col:184 bad value for attribute "time-value" from namespace "urn:oasis:names:tc:opendocument:xmlns:text:1.0"
Reproducible in MASTER on Ubuntu 12.04 (32-bit) Version: 4.2.0.0.alpha0+ Build ID: c2530b02311c46529eed53ee688bf6c83ce4b86
** 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 (4.4.1.2 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
OP reproducible on MASTER. Version: 4.5.0.0.alpha0+, Build ID: ca7f62c8262662c8f58a3fa3b298623f25b55eaa, Locale: en_US on openSuSE 13.2 (x86-64). Also still no automatic height change when adding a subscript or superscript to the cell. Selecting "Optimal Row Height..." works correctly again, though.
** 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.5 or 5.1.2 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: 2016-04-16
optimal row height does not refresh after text input (not sure after a value input) when 'optimal row height' (+0,1cm) has been selected (on multimple rows, right click on row-number), when text is entered in an empty cell, the optimal row height is not applied nor refreshed : it has to be selected again (right click on the row-number-line) though it shows already the value selected initally (+0,1cm) clicking ok applies row height. it may be simply a refresh to be done after text is entered in a cell (where optimal row height was pre-selected) (in the 'format cell' tabs, it is not showing the cell has an optimal row value) Version: 5.3.1.2 / Build ID: 1:5.3.1-0ubuntu1~yakkety0
Repro in master 6.2+ I guess it's more of an interest to know why this happens in old file than of practical use.
Still here in 7.0.1, after all these years... I agree this is probably a problem of applying optimal row height after a new entry is made. And I quite disagree with the importance set for this bug. In certain contexts, this problem is VERY annoying, like in the case of software localization. Typically, localizations use big spreadsheets containing various technical data, the text to translate and empty columns that need to be filled by the translators. And these spreadsheets are (tens of) thousands of lines long, with cells containing sometimes just one word, sometimes hundreds of words... So having to constantly manually refresh the row heights is quite a pain. Especially when the files get really big, and refreshing all the spreadsheet (selecting every cell then double clicking on a separation line between two cells) can sometimes take 10s or more... I've been plagued by this problem for years, in Win 7, Win 10 and now Linux Mint...
*** Bug 139617 has been marked as a duplicate of this bug. ***
Maybe me but this apparently not a regression for Windows environment..
I don't know why I marked regression, I guess because of Comment 0. But it's the same from OO and in 3.5 and in 7.2+ Workaround is to select celks or all and Optimal row height. Bug 59581 was marked duplicate of fixed bug 59193,seems similar.
No surprise that "No Automatic Row heigth expansion.ods" doesn't expand cell A2. The document.xml defines <style:style style:name="ro1" style:family="table-row"> <style:table-row-properties style:row-height="0.45cm" style:use-optimal-row-height="false"/> So this style (which applies to both A1 and A2) sets a specific height and says to not use auto-height. [A round-trip of the file after setting optimal height worked fine.]