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