scanny
Clone of grouped shapes return incorrect size/position coordinates
Problem: I have 2 grouped shapes on a slide. The right hand side grouped shape is a clone of the left, I simply copy-pasted it.
Reading the shape's size and position of the clone is incorrect. It provides the size and position of the left hand side grouped shapes.
Test template: Grouped.shapes.test.pptx
Expected result: All shapes should return the size and position as shown in PowerPoint GUI.
This is what the GUI shows for the chart shapes (inside the grouped shapes).
This is what python-pptx returns when you look up the size and position of all the shapes on this slide:
Shape ID: 9, Name: Group 8, Pos=(493.2, 128.88), Size=(428.96 x 342.21)
(Group contains:)
Shape ID: 4, Name: Chart 3, Pos=(59.92, 200.16), Size=(474.32 x 301.17)
Shape ID: 5, Name: TextBox 4, Pos=(135.36, 129.6), Size=(318.96 x 31.59)
Shape ID: 10, Name: Group 9, Pos=(71.92, 122.4), Size=(360.8 x 343.41)
(Group contains:)
Shape ID: 11, Name: Chart 10, Pos=(59.92, 200.16), Size=(474.32 x 301.17)
Shape ID: 12, Name: TextBox 11, Pos=(135.36, 129.6), Size=(318.96 x 31.48)
Notice shape ID 4 & 11 have the same size/position, as does shape ID 5 & 12.
I believe this is the expected behavior.
Basically a shape within a group is located relative to the origin of the group. If you have a look at the XML I think that's what you'll find.
What it sounds like you're looking for is the absolute position of the shape, i.e. relative to the slide origin. This would be the origin of the group plus the origin of the grouped-shape.
It's arguable which is the better behavior. There are multiple use-cases, like manipulating a shape relative to the slide and manipulating it relative to the group.
As far as what would be correct, I'd say whatever the behavior of the Microsoft API for PowerPoint does, but that's probably a bit moot given we're probably unlikely to change what it is now.
In the meantime you could do the arithmetic yourself in cases where you want the absolute position. That would involve detecting when you were in a group of course, so not perfectly straightforward. Although the algorithm would in general be recursive, because groups can be inside groups and also the shape-tree in which a slide's shapes are contained is in fact a group as far as the XMLSchema is concerned.
@scanny Just to clarify — I understand why shapes inside a group have coordinates relative to the group’s origin vs. the slide’s origin. My question is - why do the children of the cloned group (right hand group) are still behaving as if they belong to the original (left hand group) group’s coordinate system.
when I copy-paste a grouped shape (as in the right-hand side of the image), the cloned grouped shape does have its own dimensions, but the shapes inside them don't use coordinates relative to the group itself, it uses the same dimensions as the original child shapes
To reproduce:
- On a blank slide, add two shapes (e.g., a chart and a textbox) and group them together.
- Copy the grouped shape to create a clone, then move the cloned group to a different position on the slide.
- Read the dimensions (size and position) of all shapes.
- The child shapes in both groups return the same dimensions — the cloned shapes return the same size/position as the originals, rather than reflecting their new location.
Expected: the child shapes in both groups should return dimensions relative to the grouped shape they are in.
Let's consider the following example:
- you have a group with origin at position 10, 10
- the group contains a square at position 1, 1 relative to the group, so absolute coordinates 11, 11
- you clone the group and move it to position 100, 10
The square in the cloned group still has position 1, 1 with respect to the new group, just its absolute (relative to slide) coordinates have changed to 101, 11.
Is this different from the behavior you're seeing?
That’s exactly I’m seeing. Sounds like I need to calculate the cloned square’s position using the cloned groups position relative to the slide.