Separated from bug 82021 because another issue: 1. Make Draw document like attachment 116728 [details]. 2. copy all and paste in new Writer document 3. save Writer Document as docx and reopen Example that's enough to test is attachment 116727 [details]. Used to be wrong in 4.x, than OK with 6.0+ and wrong again, test with 7.0+.
Created attachment 158598 [details] Sample DOCX compared MSO LO Problem here is not save to DOCX, because MSO opens that DOCX fine, but reopen from LO. So, attached DOCX is valid. It's the same with DOCX saved with 7.0+. As seen, reopen was OK with LO 6.0+. So regression.
a35ab2611687602ed7c0b9856f2ced2278e31112 is the first bad commit commit a35ab2611687602ed7c0b9856f2ced2278e31112 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jul 2 18:38:24 2018 +0200 source 36bade04d3780bc54c51b46bb0b63e69789658a5 Previos commit b47996947c116b1a7b30f6e1352b40aac068cb0c (HEAD, refs/bisect/good-b47996947c116b1a7b30f6e1352b40aac068cb0c) Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jul 2 17:20:22 2018 +0200 source 942f1056b51e53358d42ff8da8a1bbdce9ba5303 Single source: commit 36bade04d3780bc54c51b46bb0b63e69789658a5 [log] author Armin Le Grand <Armin.Le.Grand@cib.de> Thu Jun 28 19:48:59 2018 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> Mon Jul 02 18:03:44 2018 +0200 tree c4465bf33aa2cda65511a2c094688522e9c9b43a parent 942f1056b51e53358d42ff8da8a1bbdce9ba5303 [diff] tdf106792 Get rid of SvxShapePolyPolygonBezier SvxShapePolyPolygonBezier was an implementation for the UNO Shape group of polygons with bezier parts (filled/unfilled/ closed/open), e.g. com.sun.star.drawing.OpenBezierShape. It was differing from SvxShapePolyPolygon just by supporting drawing::PolyPolygonBezierCoords instead of the simple drawing::PointSequenceSequence and some details. This leads to problems - the ShapeType *does change* e.g. when you edit a non-bezier Shape in Draw/Impress and change parts to curve (also when closing, see ShapeTypes above). This is why SvxShape::getShapeType() already detects this identifier by using thze internal ShapePolyType (e.g. OBJ_PATHLINE). So there is no reason to have two separate UNO API imple- mentations for sthe same type of SvxShape at all. Get rid of the extra one and unify this implementation detail. Also cleaned up double basegfx tooling for conversions of UNO API Poly/bezier data and B2DPolygon. Adapted test for "tdf113946.docx", see comment there. Adapted test for "tdf90097.rtf", see comment there. Also needed to use the Linux values, also check comment there. Adapted test for "tdf105127.docx", see comment there. Adapted test for "tdf85232.docx", see comment there. Had to fic a problem with test for "tdf96674.docx"- the adaption of the RotateAngle for line objects goes havoc together with the UNO API when scaling is involved. That old aGeo rotate stuff just kills the existing rotation due to numerical inprecise stuff. The UNP API - in trying not just to apply a rptation, but manipulate the existing one then goes wrong in not re-getting the current rotation value anymore. ARGH! This is the original reason for the ols tdf#96674 task - i doubt that the additional code to make a line not exactly hor/ver is needed. Checked and it is not needed, thus removed the change from tdf#96674 in shape.cxx. Change-Id: I2bb8d4cfe33fee3671f3dad60e5c18609a394f9d Reviewed-on: https://gerrit.libreoffice.org/56614 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de> New by bibisect. But this source is mentioned in: bug 118693 bug 96640 bug 127555 bug 122717 bug 127370 and duplicate in bug 127364 from fix in bug 106792 So, likely a duplicate.
Let's keep separated so far but related to bug 96640 which is also about docx.
Hi Armin, please see this bug because source commit is mentioned in more bibisects.
*** This bug has been marked as a duplicate of bug 118693 ***