Apache OpenOffice (AOO) Bugzilla – Issue 122753
Copy/Paste-as-Bitmap with GraphicObjects may show wrong graphic
Last modified: 2017-05-20 11:41:50 UTC
Open the attached file on AOO 4.0 (on 3.4.1 works without problem) On the first page, there are two pictures, a simple bitmap and a photography. Try to rotate both, one at a time: the bitmap rotates without problems, the picture gets corrupted. The corrupted image is exported to PDF. On the second page, there is a screenshot that shows the result of the rotation on both pictures. Below the screenshot, you can find the result of copying the fox picture and pasting it as bitmap: an empty rectangle. The same happens on Impress. 3.4.1 does not show these problems, so adding "regression" as keyword.
Bugzilla did not upload the file and gave me no warning... Because it's loo large, I uploaded it here: http://people.apache.org/~rgb-es/rotation.odg
ALG: Could not reproduce on Win7 32- bit version. Someone checked on mac?
Created attachment 81080 [details] A new sample document On this new attachment, on first page you'll find original picture, on second page a paste special → as bitmap (it gives an empty box), on third page the same picture on page 1 copy pasted and then rotated. Note: If on an empty document I insert the first picture and then rotate it, there is not problem. The picture gets corrupted on rotation only after I perform paste special → as bitmap. It doesn't matter I do that on a different page.
Created attachment 81081 [details] PDF export of previous attachment As you can see on this new attachment, the corrupted image is exported wrong to PDF.
Created attachment 81082 [details] Draw session with keep ratio set, correct rotation and flip Works for me on AOO400m3(Build:9702) - Rev. 1502185 2013-07-10 14:15:55 (Mi, 10 Jul 2013) Setting as UNCONFIRMED Opened original rotation.odg in draw I selected the "keep ratio" checkbox on the Position and Size tray. Rotated fox with radial rotation. Rotated background image 90 deg. Copied fox into same panel. Rotaded copy with radial tool. Copied. Opened an impress presentation, blank slide. Pasted into slide. Resized. Back in Draw, copied fox. Moved to second panle. Pasted. Flipped on vertical axis. Saved, opened. See attached screen capture of session.
I can reproduce it under windows 8 64bit, without rotation. Create new odg file, insert any picture. CTRL+C Create new slide CTRL+SHIFT+V Insert image as bitmap. The picture frame is empty. https://issues.apache.org/ooo/attachment.cgi?bugid=122753&action=enter
Created attachment 81083 [details] bugdoc
I can confirm for Windows7 too, that insert as Bitmap does not work. If I open the windows Clipboard parallel, I see, that the Bitmap format is already wrong in the clipboard. It is not a problem of the size. The empty Bitmap format happens too, when I reduce the jpg-file to 512x410 pixel. The error does not occur in AOO3.4.1. I think, that the bad looking rotated picture is a different problem and should get its own bug report.
Testing in Windows 7 sp1, 64-bit. Only if Copy -> Pasting as bitmap (selection from CTL + SHIFT + V) and not as default Drawing object format I do see a place holder outline of missing bitmap. But menu Insert picture --> from files: works correctly for all bitmaps I try bmp, jpeg, png, tif. All insert, display and respond correctly to sidebar tools when pasted. Question, why would one paste into a OpenOffice component as Bitmap rather than a Draw object? And since pasting the Draw object seesm to work as designed, if there is an issue--seems it would be with any automated filter conversion for bitmap or SVG images held in Draw object being converted to pastable Bitmap, what ever format that might be. I'll have a go on a 64-bit Linux.
(In reply to V Stuart Foote from comment #9) > Question, why would one paste into a OpenOffice component as Bitmap rather > than a Draw object? > This triggers the problem of the picture corruption, I'm not sure there is another way to trigger this but look at the Impress doc linked on this thread on the Spanish forum http://forum.openoffice.org/es/forum/viewtopic.php?p=35072#p35072 The user gets a corrupted image too.
(In reply to Regina Henschel from comment #8) > I can confirm for Windows7 too, that insert as Bitmap does not work. If I > open the windows Clipboard parallel, I see, that the Bitmap format is > already wrong in the clipboard. It is not a problem of the size. The empty > Bitmap format happens too, when I reduce the jpg-file to 512x410 pixel. The > error does not occur in AOO3.4.1. > > I think, that the bad looking rotated picture is a different problem and > should get its own bug report. The copy/paste as bitmap triggers the rotation problem for the current session. If you do the sequence copy → paste as bitmap → select original picture → rotate, then you get the corrupted image. If you now close AOO, reopen and just select the original image to rotate it, no problem. Now, if after the clean start you go to page 2 of rotation2.odg and *select* the empty bitmap, going to the first page and trying to rotate the original image will show the problem again.
ALG: On WIndows7 I could once reproduce the paste which produces a frame without image. The 2nd time I tried I cannot reproduce, not even after program restart, strange. The damaged rotation I could not reproduce on Win7 at all, seems to be unix-specific eventually. Building a 64bit linux version right now...
Copy and paste as Bitmap is OK in r1492861. It is broken in r1495357.
ALG: Thanks Regina, that might help. Anyone checked which apps are involved? Writer has other GraphicObjects, for example.
Got r1502185 RC build, set up on a Windows 8 64-bit system. Same issue in Draw when pasting a Draw image as bitmap (using CTL + SHIFT + V to select Bitmap) rather than a Draw object. On same system, in Writer, an image pasted in and then copied as bitmap (the same CTL + SHIFT + V selection -- except just have the option for bitmap selection) pastes a proper copy of the image. While a Draw object copied from draw will paste into the same Writer page--just a bit slow to render. And if that same Draw object is pasted as bitmap (CTL + SHIFT + V menu shows both Draw object and a bitmap) get the corrupt bitmap, outline only.
Filled a new issue for Impress with just the picture corruption problem https://issues.apache.org/ooo/show_bug.cgi?id=122758
ALG: @rgb: Thanks for the extra issue, thus I will adapt title of this one. What happens is the following: - CTRL-C clones the selection to a new model - Paste-special/as Bitmap creates a Bitmap based on that cloned content In the meantime the content of the cloned GraphicObject may have been streamed out. The 'mechanism to get the primitives and convert to a BitmapEx' (a) will create the replacement visualization that will be seen, the same as if a GraphicObject is swapped out and fast scrolling temporarily shows this. I changed (a) in r1432130 to directly use primitives, described in task #121609#, to get a better quality for tiled bitmaps, comitted at 2013-01-11. Thus, regression is correct. That change is not wrong since it uses getViewIndependentPrimitive2DSequence at the ViewContact of the cloned GraphicObject. As the name says this should return a view-independent visualization, thus an evtl. streamed out graphic *should* be loaded. Thus, the correct fix would be to change ViewContactOfGraphic::createViewIndependentPrimitive2DSequence() to always swap-in the needed graphic and to adapt ViewObjectContactOfGraphic::createPrimitive2DSequence to do the view-dependent part (as is intended). This fix is complicated and not safe enough for now. A quick and safe workaround would be in SdrExchangeView::GetMarkedObjBitmapEx to not just get the primitives from SdrObjects, but - if it's a SdrGrafObj - first call SdrGrafObj::ForceSwapIn() at it. The error itself is not always reproducible (I get it at maybe 15% of my tries) and paste-special/as-Bitmap is not the joe-user-way. Thus, I do not think that this should stop the AOO4.0... Testing the proposed QuickFix... P.S.: I could up to now not reproduce the corruption of the bitmap at rotation time.
Created attachment 81087 [details] ALG: Patch to force SwapIn for SdrGrafObjs which are part of a conversion to BitmapEx
"alg" committed SVN revision 1503655 into trunk: i122753 Force SwapIn for BitmapObjects which are part of a conversion to Bitm...
ALG: Tested QuickFix, works well, added as patch and comitted to trunk.
"alg" committed SVN revision 1503699 into branches/AOO400: i122753 integrated fix from trunk
grant showstopper flag, fix available
ALG: Changing back to all systems, was not system-dependent. Will need to write a follow-up, too.
It's working on AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:49:37 (Tue, 16 Jul 2013) - Linux x86_64