GNOME Bugzilla – Bug 631384
Images pasted from clipboard are shifted/wrapped
Last modified: 2011-11-10 18:21:24 UTC
Created attachment 171741 [details] Broken image pasted from buffer Images pasted from buffer, after making screen shot of single window (alt + Prt Scr) are broken (see attachment). The image is moved to right and wrapped from left. This bug is very seriously, the last working version fro me is 2.6.8, I've checked 2.6.10 and there is already the problem. I think it's maybe something with GTK, cause the same problem occurs in i the latest inkscape -> 0.48
Works for me, and I don't recall any other reports about this. Could there be something special to your system or the window you're taking the screen shot of?
Hah, of course I couldn't reproduce this, because it only happens if you've taken the screen shot by Alt+Print Screen, and not the screen shot plug-in. Reassigning to GTK+
ok, but on my and my friends' computer the problem occurs in both cases, with and without alt key pressed :(
*** Bug 631578 has been marked as a duplicate of this bug. ***
Michael, can you really reproduce this? I can't...
(In reply to comment #5) > Michael, can you really reproduce this? I can't... I don't mean to butt in, but I can consistently reproduce this bug if I place an image into the clipboard using the software application Paint.NET. When pasting the image into GIMP, the image is misaligned, but when pasting the same image into other applications like Microsoft Paint or XnView, the image is correctly aligned. As many here will know, bitmaps in Windows are stored in memory bottom row first. As you will see in Marcin's attachment, when gtk+ imports the image from the clipboard, it first renders three garbage pixels ((255, 0, 0), (0, 255, 0), (0, 0, 255), in that order) and then proceeds to render the rest of the image (in bottom-up fashion). This explains why the resulting image appears to be cyclically shifted to the right by three pixels. It appears that the bug is due to gtk+ sometimes incorrectly determining the offset to the pixel data in the imported bitmap. As far as I can tell, most (if not all) bitmaps exported to the clipboard in Windows are 32 bits per pixel, so the offset is off by four bytes.
i_speak_math: thanks for the useful comment, that will make it esier to reproduce and fix the problem indeed.
See http://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkselection-win32.c#n717 The field 'bfOffBits' of the BITMAPFILEHEADER prepended to the data in the clipboard is wrong for bmps having biCompression == BI_BITFIELDS and biBitCount >= 16 (screenshots taken with Alt-printScreen are found in the clipboard in this format). In that case the BITMAPINFOHEADER is followed by three DWORD specifying the masks of the red green and blue components. So the offset is missing this 12 bytes corresponding to the first three pixels red green and blue in the bottom row of the image attached to the bug report. The regression is a consequence of the adoption of the pixbuf loader based on Gdiplus, because the old loader, for these bmps, does not access the above mentioned field.
*** Bug 642549 has been marked as a duplicate of this bug. ***
*** Bug 643451 has been marked as a duplicate of this bug. ***
Created attachment 200669 [details] [review] fix some typos in gdk_selection_convert
Created attachment 200670 [details] [review] win32: fix pasting screenshots taken with PrintScreen or Alt+PrintScreen implements the suggestion from comment #8
pushed to the win32 branch