https://issues.apache.org/ooo/show_bug.cgi?id=124084
--- Comment #15 from Armin Le Grand <[email protected]> --- @Regina: You can find it starting at the four cases 'OWN_ATTR_BASE_GEOMETRY', two for bezier and two for non-bezier. These use SdrPathObj::TRGetBaseGeometry and SdrPathObj::TRSetBaseGeometry where on the latter you can read in the comment: // sets the base geometry of the object using infos contained in the homogen 3x3 matrix. // If it's an SdrPathObj it will use the provided geometry information. The Polygon has // to use (0,0) as upper left and will be scaled to the given size in the matrix. Thus, to write the polygon in the currently used form in ODF, you need two things: (a) the normalized, but scaled PolyPolygon [0.0 .. fabs(scale)] in X and Y (b) the complete transformation The viewBox will then use the [0.0 .. fabs(scale)] range and the polygon will also use that form. This makes the PolyPolygon definition in the ODF independent of the transformation, except the scale which is there for historical reasons (already explained). There is one more caveat with beziers: the BoundRect and thus the scale used for the bezier is without the control points (also due to what the original implementors did). This makes the BoundRect unfortunately non-trivial to calculate since the bezier needs to be split at it's exreama points to getthe correct BoundRect. See getRange and getRangeWithControlPoints in basegfx for more info. History: When the integer polygons were used this was done by using a copy of the polygon converted to line segments, with the result that the BoundRect was always wrong by +-10 100thMM units since that adaptive subdivision is always only a approximation. Thus, the geometry changed slightly at each save/reload... Again: Please do *not* add a 'M 0 0', this will add extra geometry to the polygon which leads to other problems later. This was already done in other circumstances and is known to have its own problems. What you do when adding this is to make the polygon seemingly conform to the requirements by always giving it a minX and minY at (0,0), but thats not a good thing to do. Instead, the transformation and viewBox needs to be correctly adapted, e.g. for a polygon having a BoundRect with a MinX of 100 and a minY of 200 to really use that in the transformation ad viewBox. This is not done in the nitial examples and that is the problem there. @JP CASSOU: Looks pretty good, but as desribed above: The BoundRect needs to be the BoundRect of the curve without the control points, but including the extremas. This makes it not easy to calculate, but is what the initial implementors defined. To see how to do that, plesae refer to the module 'basegfx' of AOO, the classes B2DPolygon, B2dPolyPolygonn and the methods getRange and getRangeWithControlPoints there. These use a temporary split of the bezier at the exreamas to ensure the correct calculation of the BoundRect without the control points. HTH! -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
