Apache OpenOffice (AOO) Bugzilla – Issue 56560
In a table, after several cell-merge and cell-split, using cell-merge distorts row alignment
Last modified: 2013-08-07 14:38:26 UTC
This is a serious table handling bug. I almost had to moved back to MS Word. Reproduction: 1.Create 4x4 (or any other) table; 2.Select whole last (or any other) column - right click - cell – merge; 3.Right click the same last column (which is now one cell)- cell - split to 4 rows; 4.Select two top cells of the same column - right click - cell – merge; What the heck is going on? The merged cell lost all its alignment to the rest of the rows of the table and moved to the bottom! This is the bug. Affected use cases: 1.Invoices! I use a table with date, project, description and rate columns. I usually add one or two rows per day. Sometimes I work on several projects that have different rates so I have to merge and split and merge again the rate column. Too bad I can't do that on OOo 2 without wasting my PRODUCTIVITY yet. 2. Documents using tables with merged/split cells where the table row integrity is important. 3. Any other intermediate/advanced table usage. How it should be: I am sorry to say, but please repeat the “reproduction†procedure on MS Word and compare.
Created attachment 30784 [details] Illustration of the cell merging/splitting problem
It's neither a P1 nor a P2. -> P3. ES->MRU: Complex tables? Can we do something against the fact that merged cells which have been reset back to splitted cells won't be considered as "untouched" cells?
VI-->ES: It is not just being "considered as ""untouched"" " issue. The solution is to make tables in OO more conscious of themselves, so to speak, by improving the usage of a "rowspan" variables and/or introducing several new variables that (only in some specific cases) keep track of which rows of the rest of the table the cells that are being split/merged are spanning. In short, a more "conscious" relation between the cells that are, or were split/merged and the rest of the table must somehow be established. By no means it is easy to find an elegant solution but it MUST be done. I could possibly help with the logic of it. Putting it down to P3 is not so good for OO success, I think. It is P1 to me, however I would only agree that at least P2 is accurate.
MRU->FME: merging - splitting - merging as described in the bugdoc does not lead to the expected result. The known problems, that a table remains "complex" after a merged cell is "re-splitted" leads to that behaviour.
*** Issue 62818 has been marked as a duplicate of this issue. ***
The example provided in Issue 62818 is better (motre detailed, and shows some more cases). Developers may please have a look.
Maybe you are already aware of this aspect of this bug: table merging and splitting followed by add, delete or resize column produces incorrect column alignment. after merging three 3-col tables, add, delete, or resizing the first column does not work correctly and extra columns may even be created, but not for the whole table. I can attach another sample doc, but I think I know what the local problem is for this part of the bug. It looks like the ID of a column is carried over from the old ( i.e. partial) pre-merge table. When you add,delete or resize the columns (after merging) visually you are addressing the first column, but the table thinks that column is say #3 for the first n rows and #6 for the last rows. In other words, the visual definition does not match the underlying definition, which is what one developer may have been saying above. HTH
I've been downloading every single development release since i first filed this bug in hope to find it fixed (over one year already). This is the only bug that holds me back from advising anybody else to use OO. This is the only bug preventing me from uninstalling MS office (i don't really care about occasional recoverable crashes). This bug makes MS office incompatible with OO. * Another example is (I do not want to file it a s a separate bug as it is probably considered a "feature" and closely related to this bug) 1. Create a 4x4 (or any other similar) table 2. Select 3 bottom cells of the first row and merge them 3. Select 3 top cells of the second row and merge (or at least try to) them What the ... is going on? * As I said before every table should have underlying "grid" (like a spreadsheet) which should never get "compromised" by any merging or splitting. Jesus Christ, the "grid" in this case is just (4,4). If i split horizontally any of the top cells of the aforementioned table in 10 cells let us say then the grid becomes (4,13) (of course every other cell of the top row gets "recalculated" to span 10 grid cells).And so on. Not a rocket science to sort it out. * A new feature related to this functionality for any table would be: Table (menu) -> Export to Calc Should be not too difficult to implement if the basics are done correctly. In other words the splitting, merging and general table-ing in Writer should be essentially the same as in Calc. Shell we make it a priority 2 bug? I would.
fme->vi: The bad news is that I have to close this issue. The good news is that there is a duplicate of it (i4032), and there is even better news for you: We are currently working on it, see http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=4460&Path=SRC680%2Fswnewtable and http://wiki.services.openoffice.org/wiki/Writer_New_Tables *** This issue has been marked as a duplicate of 4032 ***
.