Apache OpenOffice (AOO) Bugzilla – Issue 119703
Save .xls in OO3.4, the rotation setting of grahpic in grouped object will be lost.
Last modified: 2013-07-11 15:20:53 UTC
Created attachment 77913 [details] Grouped object with a rotated graphic in Build info: AOO3.4_r1327774 Reproduce steps: 1. Open the sample file attached in OO3.4, which has a grouped object(one freeline and one graphic) in. 2. Save it as .xls file. 3. Reopen it in OO. 4. Ungroup the object. 5. Check the rotation setting of the two object. Issue found: The rotation setting of Freeline can be saved (345 degrees), the rotation setting of graphic will be changed into 0 degree(it should be 45 degrees). And in step 3, you can find the grouped object has a slight deformation.
This bug can repros on AOO3.4.O Rev. 1327774, and I change the status from Unconfirmed to confirmed.
ALG: The graphic object is still rotated 45 degrees, but somehow gets deformed (relayouted in pixels) which may have to do with an old fix for PPT2003. Interestingly, Excel loads the newly changed file and shows the object correct, but the group size has extended. It seems to scale the relayouted image correctly. It does not happen when the graphic object is not grouped. Checking deeper...
ALG: Can be reproduced by creating a new calc, adding one shape and one graphic shape and grouping them. Graphic has not to be linked.
ALG: Also reproducable with new presentation, rectangle, rotated graphic and grouping these.
ALG: Same effect with Symphony. Looking further...
ALG: It even happens with two rectangles, one roated and both grouped. Seems to be an old bug with grouping.
ALG: I can load the newly created file correctly when *not* executing the scaling applied at msdffimp.cxx ln 4370. Exactly that scaling needs to be executed when loading the original test file. It is some kind of 'embedding' of object dimensions to group dimensions. The logic result is that the group dimension for export is calculated (and exported) wrong. This may have to do with bound rects of rotated objects, AFAIR MS format does use unrotated geometries. Maybe the group dimension is calculated for export using the rotated ones, checking...
ALG: Taking over...
ALG: Indeed at export the unrotated (and unsheared, that's another story, MS does not support this) is needed. I have now adapted ImplEESdrObject::Init which fills the BoundRect for the to-be-exported shape to use a helper method (getUnrotatedGroupBoundRange) when it's a group object to be exported. That method uses UNO API to recursively iterate over all contained shapes and calculates their unrotated, unsheared range (using the object transformation directly). Doing this works well, the bound ranges after export are also better now in MS programs. The MS graphic filter im/export stuff is not too well organized (grown) and may be reorganized/cleaned up and redefined more systematically... Testing with shear, too...
"alg" committed SVN revision 1382015 into trunk: #119703# Corercted bound rect for ms graphic object export for grouped object...
ALG: Comitted, done. This was a long-existing, systematical error/not supported functionality in ms graphic export format.
Verified on Aoo_Trunk_20121109.1800 rev 1407366, rotation setting of graphic is saved correctly, the bug is fixed.
Close it.