Issue 119536

Summary: [From Symphony]arrow change size and position in MS after save odp to ppt format
Product: Impress Reporter: Li Feng Wang <phoenix.wanglf>
Component: save-exportAssignee: mayongl <mayongl>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P2 CC: Armin.Le.Grand, awf.aoo, jiazema, liushenf, mayongl
Version: 3.4.0   
Target Milestone: 4.0.0   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
sample file with circle
sample file with arrow shape
Fix patch for this issue
awf.aoo: review+
Patch for solution (b)
Effect of solution b
Example file with two bitmap objects both 45 degree rotated
Extended solution (b)
test for xp ppt none

Description Li Feng Wang 2012-05-30 02:32:25 UTC
Created attachment 77744 [details]
sample file with circle

AOO3.4 r1327774

1)open sample file with AOO3.4 
2)save as to ppt file format
3)reopen ppt file with MS 

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
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.
Comment 25 Li Feng Wang 2012-08-21 05:13:33 UTC
Verified pass with AOO trunk r1374181.
Comment 26 SVN Robot 2012-11-01 09:35:48 UTC
"alg" committed SVN revision 1404513 into trunk:
#119536# removed code no longer needed after fix of that task