Apache OpenOffice (AOO) Bugzilla – Issue 119536
[From Symphony]arrow change size and position in MS after save odp to ppt format
Last modified: 2012-12-26 08:00:49 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.
Created attachment 78271 [details] sample file with arrow shape This defect focus on arrow's size and position. not on circle.
solution: Wrong rotate operation on ShapeBoundRect in scherPropertyContainer::CreateGraphicProperties, we shouldn't rotate the shape self.
Created attachment 78308 [details] Fix patch for this issue
I will take care of this.
Mark the circle sample as obsolete. This is about rotation of arrows.
Simple removing the rotation operation may not be right. There can be circumstance that rotation effect is needed.
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).
Created attachment 78403 [details] Patch for solution (b)
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).
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.
Created attachment 78426 [details] Example file with two bitmap objects both 45 degree rotated
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)...?
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...
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.
Created attachment 78429 [details] Extended solution (b)
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).
(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.
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 on attachment 78429 [details] Extended solution (b) Setting patch flag.
Comment on attachment 78403 [details] Patch for solution (b) Setting patch flag.
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?
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 on attachment 78308 [details] Fix patch for this issue Reviewed OK.
Checked in solution A patch. SVN revision is 1359009.
Verified pass with AOO trunk r1374181.
"alg" committed SVN revision 1404513 into trunk: #119536# removed code no longer needed after fix of that task