Parameter for addShape for a child of a group in oox import

[Regina Henschel]

Hi all,

if a child shape in a group is rotated, then it is currently imported 
wrongly. The visual effect of the wrong import is, that the shape might 
be skewed.

The correct behavior would be:
1. Build transformation matrix Mg for the unrotated group shape. Would 
use "off" and "ext" from grpSpPr.
2. Build transformation matrix MCh for the child transformation. Would 
use "choff" and "chext" form grpSpPr.
3. Build transformation matrix Msp for the unrotated child shape. Would 
us "off" and "ext" from spPr.
4. Build M = Mg * MCh * Msp and so get an unrotated child shape in an 
unrotated group considering the implicit coordinate transformation.
5. Rotate the child shape of step 4 around its center by the angle "rot" 
from spPr. For custom shapes this need to include the change to a 90° 
rotated basic rectangle for angles in 45°..135° and 225°..315°, same as 
we have seen in other places.
6. Apply the group rotation, which is a rotation around the center of 
the group as of step 1. This means without the child transformations of 
step 2.


Currently there are two error:
1. The scale included in step 1 and step 2 is applied after the shape 
rotation, which results in skew, if scale is not uniform.
2. The special 90° rotated basic rectangle use is missing.


Problem: The current solution to provide a "parent transformation" in 
Shape::addShape and Shape::createAndInsert respectively, does not allow 
a correct workflow, because it contains a combined step 1 and step 2 and 
therefore the scale and translate values form the original group are not 
available, so the center of the group cannot be calculated.


Question: How to bring the needed infos to the child shape?

My first idea is, to add a maybe empty struct to the parameter list, 
that can contain all the needed infos, e.g. the matrices of step 1 and 
step 2 as separate matrices and the group rotation angle as separate 
value. Such struct could later carry in addition 3Dsettings which are 
set at the group and bring them to the child shapes.


What do you think about that? Any concerns? Better ideas?

Remark: I have not yet investigate how MS Office handles group in group.

Sorry for the long mail, but I find no shorter way to describe the 
situation.

Kind regards
Regina