Description: When copy/pasting row(s) from an LO spreadsheet into another spreadsheet application, such as Google Docs or gnumeric, initial columns are omitted if they are entirely empty. This problem does not occur if a subset of columns is copied instead of entire rows. Comment: Most likely the bug relates to handling the X11 copy/paste/clipboard protocol which I gather is a bit of a monster. Getting this right is important for interoperability with Google Docs. Steps to Reproduce: 1. Start gnumeric (alternatively, create a Google Docs spreadsheet in a browser). 2. (in another terminal) Open the attached test.ods in LibreOffice 3. Click in the Row border to select all of Row 1 in LO; Control-C to copy 4. Place cursor in any cell in gnumeric or the Google spreadsheet; control-V to paste. Actual Results: The empty cell A1 in the LO spreadsheet is not copied; the data starting with B1 are pasted into the other spreadsheet. Expected Results: Empty cells should be preserved when copy-pasting rows. Reproducible: Always User Profile Reset: No Additional Info: Also try copy-pasting Rows 1 & 2 or all 3 rows together; when copying Rows 1 & 2 are copied column A is not copied (A1 and A2 are empty). But if all three rows are copied, then nothing is lost, apparently becuase A3 is not empty.
Created attachment 170159 [details] test.ods (see Steps to Reproduce)
The same problem occurs when copying between Libre Office spreadsheets if the spreadsheets are operated by different processes. For example, if one is running on LibreOfficeDev and the other is an old production build (3.6.7.2 in my test).
Another symptom is that formats are not encoded correctly when entire rows are copied. For example, a "Text" cell containing "(415)" will copy correctly into Google Docs if a subset of cells is copy-pasted; but if the entire row is pasted, it comes in a -415, i.e. a negative number. In my test, the receiving cell has "Text" format in Google Docs so this should not happen, so possibly LO is (wrongly) marking the cell explicitly as numeric when copying entire rows. Also: If a subset of cells in a row are selected and then copy-pasted, there is no bug. Then, if the previously-unselected cells are added to the selection using Control-click, then another copy-paste is done, the problem re-appears. Therefore it looks like "entire rowness" is triggering the problem, or making LO encode the copied cells differently than if only some cells are copied.
I can confirm the bug in comment 1. I've tested with to two Calc processes. First empty cells are omitted. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: f1512321581e0e605582018395ab91f04a2da8fe CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I'm not sure about comment 3. Maybe, these are other issues and should be described in separate Bugzilla issues.
Things are different for Google Sheets and Gnumeric. Google Sheets (or the browser) requests text/html and text/rtf flavour exports (whatever it may use later when actually pasting). For these we do not export empty leading (and obviously trailing neither) empty columns or rows of the selection. And I'd rather not change that. For the "(415)" to -415 that's a Google thing to interpret data (there are no data types in the HTML output) and at least in an en-US locale parentheses may indicate negative values, same in Calc. And I can't confirm that it would be different for a single cell being copy-pasted. It may be different in other locales. Gnumeric requests an ODF text/xml from the clipboard, that writes the internal clipboard document as if saved as ODF, whatever Gnumeric does with the result it skips leading empty rows and columns and pastes starting from content to the current cell cursor position. Which makes sense, see below. Similar happens when copying between different LO Calc processes, though with a application/x-openoffice-embed-source-xml flavour as known internal format (which in fact is ODF as well). For that I can tell it is on purpose, probably similar in Gnumeric, or rather inevitable as the data read has no indication what the original selection of the other application was, so data is pasted from the first data start in the resulting clipboard import with the encompassing data area. There isn't much we can do, except for the ODF format add a format extension to store the last selection as well and use that when pasting, but I'm not convinced that is a good idea. For example, using Ctrl+A and copy you certainly do not want the target to be entirely cleared except the few pasted content cells. Nor would things work the same if the current cell cursor position was not in the first column/row. So some magic when and how to evaluate that would be required anyway, making things more complicate to understand for people. It's more straight forward and consistent to always paste starting with data content to the current cell cursor position. I tend to close this as won't fix.