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>

3 files changed, 37 insertions, 11 deletions

diff --git a/sw/qa/extras/ooxmlimport/ooxmlimport.cxx b/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
index cb53c31ccfa1..a80aff6ce770 100644
--- a/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
+++ b/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
@@ -645,8 +645,12 @@ DECLARE_OOXMLIMPORT_TEST(testBnc779620, "bnc779620.docx")
 DECLARE_OOXMLIMPORT_TEST(testTdf105127, "tdf105127.docx")
 {
     auto aPolyPolygon = getProperty<drawing::PolyPolygonBezierCoords>(getShape(1), "PolyPolygonBezier");
-    // This was 1910, the shape was rendered upside down.
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(3257), aPolyPolygon.Coordinates[0][0].Y);
+    // tdf#106792 These values were wrong all the time due to a missing
+    // conversion in SvxShapePolyPolygon::getPropertyValueImpl. There was no
+    // ForceMetricTo100th_mm -> the old results were in twips due to the
+    // object residing in Writer. The UNO API by definition is in 100thmm,
+    // thus I will correct the value here.
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(5744), aPolyPolygon.Coordinates[0][0].Y); // was: 3257
 }
 
 DECLARE_OOXMLIMPORT_TEST(testTdf105143, "tdf105143.docx")
@@ -1063,8 +1067,17 @@ DECLARE_OOXMLIMPORT_TEST(testTdf85232, "tdf85232.docx")
     uno::Reference<drawing::XShapeDescriptor> xShapeDescriptor(xShape, uno::UNO_QUERY);
     // Make sure we're not testing the ellipse child.
     CPPUNIT_ASSERT_EQUAL(OUString("com.sun.star.drawing.LineShape"), xShapeDescriptor->getShapeType());
-    // This was 2900: horizontal position of the line was incorrect, the 3 children were not connected visually.
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(2267), xShape->getPosition().X);
+
+    // tdf#106792 checked that during load of tdf85232.docx the method
+    // SvxShapePolyPolygon::setPropertyValueImpl is used three times. In
+    // that method, a call to ForceMetricToItemPoolMetric was missing so
+    // that the import did not convert the input values from 100thmm
+    // to twips what is needed due to the object residing in Writer. The
+    // UNO API by definition is in 100thmm. Result is that in SwXShape::getPosition
+    // the offset (aOffset) now is (0, 0) instead of an existing offset in
+    // the load of the document before (what is plausible for a GroupObject).
+    // Thus, I will adapt the result value here to the now (hopefully) correct one.
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1630), xShape->getPosition().X); // was: 2267
 }
 
 DECLARE_OOXMLIMPORT_TEST(testTdf95755, "tdf95755.docx")
diff --git a/sw/qa/extras/ooxmlimport/ooxmlimport2.cxx b/sw/qa/extras/ooxmlimport/ooxmlimport2.cxx
index bea30cf86716..001c188be2fc 100644
--- a/sw/qa/extras/ooxmlimport/ooxmlimport2.cxx
+++ b/sw/qa/extras/ooxmlimport/ooxmlimport2.cxx
@@ -189,7 +189,12 @@ DECLARE_OOXMLIMPORT_TEST(testTdf113182, "tdf113182.docx") { CPPUNIT_ASSERT_EQUAL
 DECLARE_OOXMLIMPORT_TEST(testTdf113946, "tdf113946.docx")
 {
     OUString aTop = parseDump("/root/page/body/txt/anchored/SwAnchoredDrawObject/bounds", "top");
-    CPPUNIT_ASSERT_EQUAL(OUString("1696"), aTop);
+    // tdf#106792 Checked loading of tdf113946.docx. Before the change, the expected
+    // value of this test was "1696". Opening the file shows a single short line anchored
+    // at the doc start. Only diff is that in 'old' version it is slightly rotated, in 'new'
+    // version line is strict hiorizontal. Checked against MSWord2013, there the line
+    // is also not rotated -> the change is to the better, correct the expected result here.
+    CPPUNIT_ASSERT_EQUAL(OUString("1695"), aTop);
 }
 
 DECLARE_OOXMLIMPORT_TEST(testTdf114217, "tdf114217.docx")
diff --git a/sw/qa/extras/rtfimport/rtfimport.cxx b/sw/qa/extras/rtfimport/rtfimport.cxx
index 10c32eb50c50..c7d2a2ca2af3 100644
--- a/sw/qa/extras/rtfimport/rtfimport.cxx
+++ b/sw/qa/extras/rtfimport/rtfimport.cxx
@@ -1244,13 +1244,21 @@ DECLARE_RTFIMPORT_TEST(testTdf90097, "tdf90097.rtf")
     uno::Sequence<uno::Sequence<awt::Point>> aPolyPolySequence;
     xShape->getPropertyValue("PolyPolygon") >>= aPolyPolySequence;
     uno::Sequence<awt::Point>& rPolygon = aPolyPolySequence[0];
+
+    // tdf#106792 These values were wrong all the time due to a missing
+    // conversion in SvxShapePolyPolygon::getPropertyValueImpl. There was no
+    // ForceMetricTo100th_mm -> the old results were in twips due to the
+    // object residing in Writer. The UNO API by definition is in 100thmm,
+    // thus I will correct the values here.
+    // Indeed need to use the Linux values, I have no idea why these differ
+    // from Mac/Win ones, but the disable above hints to that (maybe a problem
+    // of it's own). Factor between Twips and 100thmm is ca. 1.76 -> stable change
+
     // Vertical flip for the line shape was ignored, so Y coordinates were swapped.
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(2819), rPolygon[0].X);
-    // This was 1619.
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1963), rPolygon[0].Y);
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(3181), rPolygon[1].X);
-    // This was 1962.
-    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1620), rPolygon[1].Y);
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(4972), rPolygon[0].X); // was: 2819, win is 10927
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(3463), rPolygon[0].Y); // was: 1963
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(5617), rPolygon[1].X); // was: 3181, win is 11572
+    CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(2852), rPolygon[1].Y); // was: 1620
 }
 #endif