Created attachment 185664 [details] Example file that is affected by this bug Using clone format to copy a format to a joined cell cause the changes to be applied only to the leftmost cell of the joined one. I've provided an example calc file to reproduce that reproduce the bug; here is how you can trigger it on it. 1. Click on cell D3 to select it 2. Click on the 'copy format button' 3. Click in the space of the joined cell (B2:E2) 4. The outcome of the action is that the format apply only B2 instead of the entire joined cell (B2:E2)
Created attachment 185665 [details] Visual description of the actions required to reproduce the bug
I think this is not a bug. Try opposite steps: select merged cells B2:E2, set for example yellow background, click 'copy format button', click B17. Format is copied containing merging of cells. So it looks like "merge attribute" is part of cell attributes, ergo copied with 'copy format' button.
(In reply to raal from comment #2) > I think this is not a bug. Try opposite steps: select merged cells B2:E2, > set for example yellow background, click 'copy format button', click B17. > Format is copied containing merging of cells. > So it looks like "merge attribute" is part of cell attributes, ergo copied > with 'copy format' button. The behaviour should be consistent. A joined group of cells should act like a single cell when is the destination of a clone command. The direction matter: the bug is in the clone command working from a specific source to a specific destination, swapping source with destination just to say this is not a bug is bizzarre. I can understand the presence of bugs (software is complex). What I do not understand is the intention to ignore the new signalled ones. In this manner maybe the number of confirmed bugs (the only where there is hope to see a fix in the future) in bugzilla continue to show less bug than the ones experienced by users. What motivate a person to fire a bug report is the willing to help the project to improve.
So, one question here is: Q1: Should "being merged" be considered one of the formatting properties of a cell? * If it should then the clone-formatting also applies the "not merged" property, and see raal's comment #2. * If it should not - then clone-formatting should never merge nor unmerge. Now, even if "being merged" _is_ one of the formatting properties, then we face a second question: Q2: Should the clone-formatting apply to all the separating cells getting unmerged or just to the first? I believe that the answer Q2 is pretty clearly "Apply to all separating cells". I very much doubt any user would want just one unmerged cell to be affected - even if the merging is broken. As for Q1, here my opinion is less well-formed. I tend to see "mergedness" as not an apsect formatting, but a structural aspect, which should not be affected by clone formatting; but I could be convinced otherwise.
Many duplicates all combined at bug 89951. Consider cell A having a format different from cell B, but both set to something. *** This bug has been marked as a duplicate of bug 89951 ***
(In reply to Heiko Tietze from comment #5) > Many duplicates Such as? > all combined at bug 89951. That bug is about how to format the merged cell given the pre-merge cell formats. This bug is not about that; nor would resolving any of the two bugs resolve the other.
I take it this is not a macOS bug then, and as it was deduplicated need UX team input again
(In reply to eisa01 from comment #7) > ... as it was deduplicated need UX team input again Which has been done on bug 89951. But Eyal has for sure an opinion what makes this ticket special...
(In reply to Heiko Tietze from comment #8) > Which has been done on bug 89951. But Eyal has for sure an opinion what > makes this ticket special... Heiko, please read my comment #6 which explains why these are quite distinct issues. So, no, this has not gotten the UX team input. And - yes, I checked the comments on bug 89951 to make sure they don't address this one.
This was discussed in the design meeting this evening, but - not in a satisfactory manner IMHO. Here's what the minutes say: > + merging cells with the keep option does exactly this, we > must not format hidden cells this bug does not regard the merging action, so either this sentence is incorrect or I misunderstand it. > + copying/cloning merged cells takes merge state into account, > however, applying a format via cell style, which is the supposed > workflow does not I'm sorry, that does not make sense. This bug is about "clone formatting". If it takes the merge state into account, the answer to Q1 is affirmative. Now, what about Q2? > + cloning the merged state is a convenience feature I don't understand this sentence. Cloning is a feature in LO calc, and you guys decided it also applies the merged or unmerged state. What does it matter whether cloning is a "convenience feature" or not? Given your position, the obvious decision is for the format to apply to all unmerged cells. I haven't read any argument for the alternative in the minutes. And thus I don't understand why you concluded > => WF/NAB rather than will-fix, is-a-bug.
We discussed the topic in the design meeting. LibreOffice offers the outstanding feature to merge cells in three different ways. Either the content if the cells to merge is collected into the new cell (eg. A1=1, B1=2 => A1 = 12), the cell content is kept hidden (and unmerging is possible), or only the content of the first cell is kept. If you copy a merged cell you expect the merged state to be taken into account. The same is true for clone format that takes the merge state as a formatting attribute and applies it to the target. It's a convenience feature in alignment to the copy function. Cell formatting is preferably done per cell style. The style with all defined attributes will be applied to the merged cells without affecting the state. => NAB
(In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. Please read my last comment. > LibreOffice offers the outstanding feature to merge cells in three different > ways. ... not relevant to this bug. > If you copy a merged cell you expect the merged state to be taken into > account. The same is true for clone format that takes the merge state as a > formatting attribute and applies it to the target. It's a convenience > feature in alignment to the copy function. All features are convenience features. One can always edit an ODF file manually. The use of this term is suspicious. > Cell formatting is preferably done per cell style. Cell formatting is application of style + DF. When you clone-format, you clone the style and the DF. > The style with all > defined attributes will be applied to the merged cells without affecting the > state. (facepalm!) 1. This bug was opened about the fact that clone-formatting _does_ affect the merged state - it breaks up the cells. You're claiming that it doesn't? That's nonsensical. In fact, in the design meeting, the conclusion was that the clone-formatting _should_ affect the merged state. 2. This bug is about cloning DF, not cloning styles. Given that the cells are broken up, the complaint is that the DF is applied to just one of them. 3. No, the style is _not_ applied to all of the cells! Just to the first one. If you change the style of D3 in the reproduction instruction to some other style (e.g. "my_style" with a blue background) - only the first of the broken-up cells will get "my_style" and the blue background; the rest will remain in Default Style.
Merged state is a direct formatting and copied with clone formatting. It is not an attribute of the cell style. => NAB Please don't add UX keyword when a topic has been discussed. It's sufficient to reopen the ticket.
(In reply to Heiko Tietze from comment #13) > Merged state is a direct formatting and copied with clone formatting. It is > not an attribute of the cell style. Ok, that address Q1. But now please address Q2. > Please don't add UX keyword when a topic has been discussed. It's sufficient > to reopen the ticket. Ok.
(In reply to Eyal Rozenberg from comment #14) > Ok, that address Q1. But now please address Q2. It depends on how you merge cells. Assuming you keep the default [1] you keep the content of hidden cells. And we apply the format as done for hidden columns/rows: if the surrounding cells are selected it applies to the hidden too. Select the cell left or right of the merged cells and apply the direct formatting to see the difference. [1] The merge option dialog shows up when the cells contain content. See also https://help.libreoffice.org/latest/en-US/text/scalc/01/05060000.html
(In reply to Heiko Tietze from comment #15) > It depends on how you merge cells. It cannot depend on how the cells were originally merged; because the choices you mention are possible actions, not choices between different kinds of merged-state. The merged state is - AFAIK and correct me if I'm wrong - made up of only the set of cells the current cell is merged into. So, once the cell is merged - LO has no information regarding how the user chose to merge it. It will have some implicit information via whether or not the cells other than the first have any contents. Are you saying that this information is taken into consideration? > we apply the format as done for hidden > columns/rows: if the surrounding cells are selected it applies to the hidden > too. Select the cell left or right of the merged cells and apply the direct > formatting to see the difference. Ah, now that's an interesting point! The minutes did not mention that. Was this discussed? Anyway, here I disagree that this should be the behavior. Why? Because the principle should be taking hints of the user's intent from their action. If clone-formatting is applied to a certain cell, with the cell next to it being hidden - the user has given no indication that they are interested in formatting the adjacent hidden cell. But in the case of selecting a merged cell as the target of clone-formatting, the user _does_ indicate they want that area to be formatted a certain way. Even if we're breaking up the cell - which is not obviously what the user wants, but let's say it's kind of acceptable - we can't go yet another step in countermanding their expressed intent, and only apply formatting to the first of the unmerged cells. > [1] The merge option dialog shows up when the cells contain content. See > also https://help.libreoffice.org/latest/en-US/text/scalc/01/05060000.html This brings up an interesting possibility which we have not discussed. Why does that dialog exist? Because we could not reconcile different and contradictory possible user intents when merging a cell. We (must have) identified at least two common intents, and perhaps added another possibility - and since we couldn't always choose one over the other, we opted for the cumbersome and flow-interrupting behavior of opening up a dialog. Perhaps we need to do the same thing here? If you ask me, I would be willing to assume the intent of not breaking up the cell at all; or of breaking up and formatting all broken up cells - but I absolutely am not willing to accept the assumption of the user wanting to break up the cells and formatting just one of them. That seems to me like the more esoteric use case. But if you or others believe that this is a common intent - we could instead bring up a dialog, and offer several options: * Keep merged cell, apply formatting other than merge state * Break cells up, format all of them * Break cells up, format the first What do you think?
(In reply to Eyal Rozenberg from comment #16) > The merged state is - AFAIK and correct me if I'm wrong... You are wrong. Please read the documentation, try yourself, and follow the comments here again - we provide an exceptional and outstanding feature. (In reply to Eyal Rozenberg from comment #16) > What do you think? (In reply to Heiko Tietze from comment #11) > => NAB
(In reply to Heiko Tietze from comment #17) > (In reply to Eyal Rozenberg from comment #16) > > The merged state is - AFAIK and correct me if I'm wrong... > > You are wrong. Please read the documentation, try yourself, and follow the > comments here again I have, and I have, and I have, and it's all consistent with my assumption. For example, I I merge two cells with "a" and "b" respectively, or one cell with "ab" and an empty cell - with "move the contents to the first cell" - unmerging in both cases results in the first cell having "ab" and the second cell being empty. So the merge state does not seem to include how the merge was performed. > we provide an exceptional and outstanding feature. I'm not sure I understand what you mean by this. > (In reply to Heiko Tietze from comment #11) > > => NAB That's not an option IMNSHO. Users - most or nearly-all of them, I would argue - expect clone-formatting applied to a merged cell to format that entire area. And their expectation is perfectly justified. If they don't get a dialog for selecting the kind of action they want - then it has to be one of the two alternatives: Either format the broken-up cells, overwriting their pre-merge formats (Q1: No Q2: Yes); or don't break up the merged cell (Q1: Yes). The current behavior (Q1: No Q2: No) does absolutely not make sense and interrupts users' work, making them correct this gaffe of a behavior they did not want. If you're worried about the non-first cells' format not being re-applied on unmerge - then you should probably support the Q1-Yes option.