To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=61220
------- Additional comments from [EMAIL PROTECTED] Sun Jan 29 23:44:18 -0800 2006 ------- 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 alignment. 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! --------------------------------------------------------------------- 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]
