Created attachment 149919 [details] Shape 'arc', file produced in Word 97 For the shape 'arc' MS Office uses the bounding rectangle of the sector as viewbox (frame rectangle, the rectangle with the resize handles). LibreOffice uses the bounding box of the entire ellipse. Both calculate the position relative to the left/top corner of this rectangle. Because the rectangle is different, the shape gets a different position in LibreOffice. Open the attached document in Word. The black rectangle marks the bounding rectangle of the entire ellipse. The sector is inside the rectangle. Click on the sector and notice the position of the left/top resize handle relative to the black rectangle. Now open the document in Writer. Notice, that the sector is shifted. Click on the sector and notice the resize handles. They are places at a rectangle, which has the size of the ellipse. Notice the left/top resize handle is still at the same place relative to the black rectangle.
Created attachment 150058 [details] Arc as decorative shape in page margin of Word-document The attached file shows problems with arcs, that are placed at the edge of a page. A simple movement does not work, because Writer does not allow part of the shape to be outside the page. Further problems occur, if the arc is part of a group or transformed by flip and rotation. In addition, MS Office counts always the entire arc including the center point in the size, even if the shape is unfilled and only the arc is drawn. It would be necessary to restrict the viewBox to the actual drawn sector or arc. But then the adjustment handles do not work correctly and there exist no UI for the user to manipulate the viewBox, when the angles are altered. A fix seems to be a large effort. Given that this particular shape is no longer used by today's OOXML format, it is questionable whether such an expense is even worthwhile.
A proposal for a fix is in https://gerrit.libreoffice.org/69829. Here are some details about that patch: The shape "mso_sptarc" behaves different than the other shapes in regard to size and position. All other shapes have a constant canvas onto which the outline is drawn. It does not change, when the user modifies the outline by using adjust handles. The position and size refer to this constant canvas. But position and size of the shape "mso_sptarc" refer to the current drawn sector and change, when the user adjusts start or end angle of the arc. And the shape "mso_sptarc" does not allow extrusion to 3D, which is possible for the other shapes. The shape "mso_sptArc" behaves similar to the primitive ellipse sector. But it can have a fill although the shape is not closed. It is written to file as custom shape by MS Office and exists this way in current MS Office versions. That makes it necessary to import it into a custom shape, the primitive ellipse sector is not sufficient. A custom shape has an internal coordinate system. The coordinates of points in path, gluepoints, handles and the internal text frames are given in that internal coordinate system. Custom shapes have a viewBox with values in this internal coordinate system. A custom shape has a 'frame' rectangle, that is the rectangle of the resize handles. The viewBox determines which rectangle in the inner coordinate system is mapped to the outer frame rectangle. MS Office uses for the shape "mso_sptArc" a coordinate system, where the underlying ellipse has width and height 43200 and the origin of the coordinate system is the left/top vertex of the enclosing rectangle of the current sector. The sector is used too, if the shape is not filled and only an arc is drawn. LibreOffice uses a coordinate system, where the underlying ellipse has width and height 21600 and the origin of the coordinate system is the left/top vertex of the enclosing rectangle of the ellipse. Therefore at least a coordinate transformation is necessary. All preset custom shapes in LibreOffice have a viewBox "0 0 21600 21600". Using the same transformation method as for other custom shapes, the frame rectangle encloses the entire underlying ellipse. As MS Office uses for the shape "mso_sptArc" a viewBox, which encloses only the current sector, an additional shift of the shape is necessary to put the sector to the same position as in MS Office. Impress allows parts of a shape to be outside the page area and the position of one object has no influence on other objects. Therefore in Impress it does not matter, if the shape is moved or has a wrong size. So I have kept the current solution for Impress. The position and size of objects affects the text layout in Writer. The current solution produces a shape which is too large compared with the shape in MS Word and thus not only the visible position or the shape is wrong, but the layout is effected too. Currently some problems have a workaround by tweaking with contour wrap. Therefore I have looked for a solution to get the same size and position as in MS Word, and have decided to manipulate the viewBox. The patch changes the viewBox for the "mso_sptArc" shape in case of import to Writer or Calc so that it encloses the sector. That way the frame rectangle for the "mso_sptArc" shape is the same as in MS Office and results in same position and text wrap behavior as in MS Office. The downside is, that the adjust handles can be moved outside the frame rectangle, because in contrast to MS Office the viewBox is fixed and will not adapt to the sector size. The handles still work, but it is not 'nice'. I had considered to use the area of the arc for the viewBox in case of an unfilled shape. Thus it would have been possible to put the shape near to the page edge. But that changes the outer size compared to MS Office and would influence the text wrap in Writer. Additional problem was, that currently changes to aBoundRect of DffObjData are not evaluated by Writer. So implementing a special solution for an unfilled arc would result in general changes in Writer. That's why I've abandoned the idea. Therefore the test document "Arc as decorative shape.." will still fail. Users might have aligned unfilled arcs to the page edge in MS Word by moving them partly out of the page area. But there are no bug reports so far. Documents which use that, seem to be rare. The problem of how to get the outline of a shape at the page edge, exists for the custom shapes 'Circle Pie', 'Circle Segment', 'Block Arc' and 'Circular Arrow' as well. Therefore I have nothing done to workaround it for the special case 'unfilled arc' of shape "mso_sptArc". I think it would be better to implement a general solution, for example implement a crop for shapes or find a way to allow such placement without breaking the layout algorithms. The shape "mso_sptArc" has handles in MS Office to adjust the angles. But the binary file format does not contain the needed equations and references but only the values at the time of saving. So drawing the shape with this information only, the user cannot change the shape outline. Therefore the 'msoArc' prototype of a custom shape with handles is used (definition in EnhancedCustomShapeGeometry.cxx) and that shape is adapted to the given size and angles. My patch does not change this concept. In case the text is rotated in Word, the text frame is wrong. But that is not a problem of this special "mso_sptArc" shape, but of other shapes too. Therefore the text frame errors are not addressed in this patch. Gluepoints of the shape are not kept. Therefore connectors to the shape do not keep the position. That problem exists already before my patch. My patch does not address it.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/5c725eb7dee248c6d1792a9b9b9a9c813ca627e6%5E%21 tdf#124029 Force correct import pos&size of mso_sptArc shape It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fix is available in Version: 6.3.0.0.alpha0+ (x64) Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04 Locale: de-DE (en_US); UI-Language: en-US Calc: threaded
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/20e5399cfecaa7ed825b399018ba7f655e58d54e Fix refs to tdf#124029 It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 87828 has been marked as a duplicate of this bug. ***