Description: Text in comments has a white highlight behind them, even when the text is set to have no fill or no highlighting Steps to Reproduce: 1. Create a new document with a comment. 2. Enter text in comment. Actual Results: Text in the comment is highlighted in white. Expected Results: Text in the comment should not have any background color. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 60(Build:3) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US 7.6.0-1 Calc: threaded
Screenshot uploaded as attachment 189440 [details].
Thank you for reporting the bug. I can not reproduce the bug in Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-AU (fr_FR); UI: en-US Calc: threaded
Created attachment 189461 [details] Test file with highlighted comment text
Already REPRODUCIBLE with Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID ae36ee4f3aa544e53e2edad93d6d79160b27bc9d CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US | Calc: CL | Colibri Theme | Special devUserProfile Was still ok with Server Installation of Version: Version: 7.2.5.2 (x64) Build ID 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE | Calc: CL | Elementary Theme | Special devUserProfile Additional Info: 7.2.5.2 Shows letters in comment of reporter's test document without white background AND New Comments also show no character background b) 7.4.0.0 shows white background in reporters sample document in old AND new comments c) I am pretty sure that this one is a DUP of (or at least related to) "Bug 146516 - Text background is white into comment box (GDI)"
d) I can`t tell whether there also is a Relation to "Bug 91515 - Inserting comments the text background will be white regardless of comment box background"
No reproducible with: Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL
Created attachment 189474 [details] Toggling problem Some more research showed: e) Problem depends on preferences in ˋTools → View → Graphics outputˊ e1) Screenshot shows preferences causing problem ☑ Hardware Acc. ☑ Anti Aliasing [] Skia e2) To switch off problem use [] Hardware Acc. ☑ Anti Aliasing ☑ Skia
Not reproducible with: Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 1; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: es-MX (en_US.UTF-8); UI: en-US Calc: threaded and : ☑ Use hardware acceleration ☑ Use anti-aliasing
Created attachment 189500 [details] Strange preferences inconsistency @LeroyG: During my tests yesterday I stumbled upon some strange observations, still don't understand them all. Short Summary:With LibO restart between the 2 variants of graphic settings I can switch on and off the problem 100% reproducible. f) But: With some "evil tricks" I manage to switch from the "bad" preferences to the "good" ones without switching off the problem. And I am pretty sure that yesterday I also managed to change settings from "good" to "bad" without getting the problem. I do some half changes, interrupt preferences change, newly start, ... and so on, and finally I get the checkmarks moved without switching the comment view. But I was too impatient to do a reproducible documentation of my steps. f1) I wonder whether there is a way to see the "really selected preferences", which might differ from the checkmarks? f2) Or can it really be that the order of the preferences change has influence to some "hidden" preference causing the problem?
Confirmed, regardless of the setting of hardware acceleration. Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: 4412c0006c0cfe5a5d40cae25a00da8a194aa4c0 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL Calc: threaded.
For me, this started in 7.6. I can see that Rainer is seeing something different, but I'll stick to what I think Faisal and [redacted] are seeing. (Rainer, maybe you should add your findings to bug 146516.) Bibisected with linux-64-7.6 repo to first bad commit dcdb8e6aaf9b50159b151afe5ac8b2b3b61c1142 with points to core commit: commit 89b1d41e0d2cd16a4088e095de0f673807c4adac author Noel Grandin Thu Jan 05 12:32:32 2023 +0200 committer Noel Grandin Fri Jan 06 11:34:20 2023 +0000 use std::optional for SALCOLOR_NONE instead of re-using an actual real color value, because it will totally not work when I convert vcl to use alpha instead of transparency Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145075 ... but then, interestingly, got fixed in 24.2 with the implementation of comment styles by Maxim: commit 9474ff4cc0abbd16f91ea582050c2332bdad88a3 author Maxim Monastirsky Wed May 31 21:59:06 2023 +0300 committer Maxim Monastirsky Thu Jun 15 22:37:16 2023 +0200 tdf#103064 editeng: fix handling of char highlighting Transparency should be set to false if a color is present, but not with COL_TRANSPARENT. Compare with what is done for shape text in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153107 Good to see this fixed in master, but is it possible to get a fix for 7.6 as well somehow?
I also started being affected by this bug since LO 7.6. And I can confirm that in master (24.2) the problem has been fixed. @Stephane, I guess the easy fix for this is to cherry-pick this patch by Maxim onto the 7.6 branch. https://gerrit.libreoffice.org/c/core/+/153107 @Xisco, what's your opinion?
Sorry, I no longer remember the exact details (I'm a bit away from LO dev. nowadays), but the quoted patch seems to be isolated from the rest of the styles work, and if it indeed fixes something on the 7-6 branch, it might be a candidate for backporting. But note that there was a follow-up patch for Bug 126382 touching the same code, so it might be needed to backport it as well, to bring it to the same state as master.
If this is fixed in master, then it should be marked Fixed. should someone backport it, the better, closed bug does not hinder that.
(In reply to Rafael Lima from comment #12) > I also started being affected by this bug since LO 7.6. > > And I can confirm that in master (24.2) the problem has been fixed. > > @Stephane, I guess the easy fix for this is to cherry-pick this patch by > Maxim onto the 7.6 branch. > > https://gerrit.libreoffice.org/c/core/+/153107 > > @Xisco, what's your opinion? Sorry, I missed this. Cherry-picked in https://gerrit.libreoffice.org/c/core/+/158699
(In reply to Maxim Monastirsky from comment #13) > Sorry, I no longer remember the exact details (I'm a bit away from LO dev. > nowadays), but the quoted patch seems to be isolated from the rest of the > styles work, and if it indeed fixes something on the 7-6 branch, it might be > a candidate for backporting. But note that there was a follow-up patch for > Bug 126382 touching the same code, so it might be needed to backport it as > well, to bring it to the same state as master. I tested with libreoffice-7-6 branch and the issue is fixed with that single patch in place.
Verified in: Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded