Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||[From Symphony]arrow change size and position in MS after save odp to ppt format|
|Product:||Impress||Reporter:||Li Feng Wang <phoenix.wanglf>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||P2||CC:||Armin.Le.Grand, awf.aoo, jiazema, liushenf, mayongl|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description Li Feng Wang 2012-05-30 02:32:25 UTC
Created attachment 77744 [details] sample file with circle build: AOO3.4 r1327774 steps: 1)open sample file with AOO3.4 2)save as to ppt file format 3)reopen ppt file with MS defect: circle's size and position were changed.
Comment 1 Li Feng Wang 2012-06-13 02:57:23 UTC
Created attachment 78271 [details] sample file with arrow shape This defect focus on arrow's size and position. not on circle.
Comment 2 Ma Bingbing 2012-06-14 03:12:31 UTC
solution: Wrong rotate operation on ShapeBoundRect in scherPropertyContainer::CreateGraphicProperties, we shouldn't rotate the shape self.
Comment 3 Ma Bingbing 2012-06-14 03:13:44 UTC
Created attachment 78308 [details] Fix patch for this issue
Comment 4 mayongl 2012-06-19 05:48:18 UTC
I will take care of this.
Comment 5 mayongl 2012-06-19 06:08:46 UTC
Mark the circle sample as obsolete. This is about rotation of arrows.
Comment 6 mayongl 2012-06-19 06:26:57 UTC
Simple removing the rotation operation may not be right. There can be circumstance that rotation effect is needed.
Comment 7 Armin Le Grand 2012-06-20 11:17:34 UTC
ALG: There are two ways to save a graphic object, (a) Save angle and unrotated graphic (b) Use angle = 0 and save rotated graphic The current solution tries to do (b), but the correctly adapted pShapeBoundRect in the EscherPropertyContainer used in sd/source/filter/eppt/epptso.cxx is not used since in the sd implementation the locals maRect, maPosition and maSize are used for export and these do not get adapted after the call to aPropOpt.CreateGraphicProperties. Interestingly solution (a) works well, so the suggested patch works. The only question is if there are MS formats which do not work well with rotated graphic objects and thus need the adaption of (a). There is a hint in filter/source/msfilter/escherex.cxx line 1486: // up to xp ppoint does not rotate bitmaps ! which suggests that there maybe indeed problems with (a) for some formats, so (b) being more safe (but also using a enlarged bitmap with questionable quality when self-rotating). If (a) is vaild, the patch will work. If (b) is needed, epptso.cxx line 4787 needs to be adapted to update maRect, maPosition and maSize dependent of aPropOpt.pShapeBoundRect and aPropOpt.bSuppressRotation, similar to lines 4631 (after aPropOpt.CreateConnectorProperties).
Comment 8 Armin Le Grand 2012-06-20 11:49:28 UTC
Created attachment 78403 [details] Patch for solution (b)
Comment 9 Armin Le Grand 2012-06-20 11:52:31 UTC
ALG: Added patch for solution (b), please check functionality. There may be more places where after calling CreateGraphicProperties(...) local values need to be adapted. Seems as if various MS exporters use various local variables instead of the basic functionality in filter module (which is bad).
Comment 10 Ma Bingbing 2012-06-21 03:39:26 UTC
Created attachment 78410 [details] Effect of solution b It seems as if solution b not worded well, please see the attached image. By the way I will check the graphic's rotation of xp point.
Comment 11 Armin Le Grand 2012-06-21 10:07:04 UTC
Created attachment 78426 [details] Example file with two bitmap objects both 45 degree rotated
Comment 12 Armin Le Grand 2012-06-21 10:11:28 UTC
ALG: Hi Ma Bingbing, this is strange. I have added a test file with two bitmap objects, one (c) copied from the original test document and a second (d) self created bitmap. It has the same size, nearly the same shape and the same rotation. When this gets exported to PPT, (c) is indeed wrong, while (d) is correct with solution (b). What is different with object (c)...?
Comment 13 Armin Le Grand 2012-06-21 10:38:16 UTC
ALG: Coming closer. The object (c) is scaled, can be seen by selecting it and choosing 'Original size' in the context menu. It will then go to the form the exported PPT shows. This leads to GraphicObject::GetTransformedGraphic which applies the bitmap changes to do the needed rotation. This method seems to handle the PrefMapMode/PrefSize wrong, so the resulting bitmap has evtl. just the copied values. Checking...
Comment 14 Armin Le Grand 2012-06-21 12:40:49 UTC
ALG: Indeed, reason is that the proportion of the contained graphic is different from the object proportion, thus the bitmap rotation works, but of course the existing unequal (in X/Y) scaling influences these rotation. The result is an unexpected bitmap. To correct this, the scaling has to be taken out of the graphic first. This is a correction of a correction (due to PPT not being able to have rotated bitmaps in some versions), but can also be constructed (just tested). Added code which does the correction. It needs to be at a place where the real object size (without adapted rotation) and the graphic size (pixels, maybe logic) is known. Adding patch when done.
Comment 15 Armin Le Grand 2012-06-21 12:43:24 UTC
Created attachment 78429 [details] Extended solution (b)
Comment 16 Armin Le Grand 2012-06-21 12:45:37 UTC
ALG->Ma Bingbing: Added the extended patch for solution (b), please have a look. It is unfortunately complicated. As alternative we may find out which PPT versions do not support rotated pixel graphics. Maybe it's acceptable to take solution (a).
Comment 17 Ma Bingbing 2012-07-02 07:58:38 UTC
(In reply to comment #16) > ALG->Ma Bingbing: > Added the extended patch for solution (b), please have a look. It is > unfortunately complicated. > As alternative we may find out which PPT versions do not support rotated > pixel graphics. Maybe it's acceptable to take solution (a). Extended patch for solution (b) works well. Because the compatibility, MS-office may show the same result between 97-2003(which contain Office-2002: xp), else if save a rotated graphic is saved to 03ppt, and then we open it with xp ppt, it will be abnormal. And I will verify the conjecture later.
Comment 18 Ma Bingbing 2012-07-02 12:03:57 UTC
Created attachment 78549 [details] test for xp ppt use solution (a) 1). open the sample file with AOO3.5 2). Save it as Microsoft PowerPoint 97/2000/XP (.ppt)(*.ppt) 3). open the saved ppt file(XP) with xp ppt 4). solution (a) works well
Comment 19 Andre 2012-07-06 13:22:19 UTC
Comment on attachment 78429 [details] Extended solution (b) Setting patch flag.
Comment 20 Andre 2012-07-06 13:26:47 UTC
Comment on attachment 78403 [details] Patch for solution (b) Setting patch flag.
Comment 21 Andre 2012-07-06 13:52:39 UTC
The comparison of the two aspect ratios (comparing their /difference/ with 0.05) in the extended patch b looks very strange but with the available information I can not judge whether it might still work. @Ma Bingbing: Armin is on vacation. Which variant do you prefer?
Comment 22 Ma Bingbing 2012-07-08 14:29:29 UTC
I think solution (a) is acceptable, Armin provide solution (b) because Comment 7. But, solution (a) works well for xp ppt(MS 2002), you can refer Comment 18. Solution (a) is more simple.
Comment 23 Andre 2012-07-09 09:54:22 UTC
Comment on attachment 78308 [details] Fix patch for this issue Reviewed OK.
Comment 24 Andre 2012-07-09 09:55:40 UTC
Checked in solution A patch. SVN revision is 1359009.