Issue 61220 - Add option, that vertically merged cells in a table do not break up the rows layout
Summary: Add option, that vertically merged cells in a table do not break up the rows ...
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-01-27 05:19 UTC by raindrops
Modified: 2013-02-07 22:34 UTC (History)
1 user (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Sample shows problem and recommended behavior (12.69 KB, application/vnd.oasis.opendocument.text)
2006-01-27 05:20 UTC, raindrops
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description raindrops 2006-01-27 05:19:19 UTC
In a table, if we enter a paragraph, the height of the entire row increases to
accomodate it. However, if any of the cells of this row is merged with a cell
above/below, each row gives up its independent existence, and stops adjusting to
the text entered in any of its cell. 

As a result, rows break up (in othjer words, cells from a given row are no more
aligned horizontally), and the table becomes totally unrecognizable.

Desired: Even if some cells of a row are merged with cells from other rows, the
row should maintain its own identity (and alignment).

This can be done with three different ways:
(a) This can be made the default behavior of all tables.
(b) Make this a selectable table property: "maintain uniform height for the
non-merged cells of rows "
(c) Provide a command to equalize the row height AFTER the row-heights are
disturbed due to difference in the length of text.

Sample document attached.
Comment 1 raindrops 2006-01-27 05:20:35 UTC
Created attachment 33605 [details]
Sample shows problem and recommended behavior
Comment 2 michael.ruess 2006-01-27 09:24:11 UTC
If there are cells merged vertically and text is entered in one cell so that it
grows, it should be possible that rest of the row also grows with this cell. See
attached document.
Comment 3 raindrops 2006-01-30 07:44:18 UTC
Raindrops ->MRU

It is my understanding that a "defect" gets immediate attention, whereas an
"enhancement" will be taken up only when resources permit.

If that IS so, this issue should be classified as a defect (certainly it is not
an enhancement, in the sense of "betterment").

The reason is, the table becomes unmanageable, unusable and meaningless to
readers when some cells are merged. 

And you would agree that merged cells are commonplace in a document (as opposed
to a database, where merging of cells is NOT allowed).

BTW this case also highlights the need to review the current definition of
"defect", which says "does not work as designed" -- Were tables DELIBERATELY
designed to work like this? I don't think so. This is evidently an overlooked
area. Such issues must be treated as DEFECTS; especially if a feature becomes
unusable because of them; and there are no easy workarounds.

For example, we CANNOT drag the borders of these rows downwards to restore the

The ONLY workaround we have is extremely painful:

1. In each row, click in another cell ACROSS the merged cell, and press "Enter"
for the required times to increase the height of that part of the row. (For
example, you may have to press the "Enter" key 10 times in a cell.)

Repeat that for each row.

For a large table, this is a extremely tedious job. (Look at the file I sent.)

2. Even this hard work may NOT give the desired result if the line space and
paragraph space (before/after) are different in different cells. (For example,
one cell may have a bulleted list instead of a running text. The list requires a
different line/paragraph spacing.) 

In that case, the overall height of the other part of the row will be different
by a few POINTS. To eliminate this tiny difference is extremely difficult: It is
purely experimental (trial-and-error) work.

Besides, just for the sake of re-aligning the rows, you have to temper with the
text entered in those cells; thus comproimizing the quality of your document.

3. To add to the woe of the users, this is NOT a one-time operation: The moment
you edit text in any cell (or if you adjust the column's width), the paragraphs
will wrap again; and the height of rows will get disturbed again. You have to
manually adjust all cells' height all over again.

Such a table is like a pack of cards-- A slight movement and it's gone!

Rather than using his precious time in creating a document, a user is forced to
waste time in correcting a formatting issue. The frustrating experience may
affect his creativity in writing the article!

Considering these hardships, this is definitely a DEFECT-- One that should be
tackled in the very next release; P3 or not!!

>> If *I* entered this issue as an enhancement, it's a mistake on my part; and I
stand corrected!