Description: If DOCX has arc shapes placed on drawing surface, LO converts arcs to Pie. Arc rotated by ~45 degrees in MSO is only rotated about 12 degrees in LO. Steps to Reproduce: Open attached DOCX sample Actual Results: Arcs looks like Pies; pie on the right rotated about 12 degrees. Expected Results: Arcs look like arcs. Arc on the right rotated about 45 degrees. Reproducible: Always User Profile Reset: No Additional Info: This is extracted/isolated from tdf#109129
Created attachment 172248 [details] DOCX sample
Created attachment 172249 [details] How it looks in MSO
Created attachment 172250 [details] How it looks in LO 7.2 master from May 22, 2021
I confirm the problems. Problem 1: It is not an arc. I see that error already in version 5.4.7. It should be either an EllipseShape with CircleKind_ARC or a CustomShape with type ooxml-arc. Instead it is an OpenBezierShape. I get that error too, if I create such shapes from scratch in Word. Problem 2: The rotation is wrong. In version 6.4.5 was no rotation at all. If I create a new file, the rotation is correct. I do not see at a glance, what makes your file different. The problems do only occur, if the shapes are placed on a drawing canvas. If the shapes are used without drawing canvas, they are imported correctly as arc and with the correct rotation. [To use a drawing canvas in Word 365, open menu Insert, then drop-down list Shapes. As last item in that list you find "New Drawing Canvas".] I see no connection to bug 109129, but use the META DOCX-Canvas-Shape instead. If you do not agree with that change, please explain why this should block bug 109129
(In reply to Regina Henschel from comment #4) > I see no connection to bug 109129, but use the META DOCX-Canvas-Shape > instead. If you do not agree with that change, please explain why this > should block bug 109129 I've made an isolated case based on the problem observed in 109129. I'm not an SME on MOOX. If you believe this one is different from misplaced/"pie"-ed arcs in the sample from 109129 -- you are probably right.
Further analysis results: The element <wpc:wpc> is used for the drawing canvas. This is not implemented at all in LibreOffice. So LibreOffice uses the <mc:Fallback> part of the <mc:AlternateContent> element. It has the drawing canvas as <v:group> and the arc objects as <v:shape>. The geometry is given in the 'style' and the 'path' attribute. The 'path' attribute describes the path by commands followed by coordinates. They allow building subpaths and disabling fill and stroke for each individual subpath. Currently LibreOffice uses the SdrPathObj. That corresponds to ODF element 'draw:path' and that uses svd:d to describe the path. The SdrPathObj is unsuitable here, because svd:d does not allow to set 'filled' and 'stroked' for individual subpaths. The implementation of LibreOffice for 'draw:path' does not allow mixed open and closed subpaths. The needed path features are available in custom shapes. So that has to be used in case the vml path has ns or nf or mixed open and closed subpaths. But pure vml graphic occurs not often nowadays, because MSO uses it mostly as fallback. So priority should be to implement import of <wpc:wpc>. From point of LibreOffice that element acts similar to a group. The <mc:Fallback> has no information, that it is ersatz for an arc and does not know anything about handles. So improving that part would not result in the same object as in Word. The wrong rotation happens in https://opengrok.libreoffice.org/xref/core/oox/source/vml/vmlshape.cxx?r=a0656ec6#1089 The rotation angle in the example file is "2955973fd" and maRotation contains it as that. toDouble converts it to 2955973.0 "fd" means, that it in deg*2^16. The correct angle in deg100 is already in Prop_RotateAngle. Either that is used or here again the convertion from https://opengrok.libreoffice.org/xref/core/oox/source/vml/vmlshape.cxx?r=a0656ec6#696 has to be used again.
(In reply to Valek Filippov from comment #5) > I've made an isolated case based on the problem observed in 109129. > I'm not an SME on MOOX. > If you believe this one is different from misplaced/"pie"-ed arcs in the > sample from 109129 -- you are probably right. No, you are right. The arcs in 'Figura 6' have the same problems as in your example document. I'll add the depedency again.
(In reply to Regina Henschel from comment #6) > Further analysis results: > The element <wpc:wpc> is used for the drawing canvas. This is not > implemented at all in LibreOffice. So LibreOffice uses the <mc:Fallback> > part of the <mc:AlternateContent> element. It has the drawing canvas as > <v:group> and the arc objects as <v:shape>. The geometry is given in the > 'style' and the 'path' attribute. Ok. I guess that could be the reason for tdf#142408 and few other issues in the original tdf#109129. Could you look if tdf#142408 is solvable with less efforts?
(In reply to Valek Filippov from comment #8) > Could you look if tdf#142408 is solvable with less efforts? I'm not an expert for text related problems. But I knew, that there exist problems with text rotation and writing direction outside of drawing canvas too, so likely not "less efforts".
The wrong rotation is duplicate to bug 137314, which I have fixed now.
Created attachment 185053 [details] Arcs with arrows LO 7.4.5 vs Word The bug is still in LO 7.4.5. This attachment shows arcs with modified start and end angles (I use that often to represent angles, as in the picture) and with an arrow end. Notice the "pie" lines that go to the arc center have an arrow in one of the segments. The "camera" object also appears rotated 90 deg extra in LO, but that is a different issue.