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] Sat Apr 5 14:37:41 +0000 2008 ------- jkaufmann->ama: Thanks for your replies. May I get clarification of some points? > ama->kfen: "BTW if you want to get a cell "out of sync" just drag the cell border with the mouse while pressing <Shift>+<Strg>."< Maybe this is the crux of my misunderstanding: When I see "if you want to get a cell 'out of sync'...", I just wonder Why would anyone want to do that? Looking over bug reports on this and the related issues, the common theme seems to be that they come from people trying precisely NOT to do that -- trying to maintain table structures that collapse in OO under standard cell merge and split operations. If I could understand why loss of structure is ever a feature rather than a bug, I would understand how OO's table model improves on what we see in other apps. Then my only remaining question would be whether the ideal is OO's row behavior or its column behavior (and, of course, why there is such difference). > ama->kfen: "For vertical splitting of cells we do have an option "Into equal proportions", which can be disabled (and is disabled as default!). For horizontal splitting we do not have such an option, we are splitting _always_ into _equal_ proportions."< Again I am confused, this time on two points: 1) In my copy of OO 2.4, the option of splitting "Into equal proportions" seems to apply to splitting Horizontally, not Vertically. (That is, Vertical splitting has no such option.) However, if this is just a matter of you being caught by OO's counterintuitive naming convention, I sympathize. When discussing OO table functions, I use the terms "horizontal" and "vertical" because those are OO's terms of choice (though I must admit they seem backward to me, as they may to you). I prefer the unambiguous terms "row" and "column" used everywhere else. 2) [As I have wondered elsewhere] Why is it good to have horizontal and vertical behavior be different? That certainly seems counter to every basic table model, whether matrix or record/field or any other structure I know. Can you help me understand the advantage of this, and what logical model it serves? > ama->kfen: "This can be changed, we could invoke such an option and we could change the split algorithm like you wish. This is no bug, is just a new feature, you could submit a feature/enhancement issue. But to implement such a feature I will not need to change our (new) table model. And I do not need to change our naming convention. It's only a local change in the split function."< Again, *which* "split algorithm" - "horizontal" (row) or "vertical" (column), and by what logic are they different? Looking at the bug reports - many of which are not resolved by the latest table model - they seem linked by the table model, not by the algorithm used for any particular merge or split operation. The new model is better than the old one, but all of the bug reports seem to anticipate a strict grid construction, and I don't think the new model is there yet. And if, when Cell Split is invoked, the choices offered take no account of an underlying grid, how is this an algorithm issue and *not* a model issue? > ama->jkaufmann: "I agree that there might be issues with our table handling. But none of your named issues is a problem of our new table model and none of them convinced me to reopen this task. The original problem of this task was the problem that the old table model disallowed the merging of table cells even in simple situations. This has been fixed by implementation of our new table model."< When you say, "The original problem ... was the problem that the old table model disallowed the merging of table cells even in simple situations", I think you arbitrarily narrow the problem considerably -- especially when other posts on this issue, and other issues which were closed as duplicates of 4032, are not so easily described. It is true that certain merge operations no longer return the error "cells are too complex to merge", but that does not necessarily mean that the merger which results is one which the user desires or expects -- especially if that result is different from what the user would get from other apps which set the norm for this domain. > ama->jkaufmann: "So what's your point? 1. You dislike the layout of the 3x2 table (with merged A1:A2 and B2:B3) because it does not show the underlying grid structure. Okay, it's a valid point. But if you have some text in your cells, you will see that the new table model has the expected structure."< Well, that's not completely accurate: It's true that the grid appearance changes with cell contents, but depending on *how much* text you have in *each* cell, the grid may or may not be apparent. Actually [as I found out in my last post, where I had to delete a long passage to make the length more reasonable], the analysis of how the appearance changes with cell contents, and why, is not immediately obvious (a problem in itself) and takes a lot of space to describe in words (though it's quick to describe with pencil and paper). I would be happy to discuss it off-list or in a phone call [do you have a skype handle?] or at least in a different post, but I'm reluctant to test readers' patience by making this post even longer. In any case, your reply begs this question: Why should the apparent grid structure change at all with cell contents? The philosophical objection to that goes [as I said earlier] to the *reason* we use tables: to provide a spatial representation of a logical structure - something that is hard, if not impossible, to do when the spatial representation is not completely reliable. The practical objection is this: If we want to make OO easier to use, more useful, or simply more appealing to more users - all of which amount to much the same thing - then why have table behavior that is so different from what users find in the normative apps, unless there is a strong case that the differences are *better* than those other apps? (And, so far, I don't see anyone even trying to make that case.) > ama->jkaufmann: "Or if you enter cell B2 and set the row height to a value like "at least 0,5cm", you will get the expected layout as well. That's the difference to another word processor, it sets the row height in such cases to "at least 0,49cm". So your point is not that we need to change our model again, you expect another value for the row height. Our default for row height is "at least 0,01" which causes these unexpected effect when cells are merged. You could write a new issue and suppose to change the row height after merging cells to another value. It has to be defined in which cases which value has to be chosen."< I'm sorry to disagree, but it's really not just a question of "which value has to be chosen" (and, if reliable representation of the table were dependent on "which value", what would *that* say about the table model?). But perhaps I misunderstand you again: I don't see a Row Height setting for "at least" x.x, but presume you mean by that to set the height x.x with the "Fit to size" box checked; is that correct? > ama->jkaufmann: "2. You described a problem with cursor travelling. Yes, that's simply a bug: if you have a merged table cell in the upper left corner of a table the cursor travelling is wrong is some cases. Please submit a new issue for this bug."< Well, I think there is a strong case that the example I gave, and many other cursor travel anomalies I have not mentioned, are all - like the grid representation problem - artifacts of the table model. So how would I "submit a new issue" without mentioning the table model and issue 4032? [If you know how to do so, perhaps you should submit that new issue?] When a common cause generates many apparent "issues", it's better to fix the underlying cause rather than try to hack around all the symptoms. > ama->jkaufmann: "3. You do not like the naming convention of our new table model, because - It does not reflect the grid structure (of the whole table). - It handles row and columns differently. Let's have a look at our current naming convention and of your proposed naming: This is our naming..."< [There follows a pair of unintelligible tables, such that I can't determine what you mean.] I'm sorry, but did you write your reply - and those tables - with a proportional font? - they are just unintelligible to me, in either my email client or on this page - both of which use a fixed font (as one would hope, for tables and other line drawings). Though I could not make out the tables, I think I can still address your conclusion on that point: > "Your first point, it does not reflect the grid structure of the whole table, e.g. cell A3 should be named A7 because its in the 7th column of the table. I prefer A3 because its in the third column of its row. But that's only my personal taste." Again I say: look at the underlying model, the reason for using the table. It is not a matter of "personal taste": The table must serve a certain data structure, and cell row/column identification must reflect the cell's logical place in that structure. It's not some arbitrary "naming convention". > "Your second point is valid, too. There is a difference between row and columns. So there might be people who prefer your naming convention and there might be people who prefer the current one. But there is no bug, no disfunctionality visible for me, so no reason to reopen this issue again. If you want, you could write a new issue where you propose your naming schema."< Let me try this one more time: It is NOT *MY* "naming schema" or "naming convention". Doesn't the fact that behavior is different for rows and columns - which do you prefer, by the way? - suggest to you that I'm talking about something more fundamental than naming conventions? Table cell identification is a well-established schema, over many years (and every other computer application I know), for a simple reason: it is inseparable from the data structure model it serves. Don't the posts to this thread, and all the other issues that have been collapsed onto this one, in the *six years* before I posted, suggest that maybe I'm not inventing some new "naming convention"? > "Conclusion: This issue (i4032) should not be reopened, it is fixed." I'm sorry, but saying "it is fixed" will not make it so, and failure to fix it would be a huge disservice to OpenOffice. If not fixed, this issue will remain the single biggest functional stumbling block to adoption of OO Writer (and hence OO) - a deal-breaker for many users. --------------------------------------------------------------------- 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]
