Description: When several ranges are copied and pasted in Calc, then these ranges are pasted to one consecutive range. However, when the same selection is pasted from the system clipboard in an editor (or another instance of LibreOffice), then the non-selected cells are pasted as empty cells. The copy to the system clipboard should behave as copy to the internal Calc clipboard, i.e. only copy/include the effectively selected cells and not also the non-selected cells. This bug applies to multi column and row selection, however multi row selection is broken anyway since OOo due to bug 95554. The behavior of multi range copy between copy to internal and to system clipboard is inconsistent. Steps to Reproduce: 1. Open new Calc spreadsheet 2. Write 1 in A1, 2 in B1 and, 3 in C1 3. Select cell A1 and C1 with Ctrl 4. Copy these cells with Ctrl-C 5. Go to cell A3 6. Paste --> In Cells A3:B3 are 1 and 3 7. Open an editor (or another instance of LibreOffice) and create a new document 8. Paste Actual Results: 1<tab><tab>3 Expected Results: 1<tab>3 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.1.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.3; UI render: GL; VCL: kf5 Locale: de-CH (en_US.UTF-8); UI: de-DE Calc: threaded Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 1c1226709c6be39c5462f5e6e1262ca630b30b34 CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Since bug 95554 is already present in OOo, probably this bug is also already present in OOo. I've discovered this issue while fixing bug 95554.
I think the first result "In Cells A3:B3 are 1 and 3" might not be what the user expects, at least not in every case. Maybe I simply want to move 1 and 3 downwards, but keep them in their columns. Then it would not be ok to "trim" the result into two adjacent cells. Though, I agree that there might be cases when "trimming" might be what the user wants. IMHO, "1 <tab> 3" should be the default, while "1 3" could be achieved by using a modifier key or a "special insert" (whatever that might look like").
> I think the first result "In Cells A3:B3 are 1 and 3" might not be what the user expects, at least not in every case. Only copying the selected cells without gaps is the default behavior of Copy/Paste of multi range columns within Calc. I guess copying within Calc is much more widely used than copying to the system clipboard. So, I assume the Calc clipboard behavior is the correct one. This behavior is also reflected in unit tests, see ScUiCalcTest: testTdf117706 in uicalc.cxx. > might not be what the user expects, at least not in every case. I agree with the second part. I think this is an enhancement. I would propose to use a modifier key or a "special insert" in that case. So, you could create a new issue for this change. > IMHO, "1 <tab> 3" should be the default, while "1 3" could be achieved by using a modifier key or a "special insert" (whatever that might look like"). This issue is only about step 8, i.e. copying to system clipboard. I think Calc clipboard and system clipboard should behave consistently in multi range selections.
Out of curiosity, I've checked behavior of Excel. Actual Result of Excel: 1<tab>2<tab>3 Excel copies everything from lowest ("first") to highest ("last) selection to the system clipboard. Regards whether the values are selected or not. Copy/Pasting within Excel The same behavior as after step 6 is present. --> In Cells A3:B3 are 1 and 3
An idea: One possibility to have a consistent behavior between internal and system clipboard could be to paste the the internal clipboard to an empty ClipDocument and then provide this ClipDocument to the system clipboard. This approach would reduce duplication of code and ensure the same behavior. I've not checked the feasibility of this idea in detail in code.
I'm thinking on fixing this issue. However, before programming, I'd like to be sure what the expected behavior should be. Is my expected result correct?
The same happens with data in a row, for instance 1,2,3 in A1:A3. (Me always expected the "skip empty cells" to have this result.) I agree with Larsen in comment 1, it would be more consistent to have the exact same result as in the source. Eike, is there any reason for the current behavior?
> The same happens with data in a row, for instance 1,2,3 in A1:A3. Yeah. This behavior is implemented consistently within LibreOffice. > it would be more consistent to have the exact same result as in the source. I am not in favor of this idea. I think only selected cells should be copied by default. Additionally, I've checked Excel. Excel behaves the same for steps 1-6. Only the selected cells are copied. > Me always expected the "skip empty cells" to have this result. "skip empty cells" is used for excluding copying formats of empty cells or similar. Skipped empty cells are not eliminated from result.
Actually if there are empty cells in the copied range (e.g. A1:A3 and A2 is empty) and "skip empty cells" is enabled, *nothing* will be pasted for an empty cell, not even overwriting existing content in the target range with empty. Anyhow, that's unrelated to the original report. Now for that, when transferring text to external clipboard, multi-selection is not handled at all but only the block it encompasses. If interested, in sc/source/ui/docshell/impex.cxx ScImportExport::Doc2Text(). That could handle a sparse cell distribution by evaluating the ranges of rDoc.GetClipParam() and include only rows or columns that are part of the selection. (In reply to Roland Kurmann from comment #4) > An idea: One possibility to have a consistent behavior between internal and > system clipboard could be to paste the the internal clipboard to an empty > ClipDocument and then provide this ClipDocument to the system clipboard. Something like that already happens. The selection *as is* (i.e. including the sparse but then empty cells as not copied) is copied to a ClipDoc of which the text is exported when transferring to system clipboard. Still, the target determines the format to export and how to handle details, there is no "provide this ClipDocument to the system clipboard" because the system clipboard does not expect some/any kind of document but a specific format/type the target requests.