See also bug 4032.

I have assigned this to Andreas Martens & added me to the CC list, assuming that 
this is a problem with the way that OOo deals with tables. Andreas, would you 
please confirm my thoughts?

I am adding the "oooqa" keyword, setting the type to Enhancement from Defect, & 
setting the status to New from Unconfirmed. Please correct me as necessary. 
Should the OS be set to All?

Oops. I forgot to set this to New.

Well, it is definitely a table issue as far as I can see.

Maybe merging cells and unmerging garbles the order of cells in the
internal representation of the table (wild guess).

Regards
Andree

No, there's no bug. If you insert some text into the cells before you
merge them you'll see that the right cells are merged. The problem is
that the merged upper two cells shrinks after the merge and the lowest
cell grows. I'm planning to describe our behaviour and publish it.
Then I will set the status of this bug to "WORKFORME".

Created attachment 8020 [details]
Sample file to illustrate the issue

Hi Andreas

Thanks a lot for looking into this.

I have attached a sample file to demonstrate the behaviour to make
sure that we are talking about the same thing.

Ok, I think the table in the middle shows what you are talking about:
The text gets merged correctly, but the bottom cell changes its size.

The table at the bottom shows the result that I would expect: The two
top cells get merged, both text- and geometry-wise.

So far, so good.

Now my point: I grant you that the text is correctly merged. So that's
cool. But the fact that the bottom cell expands and the top cell
shrinks is absolutely beyond me. Why would anyone expect this behaviour?

Further, if I start with a 'clean' table (as I've done for the below
table), i.e. created from scratch that has not undergone cell merging
and splitting activities, the behaviour is exactly as I would expect
it to be.

This in turn means that when merging cells, the history of table
modifications plays a role, which (at least in the situation at hand)
is plain wrong and leads to the above inconsistency.

Best regards & have a nice weekend
Andree

Hi Andree,
we talk about the same thing. I know what you mean and will describe
our behaviour at the project document page in near future. I know that
the behaviour of our tables is sometimes surprising the user and
sometimes the developers, too ;-)
You wrote the history of a table has influence of its merge behaviour.
That's true and false. Of course the merge algorithm knows nothing
about the history of table. It depends only of the current layout of
the table. The current layout depends of course on the history of the
table. Let me point you to your both tables: the "clean" table and the
merged and splitted table. They looks the same but they are different.
Not only the merge brings this up, if your cursor travels through the
cells please have a look at the lower right corner of the application.
In the status bar you see the names of the cells ("A1", "B1.1.1") and
so on. You'll see that this numbering is different, it reflects the
structure of the tables. Another test: please insert some paragraphs
in the cells of both tables. When the cells starts to grow you'll see
what I mean.
Resume: Our table concept may be "perfect and logical" from the
engineering point of view but unfortunately that doesn't hold for the
user point of view. We've to work on it.
Nice weekend
             Andreas

.

Hi,
While lokking at some table issues, I checked this in 2.3.0 and 680m8.
I can't see the undesired behaviour -> fixed IMO

Yes, you are right. Our new table behavior meets the expectation of the user
more often than our old behavior.
Fixed with CWS swnewtable, integrated in OOo2.3

Closed.

Created attachment 74151