After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523554 - Copy from GIMP to Word broken
Copy from GIMP to Word broken
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.12.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-03-20 13:56 UTC by Othmar Marti
Modified: 2009-01-11 14:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
clipboard.c (5.46 KB, text/plain)
2008-03-22 01:16 UTC, Tor Lillqvist
Details
clipboard.exe (22.52 KB, application/octet-stream)
2008-03-22 01:18 UTC, Tor Lillqvist
Details
Screenshot of Word when copying from Gimp (109.42 KB, image/png)
2008-03-23 06:24 UTC, Othmar Marti
Details
Updated test program (6.54 KB, text/plain)
2009-01-11 13:26 UTC, Tor Lillqvist
Details

Description Othmar Marti 2008-03-20 13:56:38 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
Comment 1 Sven Neumann 2008-03-20 14:32:21 UTC
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.
Comment 2 Othmar Marti 2008-03-21 10:00:28 UTC
(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
Comment 3 Tor Lillqvist 2008-03-22 01:16:36 UTC
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.
Comment 4 Tor Lillqvist 2008-03-22 01:18:20 UTC
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
Comment 5 Othmar Marti 2008-03-23 06:24:30 UTC
Created attachment 107851 [details]
Screenshot of Word  when copying from Gimp
Comment 6 Othmar Marti 2008-03-23 06:31:37 UTC
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
> 

Comment 7 Tor Lillqvist 2008-03-23 10:26:53 UTC
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?

Comment 8 Othmar Marti 2008-03-24 08:01:06 UTC
(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
Comment 9 Othmar Marti 2008-03-24 08:11:11 UTC
(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?
> 

Comment 10 Tor Lillqvist 2008-03-24 08:15:04 UTC
> 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+.
Comment 11 esnible 2008-11-24 02:57:07 UTC
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();
    }
Comment 12 esnible 2008-12-01 16:29:36 UTC
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.
Comment 13 Tor Lillqvist 2009-01-11 13:24:53 UTC
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.
Comment 14 Tor Lillqvist 2009-01-11 13:26:40 UTC
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.
Comment 15 Tor Lillqvist 2009-01-11 14:02:47 UTC
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.