Apache OpenOffice (AOO) Bugzilla – Issue 106549
Cannot paste image from clipboard with GNOME clipboard manager
Last modified: 2014-02-02 13:01:53 UTC
When I'm using the gnome clipboard manager (available in gnome-settings-daemon) or the xfce4-clipman-plugin (which bundles the same daemon) and I copy an image into the clipboard (f.e. with gnome-screenshot) it is possible to paste it within writer/impress/... but it will hang for a while and finally nothing is pasted. Without the daemon it works (but of course the application that puts the image into the clipboard must not quit or the clipboard content will be lost). I looked a bit around and perhaps OOo is miss-interpreting the XATOMS. Without the daemon: TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/jpeg image/x-icon image/x-ico image/x-win-bitmap image/tiff image/bmp image/x-bmp image/x-MS-bmp With the daemon the images gets stored with these: TARGETS MULTIPLE image/x-MS-bmp image/x-bmp image/bmp image/tiff image/jpeg image/png SAVE_TARGETS TIMESTAMP Pasting the image into other programs like gimp works fine.
Mmh, when I copy the screenshot to clipboard with gnome-screenshot everything is fine (the XATOMS are kept intact), it is only when I copy the image to clipboard with xfce4-screenshooter. Will have to digg a little more to make sure why both screenshot apps are behaving differently.
Ah... seems gnome-screenshot doesn't send a store even to the clipboard manager so unless the application is not closed the XATOMS are like the ones I pasted without the daemon, but once the application is closed it gets stored inside the clipboard manager with different XATOMS.
I think I found the bug, it comes definitely from the clipboard manager. Once saved within the CM it reports the target image/bmp but that particular target (amongst tiff, x-bmp and x-MS-bmp) is empty. In fact there is no format nor a length reported for it. When I try to get that target with a GTK+ test program it simply returns. Could it be that OOo tries to read the first target and hangs in there (it hangs for quite a few seconds)?
Fact that it is hanging shows that the amount of data to get from the clipboard is huge... probably way-way lot more than what it should be. And in the end the bmp image is garbage. I looked what OOo tries to paste first and it is indeed the image/bmp target (the order is not important e.g. if it is first or last in the target list). Gimp tries first the image/png target which has no problem and the reason why it was actually able to paste anything at all. My test program can be found here: http://paste-it.net/public/j26f589/ I opened a big png image and pass it for the image/bmp target (which is obviously wrong) and I was able to reproduce the bug I discovered with the CM. Gonna comment upstream on the CM about this fact. I guess the bug can still be left open cause if OOo fails to load the image/bmp it should try another target until there isn't anymore left. And I had like to suggest to load image/png first as it has an alpha channel which doesn't exist for bmp images! Cheers :-)