Apache OpenOffice (AOO) Bugzilla – Issue 124034
merging cells with move to 1st cell resets format
Last modified: 2014-01-25 07:07:54 UTC
Created attachment 82301 [details] cells to merge In MergB.ods, highlight cells A1:B1, click merge. Popup: 'Should[..]into the first cell?'. Choose Yes. Format (Text size and alignment) has been changed to default --it should not. Indeed, format is preserved when merging A2:B2, in which case there is no popup. May be related to Bug 114357.
Created attachment 82302 [details] cells to merge --updated
Confirmed with AOO410m1(Build:9750) - Rev. 1558424 Rev.1558424 Win 7
I can't see a Bug here, but user error. There is not a reset of format/style or similar. The contents moved to the other cell simply takes the format of the target cell, that seems intended to me. For a test in EnhancedSampleDocument.ods first check styles in Cells A1 and A14, then merge A1:B1 and "A14:B14". As expected the contents of new merged cells takes the format of column A cells. It helps to know some more about merge cell process. As the message box tells, there will not be a real merging of A1 and B1. In fact size of A1 will be increased so that it will cover old cell B1. And if you click [Yes] in Message box, contents of B1 will be transferred to now double width A1. This knowledge also explains why Merging B1:C1 will not show Style "demo" of C1 in new merged cell. After merge new double width B1 simply will cover cell C1 with styles frills. But indeed, Help contents is really poor, I will submit a new bug and add you to CC.
Created attachment 82303 [details] Enhanced Sample Document See comment above how to use.
(In reply to Rainer Bielefeld from comment #3) > I can't see a Bug here, but user error. There is not a reset of format/style > or similar. The contents moved to the other cell simply takes the format of > the target cell, that seems intended to me. Really? It's neither intended nor expected. Copy (^c) cell B1 and paste it (^v) to another cell, say B3 or C3, currently default-formatted: the copy does not 'simply take the format of the target cell'; instead, the B1 format overrides the default format. The same thing happens in Writer: if one pastes a string into an empty paragraph, the string format overrides the empty-paragraph style.
(In reply to TAB from comment #5) (a) Your examples do not match with things happening when you merge cells, so your argumentation is wrong. If you do things completely different it's expected that the result might be different. (b) The message appearing tells that the merge process will hide some cells and that the contents of those cells what will be hidden can be moved into the first cell A1 (in my first example). (c) "Move" from (b) sounds very similar to 'For B1: <control+c> -> click A1 -> <f2> -> control+v - <Enter>', and the result in A1 proceeding so is the same or at least very similar to the result after merge. (d) of course the behavior is unexpected from point of view of an naive approach, and it is reasonable tho think about a function doing things more intuitive, some new feature SMARTMERGE, results some closer to the cell merge function of Writer But that is something different from a bugfix. For that developers would need (e) Theory of all (e1) Real life examples: do really enough people need that? and for what? (e2) What does ODF specifications tell? (e3) Situation with competitors (IMHO Excel 2010 only keeps contents of top left cell ...)? (e4) and so on. If information is available we can rate costs / benefit relation So closing again, we don't have a bug here @TAB: Please feel free to open a separate feature request for your needs.
Created attachment 82327 [details] Demo Kit See comment above!
(In reply to Rainer Bielefeld from comment #7) ***I did not understand your arguments a, b, c until I opened your sample: HowToPredict.ods. Now, I understand that Calc really merges cells while Excel deletes all but one! OK. However, in most cases, the user just wants to make ONE cell larger --spanning several columns or rows, and expects its format to be preserved. To reconcile the merge operation with this usual application, I suggest that the final format be that of the first NON-EMPTY cell --which could be the 1st cell, but not always. In the case of MergB.ods, merging cells A1:B1 would preserbe the format of B1. (d) ...But that is something different from a bugfix. ***OK, don't call it a bugfix. Call it an enhancement. (e) ... do really enough people need that? Even I can live without it. But, the above suggestion should be easy to implement. TY.