Created attachment 42037 [details]
1 page ppt file with a figure(has alpha channel)
when a figure made by GIMP2.6 with transparent channel copied and pasted onto writer, the transparent part appears as black.
If the same figure was pasted onto the MSOffice2010 pp or word, it appears fine.
When the pasted figure in MSOffice file copied and put into LibO3.3 RC3(and RC2) writer, the program stops and exits.
I attached the pptx format file I pasted from GIMP2.6.
Created attachment 43601 [details]
picture with transparent middle to demonstrate problem with transparency
I have generated small picture to demonstrate this problem. When I add picture to writer or Draw by Insert->Picture->From File it is ok. But when directly from Gimp, thet black square in middle of picture. On windows 32 the same problem as in Linux 64.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I can confirm that pasting an image with a Transparent part it will loose transparency.
This is not unexpected since the only option available in Paste As is Bitmap so I assume that using simple Paste will use the only option available. A Bitmap doesn't have alpha channels...
This is a limitation of the way LO handles the Windows clipboard.
When pasting the same image in MS Office with Paste As in addition to Bitmap you get Picture (PNG), which is selected by default, and Device Independent Bitmap.
This feature is quite important when transferring images using the clipboard.
reproduced on LibO 3.5.0 beta 2 on Fedora 64 bit
IMHO LibreOffice saves all pasted in clipboard images as JPEG images
workaround at this time is: save image as file in Gimp and then insert this file into LibreOffice
*** Bug 41804 has been marked as a duplicate of this bug. ***
*** Bug 36097 has been marked as a duplicate of this bug. ***
*** Bug 36098 has been marked as a duplicate of this bug. ***
*** Bug 38434 has been marked as a duplicate of this bug. ***
*** Bug 33346 has been marked as a duplicate of this bug. ***
The clipboard code responsible for pasting into a document needs some rework. It currently only accepts images with mime type "image/bmp" (Bitmap). It should accept the same image formats it can import by using the standard "insert image from file" command.
Working with 3.4.4 on Ubuntu 11.04
My bug #33346, which is a duplicate of this can still be reproduced with lo 3.5.1 on Ubuntu 11.10
reproduced in 3.5.1 on Fedora 64 bit, so Reopened
*** Bug 47856 has been marked as a duplicate of this bug. ***
Tested and still broken in 3.6RC. This is one of the last really clunky old OpenOffice nuances still hanging with us. Not being able to paste an image with an alpha channel forces the users to save the file first and then insert it into Libreoffice.
Thanks for additional testing
"Version" is most old version of program where bug appears. Not current version.
Changing back to 3.3.0 RC3
I am using LO 184.108.40.206 on Ubuntu 12.04 and I don't seem to be able to reproduce this (two different png files with alpha channel tested), even though I remember it was my most hated bug a while ago.
Can anyone try this again with the 3.6 series?
Bug is still there as of 3.6.2.
1) Open libreoffice draw
2) Open a web browser
3) With the web browser, go to https://en.wikipedia.org/w/index.php?title=File:Ohm%27s_Law_with_Voltage_source.svg&page=1
The figure that shows on the browser has an alpha channel
4) Copy it
5) Back to libreoffice. Paste the image. You get a black box instead of the image.
If at point 5 you select Paste as special, you can see that the only option relevant to images is bitmap (see comment 10).
Ok I can reproduce this as described in comment #18 (Ubuntu 12.04 32 bits, LO 220.127.116.11).
The thing is that I can remember having this problem in Writer but can't reproduce this anymore. Has this been fixed seperately in Writer recently? It would make it easier to fix in Draw, wouldn't it? Of course, I have no idea at all :)
*** Bug 56751 has been marked as a duplicate of this bug. ***
There is a simple workaround: Create an empty text document, paste the image in there, copy it again and now paste it into Impress.
Tested with 18.104.22.168 (Build ID: 5b93205) on Linux
workaround not works in 4.0.0 on RFR 17 64bit
picture opened in Gimp, then Ctrl-A, Ctrl-C and in Writer Ctrl-V
Same problem here - or probably related.
1) Copy parts of a presentation (in my case from Keynote) to the clipboard
2) Paste it into writer
3) Result is that is has a black background instead of the original white background.
- Mac OSX 10.9.1
- Writer 22.214.171.124
- Keynote 6.1
What does work, is put an empty white box at the background of my presentation and then copy it. So it seems that a presentation (vector image?) with a transparent background is drawn with a black background.
*** Bug 70996 has been marked as a duplicate of this bug. ***
I'm routinely annoyed by this - though it works sometimes =)
Even more annoyingly, I can't reproduce it with master under Linux now; either in writer or draw with the attached image.
Reproduces under windows. The magic COM interface we get these nasty integer format IDs from is documented here: eg. 49383 -> 0xc0e7 -> text/html (obviously !)
Confirmed under LO draw.
I have been testing this on Windows, and what happens is that when you copy it in Gimp, then it is 3 times on the clipboard: as PNG, Device independant bitmap, and Bitmap.
When you Paste Special to PowerPoint, and choose DIB or Bitmap, you will get the same effect as in LibreOffice - black instead of transparency. So only pasting as PNG gives you what you want.
Now the good news. I have tested with the LibreOffice master, and was unable to reproduce the problem. I was searching, and found out it was fixed by commit 6e3dee395baaf333f0b5b7eae18200bbe5e4c555; when I reverted that, it again pasted with the black background.
So we can close this bug finally; I'll cherry-pick the commit to stable branches.
Gerrit requests for 4.2:
Too large work for attempting to cherry-pick to 4.1, unfortunately.
Sorry if I'm missing something, but I still experience this bug always (as it was throughout different LO versions).
Windows 7, tested under 126.96.36.199 Portable and 188.8.131.52 installation.
Image pasted with black background, Insert from file works fine.
Could some of you who had the same problem recheck it, to hopefully reopen the bug? Thanks.
Ivana - perhaps you could file a new bug; that helps to motivate people =) also - clearly Kendy fixed this issue for me, and lots of others long ago. It would be good to have a new, clear-cut, clean description of the issue - with the correct platform, application being pasted from, test file etc. so it doesn't confuse this old issue.