Fix a DPI-dependent test

It fails locally on Windows using 150% scaling with

- Expected: 9419
- Actual  : 9437

The original size of page in the PDF is 267.507 x 85.627 pt.
Converting that on 96 DPI gives 356.68 x 114.17 pixels. Without
rounding, that translated to 356 x 114 in vcl::RenderPDFBitmaps.

This adds rounding when calculating bitmap size, giving smaller
error (9446 hmm wide, less than 10 hmm from ideal 9437 mm/100,
compared to almost 20 hmm error before). Also it adds tolerance
to the unit test.

Change-Id: I3cd8f6c0e1235adf2fe1c17f4c56f3667f0132bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131110
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

1 files changed, 5 insertions, 3 deletions

diff --git a/filter/qa/pdf.cxx b/filter/qa/pdf.cxx
index ddf6c3bce066..bc8329d0116e 100644
--- a/filter/qa/pdf.cxx
+++ b/filter/qa/pdf.cxx
@@ -129,15 +129,17 @@ CPPUNIT_TEST_FIXTURE(Test, testPdfDecompositionSize)
     Graphic aGraphic(xGraphic);
     basegfx::B2DRange aRange = aGraphic.getVectorGraphicData()->getRange();
     // Without the accompanying fix in place, this test would have failed with:
-    // - Expected: 9419
+    // - Expected: 9437
     // - Actual  : 34176
     // i.e. the width was too large, it used all width of the body frame.
-    // 9419 mm100 is 267 points from the file.
+    // 9437 mm100 is 267.507 points from the file.
 #if defined MACOSX
     // TODO the bitmap size is larger (75486) on macOS, but that should not affect the logic size.
     (void)aRange;
 #else
-    CPPUNIT_ASSERT_EQUAL(static_cast<double>(9419), aRange.getWidth());
+    // Unfortunately, this test is DPI-dependent.
+    // Use some allowance (~1/2 pt) to let it pass on non-default DPI.
+    CPPUNIT_ASSERT_DOUBLES_EQUAL(9437, aRange.getWidth(), 20.0);
 #endif
 }
 }