Description: Many of the unit tests (specially on Windows) are dependent on DPI and scaling. If you set display scaling to something other than 1x (100%), like 2x (200%) or 3x (300%) scaling, and run 'make check', you will see those tests fails. If you switch back to 1x (100%) scaling, those test should pass. The task here is to fix such tests. As an example, one can take a look at some of the previous patches that provided such fixes: (thanks Ilmari for the hint) $ git log --grep=dpi -i '*/qa/*.cxx' The best would be to create a test independent of DPI: 3ffd375ffee648cdb67b1f3062f84a4b2f3af9df In some cases, changing some error margin (more tolerance) helps: b693d19884a09b5f841b30f2e8b586778584ed16 Sometimes, tests can be skipped with non-default DPI: c469e786be9345fc76e5cc62fd23dd317db53c02 Please note that there are many DPI-dependent aspects in LibreOffice. Therefore, sometimes a bug fix might be needed to make the test work. The ultimate goal of this issue is to be able to run 'make check' successfully on different display DPI and scaling.
To find a problematic test, first you should rung 'make check' with 1x (100%) scaling. You have to make sure that no test fails. Then, you should set the screen scaling to something other than 1x (100%), and then run 'make check' again. Once a test case fails, you can remove it from the source code, or the make file, and then try again running that test again. If the test does not fail again, this means that the test was related to DPI. These are some of the tests that fail because of DPI, alongside the source code/make file: (Note: it is not complete) make JunitTest_sot_complex complex.olesimplestorage.OLESimpleStorageUnitTest sot/JunitTest_sot_complex.mk make CppunitTest_sd_a11y TestImpressDefaultStructure TestImpressDefaultLayout sd/qa/unit/a11y/layout.cxx make CppunitTest_sc_shapetest testTdf144242_Line_noSwapWH sc/qa/unit/scshapetest.cxx make CppunitTest_sc_a11y Test64BitChildIndices TestCalcMenu sc/qa/extras/accessibility/basics.cxx make CppunitTest_sw_rtfexport2 testFdo52989 sw/qa/extras/rtfexport/rtfexport2.cxx make CppunitTest_sd_png_export_tests testTdf99729 testTdf126319 testTdf105998 sd/qa/unit/PNGExportTests.cxx make CppunitTest_sw_rtfexport8 testTdf155663 make CppunitTest_sw_ooxmlexport6 testDmlRectangleRelsize sw/qa/extras/ooxmlexport/ooxmlexport6.cxx make CppunitTest_sw_uiwriter6 testTdf160836 sw/qa/extras/uiwriter/uiwriter6.cxx make CppunitTest_sw_layoutwriter2 testTdf129054 sw/qa/extras/layout/layout2.cxx
These are the remaining failing tests with 3x scaling on Windows. First is the name of the test, then the failing test cases, and at last, the file that can be used to disable the test: make CppunitTest_sw_layoutwriter3 testTdf147666 testTdf159422 sw/qa/extras/layout/layout3.cxx make CppunitTest_sc_tabviewobj sc_apitest::ScTabViewObj::testSplit test/source/sheet/xviewsplitable.cxx make JunitTest_svx_unoapi svx.AccessibleShape svx/qa/unoapi/svx.sce make JunitTest_chart2_unoapi sch.ChartArea chart2/qa/unoapi/sch.sce make JunitTest_linguistic_unoapi lng.LinguProps linguistic/qa/unoapi/lng.sce make JunitTest_comphelper_complex comphelper/qa/complex/comphelper_all.sce make JunitTest_configmgr_unoapi org.openoffice.test.UnoApiTest configmgr/JunitTest_configmgr_unoapi.mk make JunitTest_dbaccess_unoapi complex.dbaccess.Beamer dbaccess/JunitTest_dbaccess_unoapi.mk make JunitTest_chart2_unoapi org.openoffice.test.UnoApiTest solenv/gbuild/JunitTest.mk Some complex test like JunitTest_unoxml_complex, JunitTest_sfx2_complex, JunitTest_dbaccess_complex, JunitTest_comphelper_complex and also CppunitTest_sw_a11y also fail, which may not be related to DPI. Please note that it is not guaranteed that all of the above tests are DPI related. Anyway, by disabling the above tests, you should be able to run 'make check' on a Windows machine with scaling other than 1x.
I recently tried building LibreOffice for the first time and noticed that some tests in chart2import2.cxx, specifically testTdf133376, testTdf136105, and testTdf136752 were consistently failing: https://paste.debian.net/1323698/ Hossein advised me in IRC that this is likely because of this bug (I’m running macOS on a 2019 16" Retina MacBook Pro). The first two of these tests include this check, which is not working properly on my machine: // FIXME: the DPI check should be removed when either (1) the test is fixed to work with // non-default DPI; or (2) unit tests on Windows are made to use svp VCL plugin. if (!IsDefaultDPI()) return; testTdf136752 is missing this check. I spent several hours trying to figure out why this check is not working properly. Unfortunately this was somewhat difficult given by unfamiliarity with this codebase and I don’t currently have a fix. Here are my notes: https://docs.google.com/document/d/1At9aFXqVLQc_k82P5Qu3E0MYd5KZpGZkHvKQAxO5Mj0/edi I concluded: It seems that my Mac (a 2019 16” Retina MacBook Pro) using HiDPI mode is causing some sort of problem with the test case. However, the test harness is calling Application::EnableBitmapRendering() and seems to be running in some sort of headless mode where IsDefaultDPI() returns “true.” Potential fixes: 1. Fixing the tests to run properly in HiDPI mode (preferable) 2. Fixing the headless mode to report the DPI properly 3. Changing the test harness to create a window and avoid using the logic for the headless case
Sorry, the link should be: https://docs.google.com/document/d/1At9aFXqVLQc_k82P5Qu3E0MYd5KZpGZkHvKQAxO5Mj0/edit