Merged cells are known to cause trouble - see bug list (and believe me I had quite some trouble). So it is desirable to "undo" all or some of the mergers and splits done in a table. I suggest a functionality that splits currently merged cells and brings back the covered cells. My suggestion imho is quite in line with what Calc does or refrains from doing. (Calc split is not capable of creating new lines or columns as done in Writer!) And here is my suggestion: Writer / Table / Split Cells is invoked with either a selection of cells or the cursor simply located in a cell. If any of the selected (or pointed to) cell(s) is merged then the only function available should be to remove the merge i. e. to bring back the covered cells to the visible surface. This is not really an undo operation since the contents can not be brought back to a so far covered cell. I request that no numeric input be requested into how many cells to split - it should be derived from the number of covered cells. I also request that no direction info be requested (horizontal or vertical) since the coverage of a merged cell is internally known. I also request that the uncovered cells get width according to the applicable column width. If no selected (or pointed to) cell is merged then and only then the currently available command functions should be available. Pro: When creating a document I can strive for simplicity and clearness and avoid problems. I can correct misconfigurations I made in a straight forward way. The internal grid is made visible. More consistency with calc is created i.e. less explanations have to be given. Existing functionality is still available. Manual could be complemented but is not made incorrect. No change to the document structure is required. Contra: In the following situation a small discomfort is arising for the user. If there is a merged cell spanning two horizontally neighbouring cells and I decide I would rather like to see it split in three subcells I could do so in a single step now - cursor located in (merged) cell, Table / Split Cells / vertical 3. With my suggestion implemented the user has to do two steps in sequence - Cursor located in (merged) cell, Table / Split Cells then select the two cells and Table / Split Cells / vertical 3.
Hi Heinrich, If I create a table, I can split any of the cells and the undo the action. Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
Hi Xcisco, my wording is bad. UNDO is somewhat ambigous. With the UNDO function I can step backwards on my chain of recent transformations. This functionality is fine but it is no help when the merging is not on my list of recent actions. My request was for a functionality that can revert merged cells to the unmerged status irrespective of when in the past the merger was done, e. g. in an editing session long before.
"since the coverage of a merged cell is internally known" This is not true. It is not possible to do what you request. The operations are lossy, not lossless. Consider that you could completely redesign your table by various splits and merges. No algorithm could know, what the user wants with such an "Undo merge" feature in each case. Closing as WONTFIX.
Hi Buovjaga, your last comment says, that the assumption "the coverage of a merged cell is internally known" is not true. And therefore you decided to set "WontFIx". I am prepared to demonstrate that the assumption is true. I suggest you supply a testcase with a table that has merged cells. I will dissect that document i.e. extract the xml inside the .ods file I will write pseudo code that elaborates the coverage I will attach my results to this bug I ask you to have look on what I will have found and to reconsider setting "New".
Created attachment 148389 [details] Writer table with merged cells Ok, try to undo this merge.
Created attachment 148410 [details] Detailled Report of activities to modify mergedcells.odt to mergedcells3.odt I upload Bug101123_Report1.odt that includes in much detail what I found when dissecting the archive mergedcells.odt (148389: Writer table with merged cells) and how i wanted to change content.xml.
Created attachment 148411 [details] mergedcells3.odt is document mergedcells.odt with merging undone The "corrected" archive mergedcells3.odt is the same document as mergedcells.odt where undoing the merge of cells is done manually by editing content.xml. Unfortunately it is not perfect. When opening with writer please allow writer to correct things in the document. I am glad that then you get to see the desired result. The table cells are regenerated.
I like the idea of a 1-click unmerge. Unmerge could be done by split, but that opens a dialog and the user needs to control the settings. I would not mix such feature with the current split, but use a separate command. There is no principle problem to get the cells. The merged cell contains the information, how many rows and columns it spans. A problem is, which width and height to use for the now visible cells, especially if above/below or left/right have different settings. Another problem is, which style to use. In Writer the style information is not kept, but the covered cells are totally empty. That is different from Calc, where a covered cell can keep its style information. At least using the settings from the associated template would be possible or the styles from column and row default, if such exists.
(In reply to Heinrich Hartl from comment #6) > Created attachment 148410 [details] > Detailled Report of activities to modify mergedcells.odt to mergedcells3.odt > > > I upload Bug101123_Report1.odt that includes in much detail what I found > when dissecting the archive mergedcells.odt (148389: Writer table with > merged cells) and how i wanted to change content.xml. We see here the problem I mentioned in my comment 3: the merging operation is lossy. The original table *had 6 rows*. Thus, your unmerge was not successful. Let's ask UX team anyway, if a "simple unmerge" would be desirable (ie. "The Rows You See Are What You Get" -type of thing).
Summarizing, the request is to split merged cells. It's not about undoing the merge. (In reply to Regina Henschel from comment #8) > The merged cell contains the information, how many rows and columns it spans. Could you please elaborate this? Let's say I start with a table with 6 columns and merge a) 3 and 3 first and subsequently the 2 or b) all 6 at once. How is the original table layout stored? If there is no clear information about the previous table layout I would not implement a single-click-split function. Not even talking about the previous formatting/style.
The argument "merge is lossy" is correct but what is lost? Visibility of covered cells and implicitely editing of covered cells. Merging may delete fully covered rows. The contents of the covered cells is moved/appended to the topmost left cell that remains visible. The width of the covered cells is not lost but is preserved in the column width. Special settings for cell borders are lost. I try to go through this list to discuss reverting merge / unmerge. Unmerge can re-establish visibility and width of covered cells and thus also re-enable editing of cell properties for those cells. Implicitely deleted rows can be recreated by insert row. Contents can be moved to the now visible cells. Special border settings can be set. A very reasonable border setting can be derived from the border setting of the topmost left cell. To summarize: most important - full editing capability is re-enabled by unmerge/split. Loss by merge that cannot be recovered is confined to empty cells and decoration.
Created attachment 148517 [details] Example with merged cells and explanation (In reply to Heiko Tietze from comment #10) > Summarizing, the request is to split merged cells. It's not about undoing > the merge. Indeed it is not about "undo", because the previous content of the now covered cell cannot be reconstructed. The request is to restore the previous table structure. > > (In reply to Regina Henschel from comment #8) > > The merged cell contains the information, how many rows and columns it spans. > Could you please elaborate this? Let's say I start with a table with 6 > columns and merge a) 3 and 3 first and subsequently the 2 or b) all 6 at > once. How is the original table layout stored? If you start with a 6col,2row table and then merge A1,B1,C1 and merge D1,E1,F1 and after that merge the two merged cells, you get the same as merging A1,B1,C1,D1,E1,F1 immediately. The attached file contains an example, how the file source looks for merged cells. > > If there is no clear information about the previous table layout I would not > implement a single-click-split function. Not even talking about the previous > formatting/style. The file format is clear about the structure. I see a need for such feature, because it cannot be done via API. At least I have not found it. But the file source has this information, thus I conclude, that the information is available in core. And then it should be used.
(In reply to Regina Henschel from comment #12) > If you start with a 6col,2row table and then merge A1,B1,C1 and merge > D1,E1,F1 and after that merge the two merged cells, you get the same as > merging A1,B1,C1,D1,E1,F1 immediately. How do you and Heinrich expect the unmerge command to work on the resulting 1 col x 1 row table?
You can only use information, which is available. So an "unmerge" would result in 6 cells.
(In reply to Regina Henschel from comment #14) > You can only use information, which is available. So an "unmerge" would > result in 6 cells. And why not in 8 or 20? Do I know the original layout? And given there are more than one split operations, which one is to take - if the "original" layout is stored somehow?
Hallo Heiko, I could imagine that "unmerge" is invoked with either cells selected (may be entire table or a single eventually merged cell or whatever subset of the table) or with the cursor in a cell. That case should be treated same as if that cell was selected. The command given by "unmerge" then would be to recreate i.e. make visible all the covered cells in the selected domain. There is no ambiguity. In all the examples I dissected columns were never deleted by merge. So I can answer why not 20 cells - there are 6 columns! Even if columns were deleted above definition of the command semantic is clear. Recreate an eventually lost entire (empty) column can be done by insert column analogous to insert row. So it is not about undoing respective recreating what may have existed before but to make visible the row/column structure and make sure that in some selected range there is no merged cell nor a covered cell thus re-exposing all parts to standard editing. To raise a valid argument about what might be possible or not I suggest to raise it with an example. Dissecting may in many cases provide a clear answer!
(In reply to Regina Henschel from comment #12) > Created attachment 148517 [details] > Example with merged cells and explanation Sorry, missed that. Your example requires the spawn info, doesn't it? <table:table-cell table:number-rows-spanned="2" table:number-columns-spanned="2"><text:p>A1</text:p></table:table-cell> (In reply to Heinrich Hartl from comment #16) > In all the examples I dissected columns were never deleted by merge. What was this originally? <office:body> <table:table table:name="Table1" table:style-name="Table1"> <table:table-column table:style-name="Table1.A"/> <table:table-row> <table:table-cell table:style-name="Table1.A1" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> </table:table-cell> </table:table-row> </table:table> <text:p text:style-name="Standard"/> </office:text> </office:body> (4x4 table, cols 1+2 and 3+4 merged then 1+2 merged, saved as fodg)
To conclude, on a cell level the merge action can be reverted while there is no info about the previous layout if full rows/cols got merged into one. Nevertheless we could implement a command that clears the "spawn" property from tables - and is just disabled if there isn't any.
Hallo Heiko, I do not understand what "spawn" property means. May I ask you to help me with some explanation. Searching bugzilla for spawn was not yielding helpful info.
(In reply to Heinrich Hartl from comment #19) > I do not understand what "spawn" property means. The merged cells get internally a "spawn" property. If you open Regina's example and look into the file (rename to zip, open content.xml) you find the actual odf content somewhere at the bottom. In a nutshell: spawn = merge (in my sloppy comments here).