DOCX import: fix interaction between the crop and the wrap polygon of images

Word first applies the crop, then applies the wrap polygon on the
remaining visible part of the image.

Writer applies the crop on the original bitmap, and even has explicit
code to make sure the uncropped bitmap is used for the wrap polygon, see
how SwFlyFrame::GetContour() calls SwNoTextFrame::GetGrfArea(), which
will extend the resulting size based on cropping.

Fix the problem by moving and scaling the wrap polygon, so it ends up
where it would in Word.

Also adapt testFdo76803, which had a similar crop+wrap polygon case, but
the different there is quite small.

(cherry picked from commit 2abe9837deee3823c7928a76b5b2f94f1464f1a3)

Conflicts:
	writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx

Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94318
Tested-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

2 files changed, 29 insertions, 0 deletions

diff --git a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
index 92f059b9760a..0214f639bf53 100644
--- a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
+++ b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
@@ -17,8 +17,10 @@
 #include <com/sun/star/text/XTextTable.hpp>
 #include <com/sun/star/text/XTextTablesSupplier.hpp>
 #include <com/sun/star/container/XNamed.hpp>
+#include <com/sun/star/drawing/PointSequenceSequence.hpp>
 
 #include <comphelper/processfactory.hxx>
+#include <basegfx/polygon/b2dpolypolygontools.hxx>
 
 using namespace ::com::sun::star;
 
@@ -104,6 +106,33 @@ CPPUNIT_TEST_FIXTURE(Test, testInlineInShapeAnchoredZOrder)
     // i.e. the image was behind the textbox that was hosting it.
     CPPUNIT_ASSERT_EQUAL(OUString("Picture 1"), xOval->getName());
 }
+
+CPPUNIT_TEST_FIXTURE(Test, testWrapPolyCrop)
+{
+    OUString aURL = m_directories.getURLFromSrc(DATA_DIRECTORY) + "wrap-poly-crop.docx";
+    getComponent() = loadFromDesktop(aURL);
+    uno::Reference<drawing::XDrawPageSupplier> xDrawPageSupplier(getComponent(), uno::UNO_QUERY);
+    uno::Reference<drawing::XDrawPage> xDrawPage = xDrawPageSupplier->getDrawPage();
+    uno::Reference<beans::XPropertySet> xShape(xDrawPage->getByIndex(0), uno::UNO_QUERY);
+    drawing::PointSequenceSequence aContour;
+    xShape->getPropertyValue("ContourPolyPolygon") >>= aContour;
+    auto aPolyPolygon = basegfx::utils::UnoPointSequenceSequenceToB2DPolyPolygon(aContour);
+    CPPUNIT_ASSERT_EQUAL(sal_uInt32(1), aPolyPolygon.count());
+    auto aPolygon = aPolyPolygon.getB2DPolygon(0);
+    CPPUNIT_ASSERT_EQUAL(sal_uInt32(4), aPolygon.count());
+
+    // Ideally this would be 2352, because the graphic size in mm100, using the graphic's DPI is
+    // 10582, the lower 33% of the graphic is cropped, and the wrap polygon covers the middle third
+    // of the area vertically. Which means 10582*2/3 = 7054.67 is the cropped height, and the top of
+    // the middle third is 2351.55.
+    //
+    // Without the accompanying fix in place, this test would have failed with:
+    // - Expected: 2361
+    // - Actual  : 3542
+    // i.e. the wrap polygon covered a larger-than-correct area, which end the end means 3 lines
+    // were wrapping around the image, not only 2 as Word does it.
+    CPPUNIT_ASSERT_EQUAL(2361., aPolygon.getB2DPoint(0).getY());
+}
 }
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/writerfilter/qa/cppunittests/dmapper/data/wrap-poly-crop.docx b/writerfilter/qa/cppunittests/dmapper/data/wrap-poly-crop.docx
new file mode 100644
index 000000000000..1835a130d740
--- /dev/null
+++ b/writerfilter/qa/cppunittests/dmapper/data/wrap-poly-crop.docx