LibreOffice 3.4.4 OOO340m1 (Build:402) Intel Mac, OS X 10.6.8 (10K549) Snow Leopard, Kernel Version: Darwin 10.8.0 Libre Office Table Row equal distribution bug ⁃ Open a new document. ⁃ Create a 4X5 table. ⁃ Place the mouse cursor in the vertical ruler, and extend the height to a vertical dimension of your choice. ⁃ HIghlight the entire table. ⁃ Select Table>Autofit>Distribute Rows Equally. All rows will have the height of the rows changed to match the height of the largest row, rather than being fit into the selected vertical space. Distribute columns equally works correctly, at least as I am expecting the feature to operate. Please feel free to email with any questions.
I can confirm the same happens under Windows (XP Pro x86 SP3)at least as far back as LO 3.3.4 Creating a table with unequal columns does work as expected (i.e. column widths are adjusted so that all columns take the same vertical space)
Reported effect is reproducible with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta3- WIN7 Home Premium (64bit) German UI [Build-ID: e40af8c-10029e3-615e522-88673a2-727f724]. But is it a bug? I Help I read: "Distribute Rows Evenly - Adjusts the height of the selected rows to match the height of the tallest row in the selection." So current behavior is intended. Bud indeed, there remain several questions: 1. Why do "Distribute Columns Evenly" and "Distribute Rows Evenly" work different? "Distribute Columns Evenly" result is equal column width within old table width, so everybody would expect that "Distribute Rows Evenly" result would be equal row height within old table height 2. If "Distribute Rows Evenly" way to work is expected to be more useful (and I believe it is), why is it called "Distribute Rows Evenly" and not "Fit rows height to maximum height in selection"? @Cédric: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Hi, Rainer (In reply to comment #2) > Reported effect is reproducible with Parallel Dev-Installation of "LibreOffice > 3.5.0 Beta3- WIN7 Home Premium (64bit) German UI [Build-ID: > e40af8c-10029e3-615e522-88673a2-727f724]. But is it a bug? > > I Help I read: > "Distribute Rows Evenly - Adjusts the height of the selected rows to match the > height of the tallest row in the selection." So current behavior is intended. > > Bud indeed, there remain several questions: > > 1. Why do "Distribute Columns Evenly" and "Distribute Rows Evenly" work > different? > "Distribute Columns Evenly" result is equal column width within old table > width, so everybody would expect that "Distribute Rows Evenly" result would be > equal row height within old table height > > 2. If "Distribute Rows Evenly" way to work is expected to be more useful (and I > believe it is), why is it called "Distribute Rows Evenly" and not "Fit rows > height to maximum height in selection"? Respectfully, I totally disagree on point 2. :-) I use tables frequently when I want to display information and have the information formatted neatly and cleanly. (I hope that is clear, if not, please let me know.) Create a 4 X 5 table. I can experiment with the height of one row to fit information/data into the height of the row. If I now want all the rows to be that height: 1. Select the row 2. Right click> Row> Height will tell me the row height. 3. Select all rows 4. Right click> Row> Height, insert the height from Step 2, and all rows are the same height. Most of the time, I want X number of rows to fit into a fixed height. I do not want the height of the table to vary, as the table *must* fit into this fixed height. I may change the number or rows, but the table height cannot change. The only way to do this that I can find is very cumbersome. You have to know the exact fixed height of the table before you create it. Then manually compute the height of the rows. Now, create your table. But, what happens when you discover your original fixed height does not work, and/or you need to change the number of rows in the table? With the program working the way it currently does, you have to basically start all over and recalculate manually the new row height, and make your changes. But if the row feature worked identical to the column feature, all I would have to do is adjust a couple of rows to be able to put the bottom of the table where I desired it, click the Distribute Rows Equally, and I'm done. Much easier, much faster. This is my first bug report filing, and I see attachments are allowed. If it would be easier for you or anyone else, I'd be happy to attach a document I created, and explain how I use tables. If a document is attached, is there a preferred file type?
@Ken: If your needs are different from the current behavior I recommend to discuss that in <libreoffice-ux-advise@lists.freedesktop.org>. May be the results of the discussion will be to submit an additional request, similar to <https://issues.apache.org/ooo/show_bug.cgi?id=14336>. But here we have to fix the misinterpretative name for the current behavior.
Hi, Rainier, (In reply to comment #4) > @Ken: > If your needs are different from the current behavior I recommend to discuss > that in <libreoffice-ux-advise@lists.freedesktop.org>. I am definitely not a fan of mailing lists. :-) I access some LO mailing lists via gmane.org. Is this list essentially the same as gmane.comp.documentfoundation.libreoffice.ux-advise? > May be the results of > the discussion will be to submit an additional request, similar to > <https://issues.apache.org/ooo/show_bug.cgi?id=14336>. I find it depressing this question/issue has been around this long. :-( > > But here we have to fix the misinterpretative name for the current behavior. Agreed. Ken
Sorry, but that is not at all the expected behaviour. I heard now many people complaining about the way it is now in LibreOffice. What I (and all people I know) would expect, is this: the overall table height stays the same and the rows are spaced equally, like the name says and like it perfectly works for the columns. If someone finds the current functionality useful, this should be named differently. But a correct space-rows-equally function is definitely very useful and needed. I think this bug should be worked on.
adding UX enhancement bug 64242 to the see also -- for UX review of handling Distribute and Equally Space cells in table.
** 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 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-04-01
This remains an issue, but will work UI and UX from similar bug 64242. *** This bug has been marked as a duplicate of bug 64242 ***
(In reply to Rainer Bielefeld Retired from comment #2) > 1. Why do "Distribute Columns Evenly" and "Distribute Rows Evenly" work > different? Because columns and rows act very differently in terms of response to data-entry. Columns do not auto-grow, but rows do. Columns do not need to fit all of the content, but rows do. So, only three row options make sense. 1.) minimize (reduce the table size), or 2.) equally space for symmetry (based on the largest row - increase the table size). 3.) Additionally, I could see the value in combining minimize, followed by an equally space (symmetry using the minimal space) with a no-shrink requirement. This allows the bottom row to be increased to the desired table size, and then that huge row is distributed among the other rows (the situation described in comment 0). [the user could also combine minimize, followed by equally space to achieve minimal symmetry in a shrunken table.]