Description: When viewing text documents at a zoom factor of 160% or greater, the red wavy line indicating misspelt words is not visible. Steps to Reproduce: 1. Turn Automatic Spell Checking on 2. Type a mispelt word 3. Zoom out to a factor of 160% or greater Actual Results: Red wavy lines disappear Expected Results: Red lines should remain Reproducible: Always User Profile Reset: Yes Additional Info: --
Confirm Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 102846d45cb9660805e209b6954c7b8d707b8288 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded fine with Skia Raster rendering
No issue with Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
*** Bug 153230 has been marked as a duplicate of this bug. ***
Heiko, I haven't bibisected but I'm wondering if this has to do with the fix for bug 70519 that made it into 7.3? https://git.libreoffice.org/core/commit/4141c13da8245b5ed46be3b7034d014d75f433f9 Cheers!
NO not Reproduced Steps to Reproduce: 1. Turn Automatic Spell Checking on 2. Type a mispelt word 3. Zoom out to a factor of 160% or greater Actual Results: Red wavy lines disappear Expected Results: Red lines should remain Actual Result and Expected Result mached Environment: Linux Mint 21 Cinnamon Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620ad1b7ae06d6f053fb2c9b57af96b736c04e57 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
The disappearing of the red line is a combination of selected font and zoom factor. On my MacBook 16, font Arial shows the bug at zoom 122%. Font Monaco raise the problem at 99%. Maybe the selected screen resolution is a second factor.
(In reply to Stéphane Guillou (stragu) from comment #4) > I'm wondering if this has to do with the fix for bug 70519 Yes, after reverting this code wavy lines are drawn at 160%. However, after undoing everything and recompiling the original source code everything works well too!
(In reply to Heiko Tietze from bug 70519 comment 14) > ...patch at https://gerrit.libreoffice.org/c/core/+/125038 does is to take the > zoom factor into account and increase the line size and wavyness. Drawback > is that it becomes cut-off on huge zoom levels. The calculation rounds >150 to a line width >1, which obviously fails. We can revert the patch and find alternatives for bug 70519, depending on priority.
*** Bug 151972 has been marked as a duplicate of this bug. ***
No repo on Windows OS: Version: 7.4.4.2 (x64) / LibreOffice Community Build ID: 85569322deea74ec9134968a29af2df5663baa21 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b4dc43b6d01d85802d5674c3a27789d6354e39a8 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
That’s because it is a macOS relevant bug as mentioned in the title.
Dup of bug 138918?
(In reply to Heiko Tietze from comment #12) > Dup of bug 138918? This one is a 7.3 regression that is so far macOS-specific and not reproduced with skia/raster, whereas bug 138918 is an older one, seen on Windows, and reproduced with skia/raster. Not dupes in my opinion.
Created attachment 194698 [details] Screenshot of red underlining with different zoom factor I have tested this now with 3 laptops (two with Intel, one with M1; 2 with newest macOS, one with 11.7) and even with the M1 with one external screen. I also see the red lining using 24.2 release with different thickness when zooming in (100%+; see screenshot). The lining disappear at ~29% (so a nearly unreadable small text). Is the bug fixed "by accident"?
I can still reproduce in 24.2.2 at 490% zoom with Liberation Serif 12 pt on Catalina. Will try a daily build next.
In a recent 25.2alpha0+ daily build: - disappears at 45% (I guess that's fine, given how small that is. I also see it disappearing at 33% on Linux.) - instead of disappearing at 490% as in comment 15, it suddenly gets a lot thicker, and then back to thin at 550%. So I think the issue is still curent: inconsistencies in visibility and thickness in macOS.
I did a bibisection on the thickness (not seeing the disappearance on my macs). There were many different states and bug fixes and so on... But in the end, the first, the initial bad commit was Heiko's commit (already mentioned in comment 4 and in comment 8) https://git.libreoffice.org/core/+/4141c13da8245b5ed46be3b7034d014d75f433f9
(In reply to Dennis Roczek from comment #17) > ...the first, the initial (bad) commit was Heiko's... You mean the fix for bug 70519.
(In reply to Heiko Tietze from comment #18) > (In reply to Dennis Roczek from comment #17) > > ...the first, the initial (bad) commit was Heiko's... > You mean the fix for bug 70519. Hence removing bisectrequest & regression from the keywords.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/baf95a7e8e7312891aed73adb26de74e5bc9ad62 Resolves tdf#153223 - Suppress variable line height when skia is off It will be available in 25.2.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.