GNOME Bugzilla – Bug 564166
Copying a tabular area just moves text to the clipboard
Last modified: 2009-02-11 13:18:34 UTC
Version is 1.9.3 of 20081017 from http://www.gnome.org/~jody/gnumeric/win32/ When an area of mxn cells is highlighted and copied, only the raw data is copied, so it can't be pasted into other applications as a table, as is possible with Excel. Specifically I am trying to paste into an Open Office 3 text document, and I can only paste the data as a table by pasting first into Excel, and then from Excel into Open Office Writer. Is it planned to be able to paste as tables?
It is supported in several formats. The open question is what formats OOo Writer recognizes.
I have tried paste special into Excel, after copying from my table in Gnumeric. When I do this, Excel 2000 opens a window which gives the choices of "Unicode Text" or "Text" Neither of these carries the table information, and Excel just accepts either of these as space delimited text and makes a new table without any of the Gnumeric formatting. When I paste into SeaMonkey Composer I have the choices of paste or paste without formatting. The "paste without formatting" looks ok, but doesn't create a table (as pasting from Excel does). The paste option creates a full screen of Chinese looking characters. When I chose "paste special" with Open Office Writer only the choice "Unformatted Text" appears, with the source listed as unknown. If I do the same with the same rows and columns copied from Excel, the Source is listed as Sheet1!R1C10:R41C16, and there are possible selections of: GDI metafile HTML format HTML format without comments Unformatted text Formatted text (RTF) Microsoft Excel Worksheet DDE link The "Formatted text (RTF)" and "Microsoft Excel Worksheet" options both give table views of the source data. I have also tried the windows clipboard viewer (C:\WINNT\system32\clipbrd.exe) which instantly displays the data from a copy operation. This does not seem to maintain any detailed formatting information from Excel (the Excel and Gnumeric views look just the same.) So it seems to me that this Windows version of Gnumeric is not keeping the information needed for a fully characterized paste operation.
Copying data from Gnumeric clearly provides many formats many of them preserving the table format. This really seems like an openoffice bug not to recognize those formats.
This is known to work on Linux, but obviously not in Windows. Underlying clipboard mechanisms are very different on those platforms, so it isn't surprising that there are problems here. It's probably a question of guessing the right format name. On Unix, we use mime types. I don't see a direct way to tell what name the other applications are expecting, but we can see what they offer when we try to paste from them. Could the next person to make a build for Windows change the #if 0 at gui-clipboard.c l. 436 to #if 1? A user could then mark a table in firefox, excel or openoffice, and paste it into gnumeric. If gnumeric is started from a command line window, a list of formats would then be printed to the command line window. I would like to see: - What format names are printed when pasting a table from firefox? - What format names are printed when pasting a table from openoffice writer? - What format names are printed when pasting a cell range from excel? - What format names are printed when pasting a cell range from openoffice calc?
Debug code is in. set GNM_DEBUG=clipboard to activate.
The debug build is up. I'll try to install on a box with MS office after the 17th.
I tested with gnumeric-1.9.4-20090205-debug.exe and the following grid: "A1" "B1" "C1" "A2" "B2" "C2" "A3" "B3" "C3" --Copying in Gnumeric-- ** Message: clipboard target=UTF8_STRING ** Message: clipboard text of 26 bytes --Copying from OpenOffice.org Calc 3.0.1-- Clipboard target 0 is UTF8_STRING Clipboard target 1 is DataObject Clipboard target 2 is Star Embed Source (XML) Clipboard target 3 is Star Object Descriptor (XML) Clipboard target 4 is GDIMetaFile Clipboard target 5 is Windows Bitmap Clipboard target 6 is HTML (HyperText Markup Language) Clipboard target 7 is HTML Format Clipboard target 8 is Link Clipboard target 9 is Rich Text Format Clipboard target 10 is Ole Private Data Clipboard target 11 is image/bmp ---> CRASH in libpixbufloader-gdip-bmp.dll --Copying from OpenOffice.org Writer 3.0.1-- Clipboard target 0 is UTF8_STRING Clipboard target 1 is DataObject Clipboard target 2 is Star Embed Source (XML) Clipboard target 3 is Star Object Descriptor (XML) Clipboard target 4 is Rich Text Format Clipboard target 5 is HTML (HyperText Markup Language) Clipboard target 6 is HTML Format Clipboard target 7 is Link Clipboard target 8 is Ole Private Data ---> Text Import Configuration dialog pops up with 9 lines in it --Copying from Excel 2003-- Clipboard target 0 is UTF8_STRING Clipboard target 1 is DataObject Clipboard target 2 is Biff8 Clipboard target 3 is Biff5 Clipboard target 4 is Biff4 Clipboard target 5 is Biff3 Clipboard target 6 is Biff Clipboard target 7 is Wk1 Clipboard target 8 is XML Spreadsheet Clipboard target 9 is HTML Format Clipboard target 10 is Csv Clipboard target 11 is Rich Text Format Clipboard target 12 is Embed Source Clipboard target 13 is Native Clipboard target 14 is OwnerLink Clipboard target 15 is Object Descriptor Clipboard target 16 is Link Source Clipboard target 17 is Link Source Descriptor Clipboard target 18 is Link Clipboard target 19 is ObjectLink Clipboard target 20 is Ole Private Data Clipboard target 21 is image/bmp ---> Cells A1:C3 are pasted correctly --Copying from Firefox 3.0.6 (with a valid XHTML 1.0 Strict file)-- Clipboard target 0 is UTF8_STRING Clipboard target 1 is DataObject Clipboard target 2 is text/html Clipboard target 3 is HTML Format Clipboard target 4 is text/_moz_htmlcontext Clipboard target 5 is text/_moz_htmlinfo Clipboard target 6 is text/x-moz-url-priv Clipboard target 7 is Ole Private Data HTML parser error : htmlParseStartTag: invalid element name ^ HTML parser error : htmlParseStartTag: invalid element name ^ HTML parser error : htmlParseStartTag: invalid element name [repeated] ---> Text Import Configuration dialog pops up with 3 lines in it Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x6b8824e6 in gdip_buffer_to_bitmap (buffer=0x1f35bc8 "BM6\231", size=39222, error=0x22f22c) at io-gdip-utils.c:356 in io-gdip-utils.c (gdb) 356 io-gdip-utils.c: No such file or directory. bt
+ Trace 212303
Excellent. It looks like some of the target atom names are different under Windows. #define OOO_ATOM_NAME "application/x-openoffice;windows_formatname=\"Star Embed Source (XML)\"" --> just "Star Embed Source (XML)" #define HTML_ATOM_NAME "text/html" --> "HTML (HyperText Markup Language)" and "HTML Format".
Created attachment 128105 [details] [review] Patch to try This might fix the input side.
Created attachment 128112 [details] Pasted data
Committed a fix to the html problem in comment #7. Had to make detection of 16 bit unicode without byte order mask more robust.
Created attachment 128148 [details] [review] On Windows, use Windows format names for html, open document. This should do the following - export & import html to windows apps. Unless they insist on 16 bit unicode, that is. - import native openoffice format just as well or poorly as we do on Linux. Adding export to Excel looks easy to do. But how many users have 2 different spreadsheet apps open at the same time?
Created attachment 128157 [details] [review] Missed a few places where "text/html" was used
jk: I thought about doing it that way, but I couldn't convince myself that no windows program would say "text/html", so my patch would accept either version (independent of OS).
Created attachment 128397 [details] [review] Updated patch How about this?
Looks good.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.