DOCX export: fix interaction between the crop and the wrap polygon of image

If the wrap polygon is influenced by crop at import time, we need to do
the opposite at export time.

Do this for RTF and DOCX, where there is matching import code in
writerfilter/, leave DOC alone for now.

Test this by changing testFdo76803 into an export test, then seeing how
the first point's Y position fails and fixing up the exporter, so we
get back the old good value.

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

1 files changed, 3 insertions, 2 deletions

diff --git a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
index 7648d9e9420d..28a0cc178410 100644
--- a/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
+++ b/writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
@@ -156,13 +156,14 @@ CPPUNIT_TEST_FIXTURE(Test, testWrapPolyCrop)
     // 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.
+    // Then there is a 15 twips shift from the origo, so it's 2351.55 + 26.46 = 2378.01 in mm100.
     //
     // Without the accompanying fix in place, this test would have failed with:
-    // - Expected: 2361
+    // - Expected: 2368
     // - 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());
+    CPPUNIT_ASSERT_EQUAL(2368., aPolygon.getB2DPoint(0).getY());
 }
 }