To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4032
------- Additional comments from [EMAIL PROTECTED] Mon Apr 7 08:49:50 +0000 2008 ------- ama->jkaufmann: 1. The (table) behavior of OOo does not meet your expectations in some cases. We should discuss every issue and see what we could/should/need to do. 2. Your conclusion is that these issues do have a common root cause (the table model) and that we should change these model to get rid of the issues. 3. You ask some "why" questions (Why should anyone what something, why do we have handle row and columns differently) ad 2: I do not think that we need to change the table model (again) to meet your expectations. Every issue you mentioned could be fixed within the current table model. But I don't think that we need to discuss this. It's only an implementation detail. We need to discuss your issues and decide which have to be fixed. And if I'm wrong and it would be better to change the table model again, I will be fine with this. ad 3: Why should somebody want to get a cell "out of sync"? Maybe for layout reasons? If the content of just one cell of my table does not fit into the cell and I do not want to extend the width of the whole column. At least there was a demand for this feature, normally you move the column with the mouse. Only if you press this modifier, you are able to move a single cell border. Why do we handle rows and columns differently? I think there is a quiet natural difference between horizontal and vertical direction. English writing direction is horizontal (left-to-right), the text flow vertical. In horizontal direction the space is limited (by the page border), in vertical direction the text flows to the next page if necessary. This does not only hold for paragraphs outside a table, this is valid for the content of cells as well. The width of columns is fix, the height of rows is variable (as default), they could grow if the content needs it. If I insert a new column to a table, the width of the table does not grow, the other columns have to shrink. If I add an additional row to a table, the table height grows. If I have a 3x3 table, my expectation to cursor traveling is for cursor-right: A1->A2->A3->B1->B2->B3->C1->C2->C3->leave table For cursor-down: A1->B1->C1->leave table (and not C1->A2->B2->C2->A3...) And what about the content? A typical table content could be data from a data base. Normally every column would represent data of the same type (e.g. number, date or text). Every row would represent a set of data of different types (e.g. name, birthday, address of a person). That's why I think it is no problem if we handle rows and columns differently in some cases. But if you create a table with fixed row heights and play around with our merge and split algorithm, does it fit to your expectation? And yes, I have been caught by the horizontal/vertical naming for splitting cells. A vertical split creates cells with the same horizon, that confused me :-/ But luckily there is an icon in that dialog, "a picture is worth more than 1000 words". Which behavior is optimal, row or column? Because rows and columns are different, there is no optimal behavior for both in every case. E.g. for the current naming convention of cells I would prefer the "column" convention but for rows it is not possible to use the same convention. ad 1: I tried to figure out, in which cases our current table handling does not meet your expectation, I found these five issues: 1) Cursor traveling: that's the easy one, if the first cell of a table is merged, the cursor traveling does not meet my expectation in the case you described as well. This is a bug, but a fix will surely not need a renewed table model. Maybe we need to improve our cursor model but not the table model. 2) Splitting cells vertically: this could be improved by an additional option (with/without equal proportions). Our table model "knows" the widths of every column so I do not need to change our table model. To invoke such option is not a big task. (And the result will be that we will get rid of another difference in row/column handling). 3) Splitting cells: Change the dialog strings from horizontal/vertical into row/column. No big deal, if user experience agree with this. 4) Naming convention: The both discussed naming conventions can be delivered by our table model, it's an easy algorithm which converts "my" convention into "yours". So I would be able to change this naming scheme without any change of the table model. So we have three possibilities: leave the naming unchanged, switch to another naming or make the naming convention arbitrary. 5) Merging cell has unexpected effect: A row seems to vanish because of their minimum height of 0,01cm (Yes, I mean row height with checked "Fit to content") if there is no content which overlaps to this row. This does not make the table model unreliable because the model does it job, it merged the cells and the layout does it job, too. It layouted like the properties are set. But to get rid of this unexpected effect, such "merged" row could get automatically another value for its minimum height. This is what another word processor does and again there is no need for another table model. Every issue is worth to be submitted and discussed separately. For 1) and 2) I agree that they should be fixed/implemented, it's just a matter of resources and priority. 3), 4) and 5) could be done but this has to be discussed and decided with the input of other customer and user experience. I do not see a common root cause for these issues and do not agree that handling them separately would be hacking on the symptoms only. I do not have a skype handle but of course we could discuss things off-line ([EMAIL PROTECTED]) if they do not fit into this issue. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
