I don't think that this is a bug. That is our internal representation of a table, and I don't think that we copy an odf file to the clipboard. So all applications supporting x-openoffice-embed-source-xml need to respect our design of this format.

Well, if this indeed not supposed to be an ODF file, then you should 
(a) not include a file named "mimetype" with the content:
application/vnd.oasis.opendocument.spreadsheet
(b) not refer to the ODF namespaces at the beginning of the other files such as styles.xml:
<?xml version="1.0" encoding="UTF-8"?>
<office:document-styles xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo="http://openoffice.org/2004/office" xmlns:ooow="http://openoffice.org/2004/writer" xmlns:oooc="http://openoffice.org/2004/calc" xmlns:dom="http://www.w3.org/2001/xml-events" xmlns:rpt="http://openoffice.org/2005/report" xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:grddl="http://www.w3.org/2003/g/data-view#" xmlns:tableooo="http://openoffice.org/2009/table" xmlns:css3t="http://www.w3.org/TR/css3-text/" office:version="1.2" grddl:transformation="http://docs.oasis-open.org/office/1.2/xslt/odf2rdf.xsl">


It is also quite strange that the file would just give just two error messages when run through an ODF validator:

upload:///mem-dump/META-INF/manifest.xml[2,88]:Error:element "manifest:manifest" is missing "version" attribute
upload:///mem-dump:Info:Generator: null

where the first error message is quite common with LibreOffice generated ODF files.

I wonder if a look into Paste Special is called for.

I assume that there are actually multiple formats that can be obtained from the clip-board for the indicated copy.

I know that an embeddable file source is used, but the question is whether the selection is preserved across the copy-paste into a different document, and whether something other than the full table can be obtained. 

(I assume the copy paste into the same spreadsheet copies two cells as expected.)

The issue may be with the default behavior relative to what the target in the destination document is.

Sometimes, to preserve formulas, it is necessary to embed more table than is shown via the selection.  

It strikes me that there are several variables here and we perhaps need more cases to surface what the usability issue is.

Dennis, what do you mean with "whether something other than the full table can be obtained"? The ODF file that is exported as the 
application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source
(XML)"
target is not the whole table. In the example any _content_ of cell A1 is not exported. A1 in the exported file is empty.

Of course there are other targets but they carry only a subset of the information, ie. typically little of the formatting.

I also do not understand your comment "if a look into Paste Special is called for". I am talking about the targets that are exported to external x clipboard. You can usually run only one instance of LOCalc, so any information exported to the x-clipboard should be destined to an other application. 

I guess we will need to use the html target instead (which of course carries only little information).

@ Andreas
If it is not secret information, please, tell which program pastes clipboard incorrectly

@sasha, the problem is visible when pasting into Gnumeric. We (Gnumeric) could of course be using a different target but those don't seem to contain all formatting info or are not publicly documented. How does LibreOffice know which part of the table to use?

Confirming.

FYI, when pasting between libreoffice we don't go through the x-clipboard but use our own internal clipboard.

Interestingly from gnumeric to libreoffice calc we seem to paste data as html...

I did some tests with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit) and others, several OOo versions, GNUMERIC 1.10.14, MS EXCEL Viewer and MS EXCEL (Starter) 2010)

a) I see the GNUMERIC effect: copy/paste due to report activates selection of a very big range including 2 rows above and 2 columns left of contents, as it seems more or less until right bottom end of GNUMERIC sheet. 
a1) No problem when copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC
a2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010


b) This selection issue is a blemish, but a really bad thing is that a paste of selected 2 cells  range does not hit the expected target. Clicking on C3 in GNUMERIC to paste the contents will create a range as written above in 'a' and put the cell contents into E5:E6
b1) No problem when copy/paste from MS EXCEL (Starter) 2010 to GUNUMERIC
b2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010

c) Another bad effect is that all GNUMERIC contents in range due to 'a' will be deleted (overwritten with empty cell)
c1) No problem when copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC
c2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010

d) It's not only a LibO effect, same with copy/paste from OOo 1.1.4, OOo 3.1.1. to GNUMERIC

