https://issues.apache.org/ooo/show_bug.cgi?id=124084
--- Comment #20 from Armin Le Grand <[email protected]> --- To make things more clear, another explanation (hopefully simpler): The representation of a draw shape containing a path in ODF format uses basically two objects: (a) The DrawObject itself containing the object transformation, either as x,y,width,height or as transformation if more aspects as translate and shear are used. It has to be split to x,y and a transformation part when mirror x/y (negative scales), rotation or shear is used. This is because: The object transformation is seen as the transformation from object unit coordinates (the object is at 0,0 and has size 1,1) to the target transformation; the x,y represents the translation, the width,height the scale. There is a logical order in which the aspects are applied: - scale - mirror - shear - rotate - translate This comes from simple considerations; scaling only works as long as the object is at (0,0); shear and rotate has to be done around top-left, so this has to be (0,0); shear defines the relation between the X and Y axes, thus is only useful before rotation. In ODF when x,y, width, height and transformation would be used the order of applying to builtd the whole object transformation would be: scale width/height, move x,y, apply transformation. The problem here is that translation would be added *before* the transformation which contains evtl. rotation/shear. To solve this, x,y has to be 0 in those cases and the translation part has to be moved to ODFs transformation part to apply it after the roation/shear parts. (b) the path geometry. This is in principle the path geometry in object unit coordinates (the object is at 0,0 and has size 1,1). For historical reasons (integer transport) the scale is included, so path data has a bound rect of (0, 0, width, height). This also defines that the path geometry always has a minX and minY of 0. Imagine the path geometry being transformed by first removing it's own scaling again and then applying the complete object transformation (see (a)). The viewBox part of this then also has a x,y of 0, thus this is practically not used in ODF. The only part of viewBox that is used is the width/height part. If this is different from the objects (a) width,height a scaling will be applied to the path geometry. The BoundRect used from the path geometry is *without* control points for historical reasons; to calculate this see tipps in comments above. Do *not* simply build the BoundRect including the control points if a bezier is used (!) I hope this makes the relationships clearer and why viewBox is a not needed part in ODF for path objects at all. -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
