Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | "Distribute rows evenly" defective; should be named differently | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | raindrops <na1000> | ||||
Component: | formatting | Assignee: | AOO issues mailing list <issues> | ||||
Status: | CONFIRMED --- | QA Contact: | |||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues, lars_o_hansen | ||||
Version: | OOo 2.0 | Keywords: | oooqa | ||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows NT | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
raindrops
2005-11-23 08:26:51 UTC
for me the commend does exactly what you expect. Can you give a step-by-step description of how to achieve your problem? Setting up: 1. Insert a small (say, 4x4) table in a fresh file. 2. Change the width of one column by dragging its right side border. 3. Click in the 3rd row and increase its height by pressing ALT+Down Arrow key. Experiment-1: Select a few cells that involve the 3rd row (which has a different height). A popup toolbar named "Table" appears. In this, press the "distribute rows equally" button. I expect only the seelcted cells to change the height, but here the entire row is affected. Secondly, I expect the total height of the selected cells to be REDISTRIBUTED equally. Instead, the maximum height in the range is taken and each row's height is made equal to that. As a result, the total height of the table increases. Experiment-2: Select a few cells that involve the column with a different width. A popup toolbar named "Table" appears. In this, press the "distribute columns equally" button. I expect only the selected cells to change the width, but here the entire columns are affected. > Select a few cells that involve the 3rd row (which has a different height).
> A popup toolbar named "Table" appears. In this, press the "distribute rows
> equally" button
If I select cells in a row, I only get a "distribute columns equally" button.
You cannot format a cell different from the row/column it is in, so the
command always works for the whole row/column.
For me the column widths are adjusted so that they are of equal length. Sorry,
but I didn't quite get your problem.
1. Your selection should have cells from >= 2 rows ana d >=2 columns. (In other words, the section should be at least 2x2 cells.) Do NOT select the entire row/column for the experiment. With that, you should be able to get both buttons ("distribute columns equally" and "distribute rows equally") activated. 2. As I explained in my last post (see steps 2 and 3), first you have to change the row height (and column width) to make them unequal. Only then will you be able to see the effect of these commands. (If the table ALREADY has equal-sized rows and columns, how can you check these commands??) confirmed on Windows XP SP2 with OOo-dev 2.0.139: insert a 2x2 table increase the height of the 1st row select cells A1 and A2, so column A if it not appears automatically, choose View->Toolbars->Table select Optimise->Distribute rows equally: the involved rows heights are adjusted to the largest height of the involved rows. This is different from the Distribute columns equally command and different from what the name implies: defect. That the whole row is affected is no defect: individual cells can't have different heights/widths from the row/column they are in. >individual cells can't have different heights/widths from the
> row/column they are in.
That logic is NOT correct-- The width/height of a cell can NOT be constrained by
its column or row. The simple reason for that is that unlike a spreadsheet,
cells in Writer are not meant to be stacked in a perfect row or column.
In fact, Writer does allow a user to have staggered borders of cells in a table.
Try this simple experiment:
In a 4x4 table, split cell B2 vertically. A new cell C2 is created. You can drag
the border between B2 and C2 to resize both these cells FREELY, without
affecting the other cells. This vertical line between the new cells is NOT
aligned with any of the columns of the table.
Note also that the erstwhile C column now has a mix of cells: C1, D2, C3, C4,...
If you move the right-hand border of column C, the cell D2 also gets resized.
Going by your logic, it should not!
The bottomline is, Writer does allow a table where any cell can have a staggered
border, which can be adjusted freely WITHOUT affecting the neighboring cells.
In a similar way, if you have a row with adequate height, you can split a cell
vertically and then drag its midle border vertically without affecting the row
height. (If your original row has only bare-minimum height, resizing the cell
will affect the entire row. But if you increase its height beforehand, you CAN
resize the split cells without affecting the row.)
To sum up, Writer allows the user to freely adjust a cell border with one
mechanism (cell-splitting), but not with the other (with the "redistribute
height/width" command)!
And THAT is the inconsistency in its behavior, and therefore a defect.
****
BTW there two other limitations that are based on the same faulty logic:
* User not allowed to draw a table (as the "pencil" tool does in MS Word)
* User not allowed to erase the border between certain cells (as the "eraser"
tool does in MS Word).
But the user can have EXACTLY THE SAME EFFECT, by splitting and merging the
cells, respectively!
(I know there is a separate issue for this topic, but since it is based on
EXACTLY the same logic, it deserves a mention here.)
I carried out some more experiments, and found that Writer does not allow the user to break up any vertical line that is formed across multiple cells. In MS Word, you can select a few cells and then drag the line. In Writer,you cannot break the vertical line. For example, try this experiment: 1. Split B2 into 2 vertical cells. 2. Split B3 into 3 vertical cells. Each of these partitions can be resized by dragging the sides. The other cells are not affected. But now try this: 1. Split B2 into 2 vertical cells. 2. Split B3 into 4 vertical cells. Now the middle edge is common. You can NOT drag it in 2nd row alone: The 3rd row is also affected. But the other two partitions in the 3rd row CAN be dragged independently. your last observation sounds like a defect: file an issue for it! Sent the file through yousendit.com, but after sending the file I am not getting the confirmation screen. Instead, "This page not available" error screen comes up. Not sure if you got it (tried thrice). Please confirm recepit! P.S. Sending the file through my gmail account results in "This document contains no data" error. Oops! Ignore that last post: entered that in the wrong issue! MRU->FL: the Tooltip for the button "Distribute rows evenly" should be named differently. Currently it has the meaning of making three row the same height by distributing the given added three row heights and not adapting the height of the largest row. Well, correction in tooltip was NOT what I had in mind: The real problems reported in this issue are not addressed at all! We started with these TWO issues: 1. Writer cannot redistribute the available width. (There will be cases when the user does NOT want to increase the dimension of all cells, but manage WITHIN the available overall dimension. In fact, increasing the overall dimensions of the table may create other problems, like table exceeds the page margins, the larger table affects the flow of text sourrounding the table and spoils the aesthetics of the page, etc..) 2. Writer cannot limit the change to the selected cells only. I have posted supporting arguments why OOo should behave like that. No one has put up convincing arguments against them. Now we have three options: 1. You could prove me wrong, and we rest the case. 2. You could accept them as defects and start further processing. 3. You could respond that these features were not intended to be there in OOo2 at all, so these are not defects, but rather "desired enhancements". I will be happy to file separate issues and call them "Enhancements" (not "defects"). I just noticed that there is a practice of changing the summary to suit the diagnosis. While that may work for poorly worded issues, often it ends up twisting the projected issue altogether. It has happened with other issues I have raised, and this post may carry traces of the frustration I am feeling right now. In this case, I do not have a problem against the tooltip: I have raised an issue against the basic behavior itself. This is like I am saying, "This gun is not able to hit its target, so please make it more accurate". And the workaround is, "Paint a bull's eye around the place where it manages to hit". How can the two be equivalent? Granted that thousands of issues must be stretching your resources, but this is surely not the way. Please do not mess up the original message like this. Created attachment 71109 [details]
Macro that replicates the expected behaviour of Distribute Rows Equally
I've just attached a text file that contains the code for a macro that replicates the expected behaviour of the 'Distribute Rows Equally' command. To use it, you need to click 'Tools, Macros, Organise Macros, OpenOffice.org Basic...'. You then need to open up 'My Macros, Standard, Module1', click 'Edit', then paste in the contents of the attachment. Once that is done, go to 'Tools, Customise', Click on the 'Menu' tab, Choose the 'Table | Autofit' menu. Click 'Add...', scroll down to 'OpenOffice.org Macros' and find the macro you just pasted in. (Optionally) Rename the menu entry to whatever you want it to be. (Optionally) Remove the misleading original menu entry. I would package this up as a proper extension, but I really have no idea how to even start doing that. This works fine PROVIDED you don't expect it to work on the entire table. If you select the whole table it sets the row height in all rows to be the same as the last row (or possibly the largest, I haven't experimented). |