GNOME Bugzilla – Bug 523554
Copy from GIMP to Word broken
Last modified: 2009-01-11 14:02:47 UTC
On windows xp, when copying from Gimp, pasting in nearly all programs including Powerpoint or Xnview works. However Word 2003 does not recognize the clipboard content Gimp 2.4.5 puts there. When the Gimp image is pasted into xnview and the copied to word, everything is fine. Even though the problem might be partially with Microsoft, why does Xnview work and Gimp not? Please fix the bug (or problem), since this degrades the value of Gimp for Windows users. Othmar Marti
Please use tools/test-clipboard from the GIMP source tree to find out what formats GIMP offers. Then do the same with xnview. This should shed some light on it.
(In reply to comment #1) > Please use tools/test-clipboard from the GIMP source tree to find out what > formats GIMP offers. Then do the same with xnview. This should shed some light > on it. > Dear Sven, I found the mentionned c-source file. I have no compiler on my computer. Would it be possible to provide a file version gimp.exe compiled with that library? Otherwise I fear that I am not able to help. Othmar
Created attachment 107776 [details] clipboard.c Actually, more useful (I think) than the test-clipboard program which only displays the GTK+ view of what is available on the clipboard is a program that displays that from the pure Win32 point of view. The attachment is the source code of such a program.
Created attachment 107777 [details] clipboard.exe And this is the executable. Run like this: clipboard -l and it will print a list of the formats of data available on the Windows clipboard: C:\>clipboard -l 1: CF_TEXT 16: CF_LOCALE 7: CF_OEMTEXT 13: CF_UNICODETEXT
Created attachment 107851 [details] Screenshot of Word when copying from Gimp
I have copied from Gimp to Word. Clipboard gives the output 49637: image/bmp 8: CF_DIB 50006: image/x-bmp 50007: image/x-MS-bmp 49636: image/png 50008: image/x-icon 50009: image/x-ico 49634: image/tiff 49633: image/jpeg 2: CF_BITMAP 17: CF_DIBV5 When copying this to XNVIEW and then copying to Word, the clipboard is 8: CF_DIB 2: CF_BITMAP 17: CF_DIBV5 The difference I see is the order of the items. This puzzles word, maybe. I have attached a screenshot from Word, using the office clipboard view. I first copied from Gimp (the second item): Word says "Vorschau nicht verfügbar" (preview not available), so it probably cannot interpret the type image/bmp. Then I did the copy from XNVIEW (first item). This works. As I said in my initial posting, the culprit is probably Word, but we have an imperfect world.. Thanks Othmar Marti (In reply to comment #4) > Created an attachment (id=107777) [edit] > clipboard.exe > > And this is the executable. Run like this: clipboard -l and it will print a > list of the formats of data available on the Windows clipboard: > > C:\>clipboard -l > 1: CF_TEXT > 16: CF_LOCALE > 7: CF_OEMTEXT > 13: CF_UNICODETEXT >
I don't think the order the clipboard formats are listed matters. Just to make it sure, these outputs are after you have done the copy operation in GIMP or xnview, but before you have pasted into Word, right? It's a bit odd that you can't paste from GIMP but can from xnview then, as the list of formats offered by xnview looks to me like a pure subset of the ones listed by GIMP. I can't paste into Word 2007 after doing a copy in GIMP, either. I can paste into MS Paint, though. If I then do a Select All and Copy in MS Paint, clipboard -l lists the formats: > clipboard -l 49161: DataObject 49163: Embed Source 49156: Native 49155: OwnerLink 49166: Object Descriptor 3: CF_METAFILEPICT 8: CF_DIB 49171: Ole Private Data 14: CF_ENHMETAFILE 2: CF_BITMAP 17: CF_DIBV5 Pasteing into Word 2007 from MS Paint works fine. My guess would be that Word uses the CF_METAFILEPICT or CF_ENHMETAFILE formats?
(In reply to comment #7) I have done the clipboard list before pasting into word 2003. However, word 2003 does not change the clipboard. Clipboard.exe -l shows exactly the same items before or after. Since copying from XNVIEW works, word must honor CF_DIB, CF_DIBV5 or CF_Bitmap Corel Photopaint 7.0 produces 49161: DataObject 49163: Embed Source 49156: Native 49155: OwnerLink 49166: Object Descriptor 3: CF_METAFILEPICT 50218: CorelPhotoPaint.Image.7 8: CF_DIB 49171: Ole Private Data 14: CF_ENHMETAFILE 2: CF_BITMAP 17: CF_DIBV5 This works Corel Photopaint 12 gives 49161: DataObject 49163: Embed Source 49156: Native 49155: OwnerLink 49166: Object Descriptor 3: CF_METAFILEPICT 50250: CorelPhotoPaint.Image.12 50254: CorelPhotoPaint.Image.9 8: CF_DIB 49171: Ole Private Data 14: CF_ENHMETAFILE 2: CF_BITMAP 17: CF_DIBV5 Works too MyAlbum 2.5.5 8: CF_DIB 2: CF_BITMAP 17: CF_DIBV5 This works (same as XNVIEW) These are all the programs I have Othmar
(In reply to comment #7) I have done the clipboard list before pasting into word 2003. However, word 2003 does not change the clipboard. Clipboard.exe -l shows exactly the same items before or after. Since copying from XNVIEW works, word must honor CF_DIB, CF_DIBV5 or CF_Bitmap Corel Photopaint 7.0 produces 49161: DataObject 49163: Embed Source 49156: Native 49155: OwnerLink 49166: Object Descriptor 3: CF_METAFILEPICT 50218: CorelPhotoPaint.Image.7 8: CF_DIB 49171: Ole Private Data 14: CF_ENHMETAFILE 2: CF_BITMAP 17: CF_DIBV5 This works Corel Photopaint 12 gives 49161: DataObject 49163: Embed Source 49156: Native 49155: OwnerLink 49166: Object Descriptor 3: CF_METAFILEPICT 50250: CorelPhotoPaint.Image.12 50254: CorelPhotoPaint.Image.9 8: CF_DIB 49171: Ole Private Data 14: CF_ENHMETAFILE 2: CF_BITMAP 17: CF_DIBV5 Works too MyAlbum 2.5.5 8: CF_DIB 2: CF_BITMAP 17: CF_DIBV5 This works (same as XNVIEW) Firefox 2.0.0.12 49161: DataObject 50191: application/x-moz-nativeimage 8: CF_DIB 49171: Ole Private Data 2: CF_BITMAP 17: CF_DIBV5 This works These are all the programs I have Othmar (In reply to comment #8) > (In reply to comment #7) > > I have done the clipboard list before pasting into word 2003. However, word > 2003 does not change the clipboard. Clipboard.exe -l shows exactly the same > items before or after. Since copying from XNVIEW works, word must honor CF_DIB, > CF_DIBV5 or CF_Bitmap > > Corel Photopaint 7.0 produces > 49161: DataObject > 49163: Embed Source > 49156: Native > 49155: OwnerLink > 49166: Object Descriptor > 3: CF_METAFILEPICT > 50218: CorelPhotoPaint.Image.7 > 8: CF_DIB > 49171: Ole Private Data > 14: CF_ENHMETAFILE > 2: CF_BITMAP > 17: CF_DIBV5 > This works > > Corel Photopaint 12 gives > 49161: DataObject > 49163: Embed Source > 49156: Native > 49155: OwnerLink > 49166: Object Descriptor > 3: CF_METAFILEPICT > 50250: CorelPhotoPaint.Image.12 > 50254: CorelPhotoPaint.Image.9 > 8: CF_DIB > 49171: Ole Private Data > 14: CF_ENHMETAFILE > 2: CF_BITMAP > 17: CF_DIBV5 > Works too > > MyAlbum 2.5.5 > 8: CF_DIB > 2: CF_BITMAP > 17: CF_DIBV5 > This works (same as XNVIEW) > > These are all the programs I have > > Othmar > (In reply to comment #7) > I don't think the order the clipboard formats are listed matters. Just to make > it sure, these outputs are after you have done the copy operation in GIMP or > xnview, but before you have pasted into Word, right? It's a bit odd that you > can't paste from GIMP but can from xnview then, as the list of formats offered > by xnview looks to me like a pure subset of the ones listed by GIMP. > > I can't paste into Word 2007 after doing a copy in GIMP, either. I can paste > into MS Paint, though. If I then do a Select All and Copy in MS Paint, > clipboard -l lists the formats: > > > clipboard -l > 49161: DataObject > 49163: Embed Source > 49156: Native > 49155: OwnerLink > 49166: Object Descriptor > 3: CF_METAFILEPICT > 8: CF_DIB > 49171: Ole Private Data > 14: CF_ENHMETAFILE > 2: CF_BITMAP > 17: CF_DIBV5 > > Pasteing into Word 2007 from MS Paint works fine. My guess would be that Word > uses the CF_METAFILEPICT or CF_ENHMETAFILE formats? >
> Word 2003 does not change the clipboard [when pasting] Ah, ok, sorry. I know it shouldn't/doesn't I just didn't think clearly ;) So I guess there must be some real problem then in the GTK+/win32 code that handles the clipboard then, when it is possible to paste into MS Paint but not into Word. Changing product to gtk+.
I am having the same problem. Note that the Windows Clipboard Viewer, CLIPBRD.EXE, can read the CF_DIB from Gimp but not the CF_BITMAP (from the Clipboard UI, View->Bitmap after copying from Gimp). I verified that Gimp produces an identical CF_DIB to MS Paint for the same image. Gimp's CF_BITMAP seems wrong. The bmType is not the required 0. The following program fragment demonstrates the problem. Copy from Gimp, run this, paste into MS Paint, run this again. A work-around might be to have Gimp only copy CF_DIB, not CF_BITMAP. if (OpenClipboard(NULL)) { printf("Opened Clipboard\n"); HANDLE hbitmap = GetClipboardData(CF_BITMAP); BITMAP bm; GetObject(hbitmap, sizeof(BITMAP), (LPSTR) &bm); printf("Type = %d\n", bm.bmType); printf("Width = %d\n", bm.bmWidth); printf("Height = %d\n", bm.bmHeight); printf("WBtytes = %d\n", bm.bmWidthBytes); printf("Planes = %d\n", bm.bmPlanes); printf("Bits/Pixel = %d\n", bm.bmBitsPixel); printf("Ptr = %p\n", bm.bmBits); unsigned char *p = (LPSTR) &bm; int i; for (i = 0; i < sizeof(BITMAP); i++) { printf("%02x", *p++); } GlobalUnlock(hbitmap); CloseClipboard(); }
A poster on gimpusers.com points out that Paint.NET (http://www.getpaint.net/) is a no-cost program that demonstrates the same inability to receive images by pasting from GIMP.
This bug seems to have been there many years. It was introduced as part of Ivan Wong's patch for delayerd rendering, see bug #168173. The size of the DIB stored in the clipboard was for some reason truncated by one byte. Presumably this also means that the data for CF_DIB was also bad, one byte too short? The CF_DIBMAP format is synthesized by Windows from the CF_DIB data that GTK+ stores on the clipboard, and apparently Windows is picky that the CF_DIB data really is consistent, thus attempts to fetch data in CF_BITMAP format failed.) The fix is very simple: Index: gdk/win32/gdkselection-win32.c =================================================================== --- gdk/win32/gdkselection-win32.c (revision 22081) +++ gdk/win32/gdkselection-win32.c (working copy) @@ -1175,7 +1175,7 @@ HGLOBAL hdatanew; g_free (target_name); - size = GlobalSize (hdata) - 1 - sizeof (BITMAPFILEHEADER); + size = GlobalSize (hdata) - sizeof (BITMAPFILEHEADER); ptr = GlobalLock (hdata); memmove (ptr, ptr + sizeof (BITMAPFILEHEADER), size); GlobalUnlock (hdata); Fixed in trunk and gtk-2-14.
Created attachment 126214 [details] Updated test program Slightly updated test program that properly prints out also CF_BITMAP format, where the handle from GetClipboardData() isn't a memory handle but really a HBITMAP.
I wonder if the subtraction of one here, too, is bogus: ok = gdk_pixbuf_loader_write (loader, ptr, GlobalSize (hdata) - 1, NULL) && gdk_pixbuf_loader_close (loader, NULL); If I understand correctly, this is code that gets invoked when an GTK+ app provides image data to the clipboard in some other format than bmp, and some other app then requests the image as bmp. I don't know how easy it might be to get this code exercised.