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.

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

2 files changed, 30 insertions, 0 deletions

diff --git a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
index 590a93273e92..7648d9e9420d 100644
--- a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
+++ b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
@@ -15,6 +15,9 @@
 #include <com/sun/star/frame/Desktop.hpp>
 #include <com/sun/star/container/XNamed.hpp>
 #include <com/sun/star/text/RelOrientation.hpp>
+#include <com/sun/star/drawing/PointSequenceSequence.hpp>
+
+#include <basegfx/polygon/b2dpolypolygontools.hxx>
 
 using namespace ::com::sun::star;
 
@@ -134,6 +137,33 @@ CPPUNIT_TEST_FIXTURE(Test, testRelfromhInsidemargin)
     xShape->getPropertyValue("PageToggle") >>= bPageToggle;
     CPPUNIT_ASSERT(bPageToggle);
 }
+
+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