e) Copy / paste similar to report from GNUMERIC fails to OOo 3.1.1, LibO 3.5 RC2 with Error message (Translated: Unable to paste clipboard contents)
e2) Also impossible to paste to MS EXCEL (Starter) 2010

Currently I cant exclude that it's also a GNUMERIC problem, but I can't exclude that also LibO's compatibility is not optimum

LibreOffice provides various targets on the clipboard:

------------------------------------------------------------------------------
Clipboard target 0 is text/plain;charset=utf-8
Clipboard target 1 is text/plain;charset=UTF-8
Clipboard target 2 is UTF-8
Clipboard target 3 is UTF8_STRING
Clipboard target 4 is COMPOUND_TEXT
Clipboard target 5 is STRING
Clipboard target 6 is application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
Clipboard target 7 is application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="calc8";viewaspect="1";width="2259";height="451";posx="0";posy="0"
Clipboard target 8 is application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
Clipboard target 9 is application/x-openoffice-emf;windows_formatname="Image EMF"
Clipboard target 10 is application/x-openoffice-wmf;windows_formatname="Image WMF"
Clipboard target 11 is application/x-openoffice-bitmap;windows_formatname="Bitmap"
Clipboard target 12 is PIXMAP
Clipboard target 13 is image/bmp
Clipboard target 14 is text/html
Clipboard target 15 is application/x-openoffice-sylk;windows_formatname="Sylk"
Clipboard target 16 is application/x-openoffice-link;windows_formatname="Link"
Clipboard target 17 is application/x-openoffice-dif;windows_formatname="DIF"
Clipboard target 18 is text/richtext
Clipboard target 19 is application/x-openoffice-editengine;windows_formatname="EditEngineFormat"
Clipboard target 20 is MULTIPLE
------------------------------------------------------------------------------

Copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC does not use the 
application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" target. So any observation with respect to this transfer does not apply to the issue at hand.

Similarly it is unlikely that  copy/paste from LibO to MS EXCEL (Starter) 2010 uses that target.

Of course Gnumeric could easily switch to one of the other targets but it seems that they do not provide all the formatting information that is contained in the application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" target. So switching to a different target would loose more formatting info when copy/paste.

Comment on attachment 50416 [details]
clipboard content

copy/paste picks up previous clipboard content instead of currently selected cell(s)
Also happens in Writer - most recent prior text is copied and inserted instead of currently selcted word/text block

(In reply to comment #14)
> Comment on attachment 50416 [details]
> copy/paste picks up previous clipboard content instead of currently selected
> cell(s)
> Also happens in Writer - most recent prior text is copied and inserted
> instead of currently selcted word/text block

I have observed this on Windows across other applications.  I think this may be some sort of aberration related to how multiple copies (i.e., different selections, not just different clip-board format choices) can be on the clipboard at the same time in later versions of Windows and of Microsoft Office.  Or, for some reason, the second copy to the clipboard just doesn't "take." 

I believe this is a different problem than the subject of the current bug, however.

(In reply to orcmid from comment #15)
> (In reply to comment #14)
> > Comment on attachment 50416 [details]
> > copy/paste picks up previous clipboard content instead of currently selected
> > cell(s)
> > Also happens in Writer - most recent prior text is copied and inserted
> > instead of currently selcted word/text block
> 
> I have observed this on Windows across other applications.  I think this may
> be some sort of aberration related to how multiple copies (i.e., different
> selections, not just different clip-board format choices) can be on the
> clipboard at the same time in later versions of Windows and of Microsoft
> Office.  Or, for some reason, the second copy to the clipboard just doesn't
> "take." 
> 
> I believe this is a different problem than the subject of the current bug,
> however.

That's right, it has been reported in bug 148647. But interesting to see that it already was an issue back in 2014!

Regarding this bug, last relevant comment was from 2012. I just tested pasting from OOo 3.3 and LO 7.5.0.3 to Gnumeric 1.12.46 and it works as expected. Maybe Gnumeric is now using a different clipboard target by default? Cell and text formatting (cell background, bold and italic, partial text colour) has come across to Gnumeric in my test too.

Marking as "works for me" but please feel free to chime in with update information. Would be good to know what changed on Gnumeric's side.

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: c21113d003cd3efa8c53188764377a8272d9d6de
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded