Created attachment 50416 [details] clipboard content new spreadsheet, enter c3 in C3 enter c4 in C4 select C3:C4 copy LOCalc places an ODF file on the clipboard as target application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" That ODF file does not just contain a table with 2 cells but a table with 3 columns and 4 rows, misleading other programs into pasting a larger area (should they decide to use the ODF file).
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).
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I will not waste my time with checking whether this is still true in some recent unreleased version. I filed this report as a service to the LibreOffice user community. I am of course _not_ using LO myself. So if you don't care about these bugs, feel free to close this report.
@ 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?
Thanks for information. And let ask experts. @ experts Please, look on it bug
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.