Issue 4032

Created attachment 1402 [details]
HTML table with arbitrary merged cells, for conversion

I've attached an HTML file of a 5x5 table with merged cells that looks
like this (except for the vertical centering of the text:

     --------------------------
     | A1 |    | C1 | D1 | E1 |
     ------ B1 ----------------
     |    |    | C2 | D2 |    |
     - A2 ---------------- E2 -
     |    | B3 |    | D3 |    |
     ----------- C3 -----------
     | A4 | B4 |    |    | E4 |
     ---------------- D4 ------
     | A5 | B5 | C5 |    | E5 |
     --------------------------

Note that each column has one merge of two cells. When the table is
imported into the OpenOffice word processor, the structure is
completely messed up:

     --------------------------
     | A1 | B1 | C1 | D1 | E1 |
     --------------------------
     | A2 | B2 | C2 | D2 |    |
     --------------------- E2 -
     | A3 | B3 | C3 | D3 |    |
     --------------------------
     |    |    |    |    | E4 |
     | A4 | B4 | C4 | D4 ------
     |    |    |    |    | E5 |
     --------------------------

So, the document attached can serve as a test case.

By the way, i spoke a little too soon about Mozilla Composer. Although
it did do the merges correctly in this example, it fails to do the
simpler 2x3 example i described in the original description of this
bug. (This is still better than OpenOffice, though, which fails both.)
Build 641(c?).

Leston, thanks for posting this issue.

I'm changing this issue to an enhancement request.

Thank you for using and supporting OOo.

Known limitaion due to current table concept.
Reassigned to Andreas.

We have to change our table concept.

*** Issue 13310 has been marked as a duplicate of this issue. ***

Should there perhaps be a meta bug for issues which depend on the
adoption of a new table concept? (And is bug 16561 another example of
such an issue?) If so, i would propose calling it "adopt new table
concept".

Is there any work being done on the new table concept? Will a proposal
or something of the like be posted on the Word Processing project page?

removing od from Cc.

Hi Leston,
please take your 5x5 html example, go to cell B1 and type in an <CR>
to get a second paragraph in there.
=> You get your wished table design, don't you?
For your 2x3 problem: Replace step 3. by:
3. Merge B1, B2 and B3.
4. Split B1 horizontal into 2 pieces.
5. Input some text into A1.1.1 until the cell grows.
So our current model is not too bad, but it's not perfect and not
always intuitive.
What do we plan?
I think first I've to describe our current behaviour and current
restrictions in a document at the Word Processing project page.
We will fix restrictions without a new model if possible. So we plan
to allow page breaks inside of cells. Your 2x3 problem could be solved
without a new model, too. We have to check this.
If we plan a new model, we'll present at the project page and discuss
it in the mailing list. But at the moment we don't plan this.

We should allow every merge which could be described by our table
model and the cells B2 and B3 should be mergeable after merging A1 and A2.

*** Issue 19406 has been marked as a duplicate of this issue. ***

.

*** Issue 21155 has been marked as a duplicate of this issue. ***

*** Issue 24775 has been marked as a duplicate of this issue. ***

estimated effort

*** Issue 27639 has been marked as a duplicate of this issue. ***

Because of a shortage of resources we have to retarget this issue to OOo later.

adding keywords according to new RFE process - Sophie

I'm sorry for disagreeing, but I think this is a bug, not an enhancement...

because this is from a technical point of view, not from usability one.

*** Issue 41532 has been marked as a duplicate of this issue. ***

*** Issue 42108 has been marked as a duplicate of this issue. ***

Unfortunately also I am not able to merge two or more cells. It would be
grateful to me for see solved this problem. Creating a complex header for a
table in a text enviroment would be a very useful capacity of OOo.
Thanks Dezse from Hungary

With OpenOffice 2.0 about to become final, will this issue remain unresolved? It
is still present in Writer tables in ver. 2.0 betas, inlcuding the recent 19.100
released to the public.

Regards,

Piotr

*** Issue 49836 has been marked as a duplicate of this issue. ***

*** Issue 49857 has been marked as a duplicate of this issue. ***

Is there any work fulfilled on the bugs dated by april of 2002? The new upcoming
OO 2.0 doesn't have the really trivial ability _all_ the competitors (MS Word,
AbiWord, KOffice...) have.

*** Issue 52149 has been marked as a duplicate of this issue. ***

There seem to be a lot of duplicate bugs for this issue.  Perhaps this means
that users find it a real problem?

I can't use the tables in the current m122 release: the simplest merge fails or
rearranges the cells.  This is a bug, not an enhancement. Please re-classify.

