Description: muddy fonts in LibreOffice GUI with 125% scale in Windows 10 it's a regression Steps to Reproduce: 1. Make sure you use 125% scale in OS Windows 2. Open LibreOffice in Start Screen 3. Look at fonts Actual Results: muddy fonts in LibreOffice GUI with 125% scale in Windows 10 Expected Results: good fonts in LibreOffice GUI with 125% scale in Windows 10 Reproducible: Always User Profile Reset: No Additional Info: Версия: 6.4.0.0.alpha0+ (x64) ID сборки: ccfbe8b478f3daa8b5ec07a7e48dd5fbf8556811 Потоков ЦП: 4; ОС:Windows 10.0 Build 18362; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded
Created attachment 154985 [details] Screenshot
Confirmed Windows 10 Home 64-bit en-US with Version: 6.4.0.0.alpha0+ (x86) Build ID: 2ef2c031ce9ec730b13fca8bca808f382aab5fe4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Default GDI rendering also affected. As compared to 100% scaling (my default) moving to 125%, or 150% the font rendering has gotten very 'fuzzy' Seems recent issue, not sure when as I don't scale os/DE UI above 100% often.
Unfortunately, both Roman and myself get nonsensical results when bibisecting this!
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=1144712bb99cfb699e73b473ee44351c50a35613 author Szymon Kłos <szymon.klos@collabora.com> 2019-10-28 10:19:50 +0100 committer Szymon Kłos <szymon.klos@collabora.com> 2019-10-28 12:33:49 +0100 commit 1144712bb99cfb699e73b473ee44351c50a35613 (patch) tree 6b34143b3a14664448c96da79cc788bb4f2afb31 parent 6385e04f7e194ce6dcc82588f38355b467d0d276 (diff) jsdialogs: make possible to set .uno:BackgroundColor in Writer Bisected with: bibisect-linux64-6.4 Adding Cc: to Szymon Kłos
oh wait, my bisection was for bug 128593, not for this one...
(In reply to Buovjaga from comment #3) > Unfortunately, both Roman and myself get nonsensical results when > bibisecting this! Sharing those nonsensical results might still be helpful, as an indication. Like this one: https://cgit.freedesktop.org/libreoffice/core/log/?id=d4ad516bc0607a1d84451dd3dc8811a4f801fa4c
(In reply to Aron Budea from comment #6) > (In reply to Buovjaga from comment #3) > > Unfortunately, both Roman and myself get nonsensical results when > > bibisecting this! > Sharing those nonsensical results might still be helpful, as an indication. > Like this one: > https://cgit.freedesktop.org/libreoffice/core/log/ > ?id=d4ad516bc0607a1d84451dd3dc8811a4f801fa4c yep, I got this sha d4ad516bc0607a1d84451dd3dc8811a4f801fa4c five time=(
That bibisect result was really puzzling and it's actually correct. I also reproduced it :-) I guess the bibisect repository is build incrementally without a "make clean", so it took a while, until soffice.bin needed to get linked again, which has caused this bug. Changing the text of a central header like include/osl/file.h* was the trigger for an almost full rebuild of LO. The breaking commit is: commit 7f791f431c79c6d0a156c4a2726a0dfc5ff40cc1 Author: Luboš Luňák <l.lunak@collabora.com> Date: Tue Oct 8 20:14:31 2019 +0200 filter out the "Creating library" message from link.exe The filtering command in the Makefile has an exit "${PIPESTATUS[0]}", which will exit the gb_LinkTarget__command macro after calling the linker. As a result the DeclareDPIAware.manifest isn't merged into the linked binaries, so Windows applies System DPI scaling. I first just checked soffice.exe, which was correct before and after the breaking commit. And it took me a while to realize, that the incremental build slowly lost its "dpiAware" manifest on all the executables and the problematic one is actually soffice.bin. The proposed patch is: https://gerrit.libreoffice.org/#/c/84099/ I'm not really familiar with AWK scripting, so can currently just say, that the regexp based filtering still works for me in my German Windows locale. Maybe the bug should be more important. OTOH bug 122218 isn't fixed since a year on MacOS, which - I guess - is some similar problem.
(In reply to Jan-Marek Glogowski from comment #8) > I guess the bibisect repository is build incrementally without a "make > clean", so it took a while, until soffice.bin needed to get linked again, > which has caused this bug. Changing the text of a central header like > include/osl/file.h* was the trigger for an almost full rebuild of LO. ... so there's a problem in bibisect commit creation, which needs a make clean each time, or at least when an .mk/autogen/configure change is detected ... :-)
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d10db7846602c16701dde019f12f61fd536e9ae4 tdf#128133 WIN don't exit after link-output filter It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified, thanks! Version: 6.5.0.0.alpha0+ (x64) Build ID: 9ab43aebad67383057d2cc3f754ce2193fa78b4e CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
Verified, looks to also have helped the Skia/Vulkan rendering. On Windows 10 Home 64-bit en-US (1903) at 150% with Version: 6.5.0.0.alpha0+ (x64) Build ID: 9ab43aebad67383057d2cc3f754ce2193fa78b4e CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/a88f11f89ea2f048be4aba24513f4bae51c81ffb tdf#128133 WIN don't exit after link-output filter It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.