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] Tue Apr 8 18:23:39 +0000 2008 ------- jkaufmann->ama: Thanks again for your replies; we may be converging on a resolution. > "ama->jkaufmann: 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."< OK. Let me begin by apologizing for the following reply, which is longer than I would like. [I have tried to reduce it, but keep running into Einstein's dictum: the answer must be as simple as possible, but not simpler.] Again: Looking over the bug reports, two things seem clear: (a) The behavior problems that users (still) experience with OO tables are not about *my* expectations; those expectations seem to be almost universal. (b) The new table model has moved in the right direction, but has not arrived. A reading of fme/Frank Meies' blog <http://blogs.sun.com/GullFOSS/entry/too_complex_to_merge%3F> shows why: The earlier Subtable model is replaced by a Rowspan (but *not* Colspan!) model, in order to become closer, but not identical, to the model of the ODF and HTML formats and of other apps. The problem is that nowhere is there any recognition of *why* they are different: the semantic significance of tables. Like a graph, a table is almost always a structured view of data. When a user creates a table, it is almost always to represent a data structure [an example of the basic mathematical/logical principle of adding dimensions to enhance data analysis]. Typically it is a record/field (entity/attribute) structure, where the records (entities) are represented in rows and the fields (attributes) in columns. Sometimes a field will have arithmetic significance, for example a list of costs to be added. Sometimes, when a 2-dimensional view is inadequate to represent multi-variate attributes [where a 3rd dimension would enhance the structured view] a Column-span (Merge) is used to group two or more attributes by a common parameter. However, regardless how many Row or Column spans are used [how many natural dimensions are represented], the integrity of the data structure is enforced by a strict underlying grid model: No grid, no data integrity. That is a(n incomplete) semantic view of tables. It is typically the way tables are implemented - certainly in every other major word processor, but not only in word processors. It's important to recognize that file structures, like ODF or HTML, do not *enforce* semantic significance, but use the rowspan/colspan model in order to *accommodate* that structure. [It's also important to recognize that HTML, for example, is largely supplanted by the need for more structure: The semantic web is the future, and XML is its language precisely because it allows for the layering of meaning (structure) onto the data presented to our eyes and ears. We will increasingly use software to parse structured data for us; screen readers are only one, low-level, example. It is sad to see OO, with respect to tables, so far behind modern data structure.] With that understanding of the purpose of tables to represent data structure, let's return to Frank's blog: What is striking is that the OO table model is described entirely in terms of visual effect, without regard to data structure. Both the new Rowspan model and the old Subtable model are discussed entirely in terms of appearance, as if a table were simply a kind of freeform drawing tool. It's not just that the concept "data structure" is not discussed (the word "structure" is used only three times, all referring to appearance). Even the word "data" is absent (as is the *concept*, which is *central* to use of tables), as are ideas like "integrity" and "grid". And yet the bug reports on OO tables, all seem to be that users either can't achieve the structure they intend, or have seen their intended data structure violated. So it's hardly surprising that the new model, which seeks only to tweak the representation without considering the structure, is only partly successful at responding to those bug reports. Ironically, it should be noted that in principle there is nothing wrong with Subtables -- but not for the reasons given in Frank's blog. The problem with a subtable is the same as with any table: What is the semantic significance? If a (sub)table is inserted into a table as a way to convey the data for a particular attribute for a particular entity, then its cell addresses must all be referenced to *that cell* which the (sub)table occupies (which cell has the structural significance of providing that attribute for that entity). The *representation* - that it is a (sub)grid within the larger grid - comes after the semantic significance. So I'm afraid I must disagree with your premise that the problems are "only an implementation detail." Thus I will not bother all of us by responding to your paragraph on why rows and columns are treated differently, which discusses the matter completely in terms of superficial representation (on which we have significant, but secondary, differences), taking no account of the fundamental data structure. It would be silly to discuss differences on representation if we don't proceed from a common understanding about what is to be represented. [I'm afraid it is not coincidental that you have not responded to any of my points about data structure, which I find the common theme of the bug reports.] Similarly, the cursor travel anomalies are, I submit, artifacts of the basic fact that the cursor is not traveling a data structure, so I really don't think it's useful to discuss the cursor travel without the underlying table model. > "... 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".< I'm glad it's not just me. ;-) The fact that we both (and probably most users) get it backwards is probably a warning that the terms are ill-advised, and should be replaced by "row" and "column", which are used everywhere else. But I think that problem pales in comparison to the basic issue. In conclusion: I don't think it's useful to go around and around on your points about "cursor traveling" (1), "splitting cells" (2,3), "naming conventions" (4), and "merging cells" (5), as long as you proceed from the premise that "Every issue is worth to be submitted and discussed separately." [I use examples to illustrate an underlying problem, not to say that the examples are themselves individual problems.] Until we at least *look* at the table model in terms of semantic significance (data structure), it is probably a waste of everyone's time to talk about "implementation details". Once the underlying structure is fixed, those representation anomalies will go away. But until that happens, this most troublesome of OO issues will not be fixed, and for most users OO will not be a complete (and thus viable) alternative to Word or other apps. If we can address the basic issue, I will be happy to help in whatever way possible. Until then, I remain stunned that this issue is marked "CLOSED". --------------------------------------------------------------------- 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]