Anyone can try this:
--------------------
Open a fresh .odt document
Make a 6x6 table 
(I'll give co-ordinates as x,y starting with 1,1 in the top-left corner)
merge the cells 5,2  5,3 and 5,4
merge the cells 6,2 and 6,3
The merged box jumps down to 6,3 and 6,4
This is a bug.

Now select cells 4,1  4,2 and 4,3
click the merge button
Get an error message that the 'Selected table cells are too complex to merge'.

This bad table behaviour is letting the otherwise very good word processor down.

David

There seem to be a lot of duplicate bugs for this issue.  Perhaps this means
that users find it a real problem?

I can't use the tables in the current m122 release: the simplest merge fails or
rearranges the cells.  This is a bug, not an enhancement. Please re-classify.

Anyone can try this:
--------------------
Open a fresh .odt document
Make a 6x6 table 
(I'll give co-ordinates as x,y starting with 1,1 in the top-left corner)
merge the cells 5,2  5,3 and 5,4
merge the cells 6,2 and 6,3
The merged box jumps down to 6,3 and 6,4
This is a bug.

Now select cells 4,1  4,2 and 4,3
click the merge button
Get an error message that the 'Selected table cells are too complex to merge'.

This bad table behaviour is letting the otherwise very good word processor down.

David

*** Issue 55126 has been marked as a duplicate of this issue. ***

I think this is a real problem for open office that is now four years old.
The problem is it's a real pain in the *ss limitation of this software package.
I encourage everybody to vote for this bug/issue so that we may have it resolved
in a patch for openoffice 2.

Best Regards 
Fyzix

We have the same problem here. It is a frequently needed way of merging cells
and it is a big bug in OOo writer. It should be blocking the release of OOo 2.0.2.

The bug is still present in version 2.0.2. When will this get fixed? Is anybody
even working on getting this fixed?

It would be really great if this gets fixed.

more than 4 years and this problem still exists!
I have the same problem

*** Issue 17955 has been marked as a duplicate of this issue. ***

*** Issue 26266 has been marked as a duplicate of this issue. ***

*** Issue 69792 has been marked as a duplicate of this issue. ***

A long running issue with numerous duplicates and votes. There are even more
duplicates, but many were rolled up into Issue 20193, which did not fix this
problem... (see last few comments)

It has been ~2 years since the assigned developer last commented... should this
be re-assigned? It would be good to at least re-target for 2.X, so that we keep
the Issue on the radar. I'm adding 'ms_interoperability', since this prevents
people importing funky Word tables (I can attach a test doc if really necessary).

Cheers,
Andrew.

.

*** Issue 56560 has been marked as a duplicate of this issue. ***

*** Issue 56560 has been marked as a duplicate of this issue. ***

.

.

*** Issue 60238 has been marked as a duplicate of this issue. ***

First of all, this bug is becoming a bug container for many other tables related
bugs. Most of the "duplicate" issues were serious defects, regardless, this bug
is still classified as an enhancement. It affects all and every OS - however it
is still listed as a Linux issue.<br>Let me tell you, this is the only bug
(table design bug) that prevents me from uninstalling MS Office, recommending OO
to anybody else, considering Linux desktop as a viable choice and most of all it
makes OO incompatible with MS Office. In many cases it results in data loss (old
P2 ) and prevents creating documentation (old P1) with some specific workflow
specifications.<br><br>This is a bloody serious bug.<br>I would recommend to
make it a P2 issue. Please, whoever is responsible, take a careful look at this
issue and make sure it is being taken into serious consideration.

fme->vi: This issue is currently being worked on. It has been added to cws
swnewtable.

I agree there are many issues being marked as duplicates of this one, and they
aren't quite exactly the same problem. This issue really needs to be resolved
for the next release instead of putting it off for so long (over 2 years). 

There doesn't need to be a new "table model" just implement tables as per the
open document spec. I have posted about this at
http://danieldebyl.blogspot.com/2007/01/ooo-doesnt-support-spanning-table-rows.html 

The problem: If you merge a row OOo doesn't use the the
@table:number-rows-spanned on the cell as specified in the Open Document spec
instead it changes the table to contain nested tables. If you only merge columns
then it uses the @table:number-columns-spanned as per the spec. Because of this
the HTML is actually technically correct as the xml of the OOo doc contains
nested tables. However, the borders in the HTML will never line up as they do in
the document which is the problem.

NB: I am posting to this issue as the one I created was marked as a duplicate of
this one, see #60238

fme->debyld: Thank you for your input. As I already said, the issue is currently
being worked on. Please see
http://blogs.sun.com/GullFOSS/entry/too_complex_to_merge%3F for details.

Thanks fme for your response. 

According to the posting on GullFOSS the new table model is to support rowspans,
and if you look at
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=4460&Path=SRC680%2Fswnewtable
it is to be fixed in 2.3.

Please correct me if I am wrong, but if this is the case why hasn't this issue
been marked for the 2.3 release?

fme->debyld: No problem. 

Fixed in CWS swnewtable.

Ready for QA.

Verified fix in CWS swnewtable.

Changed type.

Checked new implementation in SRC680m206 build.

*** Issue 77899 has been marked as a duplicate of this issue. ***

*** Issue 78302 has been marked as a duplicate of this issue. ***

*** Issue 79871 has been marked as a duplicate of this issue. ***

This is not completely fixed in Version 2.3. Vertical merge works for tables
with more than 2 columns. In a table with 2 columns. Merging has the following
effect:
Stepe 1:
----------------
|       |      |
----------------
|       |      |
----------------
|       |      |
----------------

Step 2 (works):

----------------
|       |      |
|       --------
|       |      |
----------------
|       |      |
----------------

Step3: should be 

----------------
|       |      |
|       --------
|       |      |
--------       |
|       |      |
----------------

but: (broken result)

----------------
|       |      |
----------------
|       |      |
----------------

fme->kfen: The second line has a height of 0, therefore it appears as if your
resulting table has only 2 rows. Enter some more text in the first cell and you
will see.

OK. I see your point. The solution may be technically OK. However, from a user
perspective, the actual display is puzzling. I tried the same in FrameMaker,
Word and XMetaL (CALS table model): they all show a different behavior (as
depicted under Step 3 (should be) in my line drawings): Basically line 2 keeps
its height in all these implementations, event though no cell is present - I
prefer this solution. Since the real problem is fixed (and finally allows us to
use OO in technical documentation), I consider this quirk a minor/marginal issue.

How can this issue be "CLOSED"?  Not only does the problem remain in OOo 2.3,
where it was supposed to have been targeted, but still exists in 2.4.  Why
should  this basic design issue - adopting the same basic grid structure, with
rowspan and colspan attributes, as used for tables in every other major
application (not to mention HTML and even ODF file structures!) - still be
unfixed six years after this bug issue was opened?  Even worse, closing #4032
also closes all of the issues that were closed as duplicates of 4032.

Is there any other use issue as important in retarding the adoption of OOo or
forcing users to maintain Word for their technical use?  Is it time to upgrade
the priority from P3 to P2?

fme->jkaufmann: Why do you think this issue is not fixed? Could you please give
a detailed description?

MRU->jkaufmann: for documents which were created with OO 2.2.1 or older, this
will -of course- still not work, because these documents keep the "old" table
structure. Only documents created with OO 2.3 or newer can benefit from the
changes made in the concept.

> 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. ;-) 

ama->jkaufmann:
That you for your input!
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.

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.
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.

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.

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...
+----------+------------+--------+
| A1       | A2         | A3     |
+--------+-+----------+-+--------+
| B1     | B2         | B3       |
+--------+-+-+------+-+-+--------+
| C1         | C2   | C3         |
+--------+-+-+------+---+--------+
This would be yours...
+----------+------------+--------+
| A1       | A3         | A7     |
+--------+-+----------+-+--------+
| B1     | B2         | B6       |
+--------+-+-+------+-+-+--------+
| C1         | C4   | C5         |
+--------+-+-+------+---+--------+
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.
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.

Conclusion:
This issue (i4032) should not be reopened, it is fixed.
You found a new (small) bug in cursor travelling.
You propose to change the row heights when cells are merged.
You propose to change the naming convention of cells.

kfen->ama&jkaufmann
I think jkaufmann has a valid point with his reference to an underlying grid
structure. Our background is in structured (XML) publishing, and the table
models there (XHTML or CALS) are based on a grid structure.
A table like the example from ama (repeated here) can only be interpreted on
a 7-column base:
+----------+------------+--------+
| A1       | A3         | A7     |
+--------+-+----------+-+--------+
| B1     | B2         | B6       |
+--------+-+-+------+-+-+--------+
| C1         | C4   | C5         |
+--------+-+-+------+---+--------+
The advantage (at least for our purposes) is that merging cells can
be reversed in such a way that we can return to the underlying grid
structure. With the oo table model this seems not to work in all cases
for horizontal splits. Do the following:
     ----------------
     | A1 | B1 | C1 |
     ----------------
     | A2 | B2 | C2 |
     ----------------
     | A3 | B3 | C3 |
     ----------------
Merge a1:b1, change width of col A (result after that step)
     ----------------
     |  A1:B1  | C1 |
     ----------------
     |A2|  B2  | C2 |
     ----------------
     |A3|  B3  | C3 |
     ----------------
Split a1:b1 again, result after that step
     ----------------
     | A1 | B1 | C1 |
     ----------------
     |A2|  B2  | C2 |
     ----------------
     |A3|  B3  | C3 |
     ----------------
Cell A1 is now out of sync with the column to which it
should belong. I have not found a way to achieve this
effect without splitting and merging. There is also no
easy way of getting the columns back in sync (drawing the
cell divider until it visually ligns up is not what
I consider an easy way).

To sum up - from my point of view the issue is not 
satisfactory - however, I am not sure whether it is a bug.
Microsoft Word shows exactly the same behavior (which
again doesn't mean that it is OK - in our work we need
a stable, grid-based foundation of table models whith an
inherent integrity of rows and columns).

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.
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.
Summary: the new table model is sufficient but there's another idea to improve
the handling of tables (splitting cells into "unequal" proportions).

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>.

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.

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
(ama@openoffice.org) if they do not fit into this issue.

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".

ama->jkaufmann:
> 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.
It's hard to argue against "almost universal expectations", but I have a
question: which bug report, which behavior do you refer to?
I've checked a lot of duplicates to this issue (4032) but these duplicates are
real duplicates and fixed within our new table model.
Please point me to other issues which you recognized as caused by the table
model. At the moment I'm only aware of these 5 issues I mentioned earlier, which
do not request a change of the table model IMHO.
>  (b) The new table model has moved in the right direction, but has not arrived.
Why? If I interpret you right, you are thinking, that our internal data
structure does not reflect the table structure in an appropriate way. You think
that the column span is not represented well. And you seem to believe that a
other way to reflect the column span will solve any issue? Which one?
> It is sad to see OO, with respect to tables, so far behind
> modern data structure.]
Sorry, but that's a statement but I'm missing any proof, I'm mathematician no
philosopher.
>    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.
Again: which bugs do you mean?
> [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.]
In my view, our old table model was not able to represent some tables with
certain row/column spans. Our new table model solves that problem. Or could me
describe me a table with row/col spans which cannot be achieved with our new model?
> 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.
At the moment I'm aware of the one anomaly you described earlier. I think cursor
traveling in a table with row/col spans is worth a new bug report. There we
could discuss, which movement is unexpected. If we agree on some improvement of
the behavior I will not hesitate to change any code which is necessary. I have
no problem to change any data structure or any algorithm.
> 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".
But that's what I did, for every of your examples I "looked" into our code to
detect if data structure or algorithm or both needs to be changed.
There was no issue which has to be fixed by a change of the data structure.
(1) cursor traveling: Your mentioned anomaly is caused by a row span, so a more
"column spanned" cannot be a solution.
(2) splitting cells: Could be solved by a simple algorithm, no structure change
needed.
(3) splitting cells: Only a string changed, a model change is not needed and
will not be helpful
(4) naming convention: like (2)
(5) merging cells: Like (1), row span causes trouble, a change of column span
representation cannot be a solution for this problem.
>    Once the underlying structure is fixed, those representation anomalies will
> go away.
Which one? Maybe (2) and (4) can be touched by a structure change, but surely a
little bit algorithm change will needed, too.
>   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.
Why?
(1), (3) and (5) are not caused by a missed column-span-model.
(2) is a nice feature, but I just tried another word processor, it behaves like OOo.
(4) I tried another word processor but it does not show the names of the cells
in the status bar, so I could not decide which naming scheme it uses.
>   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".
This issue was about a problem to merge cells. This problem has been solved. The
issue is fixed.
(Implementation detail: to fix this issue, we had to do some changes in the
underlying data structure, the table model.)
If you want to help us to improve our product, you have e.g. the following
opportunities:
- submit issues for improvable behavior (bugs, better behavior, feature, new
options or whatever)
- for features you could help to write a specification
- if you are a software developer you could submit patches or make proposals how
to improve the code

Row synchronization still does not work as expected: 
Take an n x m table (n, m > 3)
Merge all cells in column 2
Add content to cells in columns 3, 4, .... make sure that conten is longer then
cell width and creates new lines.
Result: cells in col 1 are out of sync with cells in columns after merged column.
I will try to attach an example.
My requiremement: lines must stay synchronised - even across merged columns.
Adding line breaks to manually syncronize lines is not an option.

Created attachment 53383 [details]
Row synchronisation problem

mru->kfen: please file a new issue for any problem occuring with tables. Thanks!