Bug Hunting Session
Bug 44871 - TABLES Distribute rows equally works unexpectedly different from "Distribute Columns Evenly"
Summary: TABLES Distribute rows equally works unexpectedly different from "Distribute ...
Status: RESOLVED DUPLICATE of bug 64242
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-17 13:20 UTC by Ken Springer
Modified: 2018-09-17 19:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Springer 2012-01-17 13:20:38 UTC
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.
Comment 1 Pedro 2012-01-17 14:23:12 UTC
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)
Comment 2 Rainer Bielefeld Retired 2012-01-17 22:14:51 UTC
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.
Comment 3 Ken Springer 2012-01-18 05:47:29 UTC
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?
Comment 4 Rainer Bielefeld Retired 2012-01-18 07:06:47 UTC
@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.
Comment 5 Ken Springer 2012-01-18 18:17:04 UTC
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
Comment 6 noeck 2013-02-20 20:03:14 UTC
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.
Comment 7 V Stuart Foote 2013-05-05 17:06:20 UTC
adding UX enhancement bug 64242 to the see also -- for UX review of handling Distribute and Equally Space cells in table.
Comment 8 QA Administrators 2015-04-01 14:41:11 UTC Comment hidden (obsolete)
Comment 9 V Stuart Foote 2015-04-01 16:14:18 UTC
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 ***
Comment 10 Justin L 2018-09-17 19:43:58 UTC
(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.]