Issue 122753 - Copy/Paste-as-Bitmap with GraphicObjects may show wrong graphic
Copy/Paste-as-Bitmap with GraphicObjects may show wrong graphic
Status: VERIFIED FIXED
Product: Draw
Classification: Application
Component: editing
4.0.0-dev
PC All
: P3 major (vote)
: 4.0.0
Assigned To: Armin Le Grand
: regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 14:50 UTC by rgb
Modified: 2013-07-18 01:28 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---
jsc: 4.0.0_release_blocker+


Attachments
A new sample document (177.01 KB, application/vnd.oasis.opendocument.graphics)
2013-07-15 16:26 UTC, rgb
no flags Details
PDF export of previous attachment (804.37 KB, application/pdf)
2013-07-15 16:28 UTC, rgb
no flags Details
Draw session with keep ratio set, correct rotation and flip (150.34 KB, image/jpeg)
2013-07-15 17:17 UTC, V Stuart Foote
no flags Details
bugdoc (382.32 KB, application/vnd.oasis.opendocument.graphics)
2013-07-15 17:24 UTC, r4zoli
no flags Details
ALG: Patch to force SwapIn for SdrGrafObjs which are part of a conversion to BitmapEx (970 bytes, patch)
2013-07-16 10:55 UTC, Armin Le Grand
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description rgb 2013-07-15 14:50:28 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.
Comment 1 rgb 2013-07-15 15:19:00 UTC
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
Comment 2 Armin Le Grand 2013-07-15 16:12:41 UTC
ALG: Could not reproduce on Win7 32- bit version. Someone checked on mac?
Comment 3 rgb 2013-07-15 16:26:31 UTC
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.
Comment 4 rgb 2013-07-15 16:28:53 UTC
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.
Comment 5 V Stuart Foote 2013-07-15 17:17:28 UTC
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.
Comment 6 r4zoli 2013-07-15 17:22:01 UTC
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
Comment 7 r4zoli 2013-07-15 17:24:35 UTC
Created attachment 81083 [details]
bugdoc
Comment 8 Regina Henschel 2013-07-15 17:38:43 UTC
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.
Comment 9 V Stuart Foote 2013-07-15 17:58:48 UTC
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.
Comment 10 rgb 2013-07-15 18:22:11 UTC
(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.
Comment 11 rgb 2013-07-15 18:39:52 UTC
(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.
Comment 12 Armin Le Grand 2013-07-15 19:08:02 UTC
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...
Comment 13 Regina Henschel 2013-07-15 19:20:20 UTC
Copy and paste as Bitmap is OK in r1492861. It is broken in r1495357.
Comment 14 Armin Le Grand 2013-07-15 19:37:41 UTC
ALG: Thanks Regina, that might help. Anyone checked which apps are involved? Writer has other GraphicObjects, for example.
Comment 15 V Stuart Foote 2013-07-16 01:13:20 UTC
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.
Comment 16 rgb 2013-07-16 08:51:44 UTC
Filled a new issue for Impress with just the picture corruption problem

https://issues.apache.org/ooo/show_bug.cgi?id=122758
Comment 17 Armin Le Grand 2013-07-16 10:01:18 UTC
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.
Comment 18 Armin Le Grand 2013-07-16 10:55:11 UTC
Created attachment 81087 [details]
ALG: Patch to force SwapIn for SdrGrafObjs which are part of a conversion to BitmapEx
Comment 19 SVN Robot 2013-07-16 10:55:55 UTC
"alg" committed SVN revision 1503655 into trunk:
i122753 Force SwapIn for BitmapObjects which are part of a conversion to Bitm...
Comment 20 Armin Le Grand 2013-07-16 10:56:37 UTC
ALG: Tested QuickFix, works well, added as patch and comitted to trunk.
Comment 21 SVN Robot 2013-07-16 12:57:35 UTC
"alg" committed SVN revision 1503699 into branches/AOO400:
i122753 integrated fix from trunk
Comment 22 jsc 2013-07-16 13:02:07 UTC
grant showstopper flag, fix available
Comment 23 Armin Le Grand 2013-07-16 13:09:18 UTC
ALG: Changing back to all systems, was not system-dependent. Will need to write a follow-up, too.
Comment 24 rgb 2013-07-18 01:28:32 UTC
It's working on

AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-16 14:49:37 (Tue, 16 Jul 2013) - Linux x86_64