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] Fri Apr 4 05:02:59 +0000
2008 -------
> fme->jkaufmann: Why do you think this issue is not fixed? Could you please
give a detailed description? <
Good question. Yes I should have been more explicit, instead of assuming that
the examples already in this thread were sufficient. So let's start with the
example from the original post of six years ago, a 2x3 table:
-----------
| A1 | B1 |
|----|----|
| A2 | B2 |
|----|----|
| A3 | B3 |
-----------
Merge A1:A2 and B2:B3.
The old OOo table model would not allow that second operation, returning the
error "cells are too complex to merge" (presumably because it requires row 2 to
contribute a cell in one column to a merger with row 1 and a cell in a different
column to a merger with row 3). However, most apps, with a strict grid model
underlying the table representation, handle this (or *any* combination of
rectangular merges) with obvious simplicity:
-----------
| | B1 |
| A1 |----|
| | |
|----| B2 |
| A3 | |
-----------
By contrast, the new OOo model gives this:
-----------
| A1 | B1 |
|----|----|
| A3 | B2 |
-----------
What's wrong with that? In the basic data model of a table - the reason that we
*use* tables in the first place - the row/column structure is a spatial analog
of the record/field structure for managing data. That's why the underlying grid
is important: it presumes an organization of entities (of a common class) and
their class attributes, such that when we spatially look down a row or column we
can compare entities against a certain attribute, or see all attributes
associated with one entity.
Next try a 3x3 table that may illustrate a little bit more:
----------------
| A1 | B1 | C1 |
|----|----|----|
| A2 | B2 | C2 |
|----|----|----|
| A3 | B3 | C3 |
----------------
First merge A1:A2 and B1:C1:
----------------
| | B1(B:C1)|
| A1 |---------|
| | B2 | C2 |
|----|----|----|
| A3 | B3 | C3 |
----------------
Now try to merge B2:B3 (or C2:C3). Again, the OLD table model would say "cells
are too complex to merge" - presumably because row 2 already contributes a cell
to a merged cell row 1 [though, ironically, it would *allow* a merger of A3:B3 -
even though column B also contributes a cell to a different column (C)]. In
other words, it was a really broken model, and the new model is better -- but
not by a whole lot. The new model (as of OOo2.3) *allows* the merger of B2:B3 -
----------------
| | B1(B:C1)|
| A1 |---------|
| | | C2 |
|----| B2 |----|
| A3 | | C3 |
----------------
just like a table in any other major word processor (say, Word or WordPerfect) -
but there the similarity ends. Because its underlying model is apparently not a
strict grid, we get anomalies. First, try walking the cursor through the table
(cursor right from A1 to C3),
A1(row_1) → B:C1 → A1(row_2) → B2(row_2) → C2 → A3 → B2(row_3) → C3 ,
which still looks good.
Now reverse direction (cursor left from C3 to A1). Other word processors, with a
strict grid model, just reverse the path:
C3 → B2(row_3) → A3 → C2 → B2(row_2) → A1(row_2) → B:C1 → A1(row_1)
but the new OOo model runs a different path:
C3 → B2(row_3) → A3 → C2 → B2(row_2) → A1(row_1?) , where it terminates.
On the other hand, if you walk the same path through the table using
Tab/Shft-Tab instead of cursor Left/Right, OOo gives a different result -
A1(row_1) → B:C1 → A1(row_2) → B2(row_2) → C2 → A3 → B2(row_3) → C3 ,
C3 → B2(row_3) → A3 → C2 → B2(row_2) → A1(row_2) → B:C1 → A1(row_1)
This time it appears to be the *same* behavior as other apps - but that path
difference between cursor Left/Right and Tab/Shft-Tab also speaks to a problem
in the model.
So far, with simple (2x3 and 3x3) tables, we have just looked at cell Merges.
What happens when we Split those merged cells? Again OOo's table behavior takes
inadequate account of an underlying grid. Again looking to other apps for
normative behavior, we find that Word and WordPerfect (typical of apps with a
strict grid model), when splitting a cell, defer to the underlying grid.
(WordPerfect actually *defaults* to the underlying structure of merged cells,
offering first to simply restore the pre-merge row/column structure of the
merged cell.) When splitting a simple cell, or splitting a merged cell into
more divisions than the underlying row/column structure will support, those
models based on a strict grid insert the necessary row(s) or column(s) *over the
whole table* to support that split, so that grid integrity is always maintained.
The OOo model is simply not sufficiently robust to do this.
For the simplest view of this issue, take 3x2 table:
----------------------------
| A1 | B1 | C1 |
|--------|--------|--------|
| A2 | B2 | C2 |
----------------------------
Now split B1 vertically into 2 cells. For all other apps I know, the resulting
table is:
----------------------------
| A1 | B1 | C1| D1 |
|--------|--------|--------|
| A2 |B2(B:C2)| D2 |
----------------------------
But for OOo, the result is:
---------------------------- [If, instead of first splitting B1,
| A1 | B1 | C1| D1 | you merge B1:C1 and then split
|--------|--------|--------| that merged cell vertically
| A2 | B2 | C2 | into, say, 3 parts, the OOo
---------------------------- result is even more weird.]
- which simply destroys the data integrity of the table.
On the *other* axis, however, OOo gets at least this issue *right*, as a 2x3
table shows:
-----------
| A1 | B1 |
|----|----|
| A2 | B2 |
|----|----|
| A3 | B3 |
-----------
Splitting B2 horizontally into 2 cells give this -
-----------
| A1 | B1 |
|----|----|
| | B2 |
| A2 |----| [Note the insertion of a row across the whole table,
| | B3 | so that cells A3 and B3 become A4 and B4, which
|----|----| maintains their necessary relationship.]
| A4 | B4 |
-----------
- which is just the way other apps handle it (and different from the vertical
split in the 3x2 table). It's a simple proposition: *both* aspects of the OOo
table model can't be right, even if you think OOo has done it better than other
apps (which is a hard sell).
Sorry this answer was long; I could not see how to make it shorter. When I
realized that what seemed obvious (that the current fix does not even address
all of the examples in this thread) was not obvious, I thought I had best be
sufficiently comprehensive for clarity. Even so, I cut out a lot from the
answer drafted initially. In particular, I took into account your Sep.25 answer
to kfen (about zero-height cells and the effect of adding text [which I had
previously noticed]), and realized there is much more to that issue as well...
but that got *really* long, and this post has to end somewhere. ;-)
---------------------------------------------------------------------
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]
