Description: Open the sample slide and observe that the two text blocks render black on black instead of black on white. Office 365 shows that properly in presentation mode. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ Build ID: 72056f39e01e36afac36c62988331b6813c8214f CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-13_00:15:11 Calc: threaded Similarly seens with current 6.4 and 7.0 dev builds.
Created attachment 167305 [details] Sample slide (PPTX)
Created attachment 167306 [details] Visual comparison Office 365 vs LibreOffice 7.1
Confirm with Version: 7.1.0.0.alpha1+ Build ID: 548d77d0c06f7088dd3eb408797aa1fc1d7eb277 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded ok in 4.1, regression
This seems to have begun at the below commit. Adding Cc: to Xisco Fauli ; Could you possibly take a look at this one? Thanks c5b504b79ac003bd0ed11b34533c73c81e86167b is the first bad commit commit c5b504b79ac003bd0ed11b34533c73c81e86167b Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Oct 12 13:30:46 2019 +0200 source 57cfbc6830c3d8dc64107aed4a5555613415f069 commit 57cfbc6830c3d8dc64107aed4a5555613415f069 [log] author Xisco Fauli <xiscofauli@libreoffice.org> Thu Oct 10 21:29:50 2019 +0200 committer Tamás Zolnai <tamas.zolnai@collabora.com> Sat Oct 12 12:24:25 2019 +0200 tree 16c556be5b715aa9e2b370e25d34a77f9fbf314e parent f62590b6bace50f61cf3a43823a57180ba8a6ce4 [diff] tdf#127129: pptx: map highlight to CharBackColor
Created attachment 172727 [details] Updated rendering with LibreOffice 7.2 With current 7.2 development and 7.1 development the problem has morphed (and "reduced"): only one of two text blocks now shows as black on black, one as black on white: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: b6a30a9db00f92eec7387a577321d65d47ff4af5 CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-08_21:15:20 Version: 7.1.5.0.0+ / LibreOffice Community Build ID: db6efbaf5f9d6ae818afccec6a9fab219268b621 CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-06-07_20:32:23 On the other hand Version: 7.1.3.2 / LibreOffice Community [[ from openSUSE Tumbleweed ]] Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and Version: 7.0.7.0.0+ Build ID: 54e9dd41dc9dd45af12c9346199f601ea4a5994d CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-0, Time: 2021-05-07_08:22:18 exhibit the problem as originally reported: two of two text blacks show black on black.
This got improved by author Gülşah Köse <gulsah.kose@collabora.com> 2021-05-19 14:37:36 +0300 committer Gülşah Köse <gulsah.kose@collabora.com> 2021-05-26 10:14:57 +0200 commit 1cd26a9ab64482daf4de08f5bb7730d0a991bbce (patch) tree 0c89df535ab628423c84a1fd557d83f9f2b7d42b parent 39276660f862b8d534db971d53490450f8ec5d9e (diff) tdf#96061 Unset the highlight property
(In reply to Xisco Faulí from comment #6) > This got improved by > > author Gülşah Köse <gulsah.kose@collabora.com> 2021-05-19 14:37:36 +0300 > committer Gülşah Köse <gulsah.kose@collabora.com> 2021-05-26 10:14:57 +0200 > commit 1cd26a9ab64482daf4de08f5bb7730d0a991bbce (patch) > tree 0c89df535ab628423c84a1fd557d83f9f2b7d42b > parent 39276660f862b8d534db971d53490450f8ec5d9e (diff) > tdf#96061 Unset the highlight property This is weird, Gülşah's patch should have fixed the problem with the second paragraph as well... @Gülşah, any idea why the second paragraph still has a black background ?
This seems to be set in slideMaster2.xml with <a:highlight> <a:scrgbClr r="0" g="0" b="0"> #black <a:alpha val="0"/> #particularly this fully transparent alpha </a:scrgbClr> </a:highlight> Setting alpha to 100,000 (100%) makes it completely black like LO.
There seems to be two issues here. 1.) oox/source/drawingml/color.cxx getColor() just returns COLOR_FINAL mnC1, even though it has no transparency component to it. 2.) Character highlighting (in LO) doesn't seem to have any transparency component, so only the colour part is used anyway. The given colour would need to be adjusted to appear like the transparent colour (without actually becoming transparent). I can't wrap my brain around this kind of stuff, and it seems like it would just be emulating anyway, so I'm going to stop investigating here.
OK - the 100% transparent case is easy/safe enough to handle - which is what this bug report is about. Proposed fix at http://gerrit.libreoffice.org/c/core/+/125670
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/283586c89a0542efb2d57a36ee3aad7cc5153ed5 tdf#138223 oox: don't set highlight color if it is transparent It will be available in 7.3.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/1ed00f2ad9bbc6e920248ba3d39c227acb06e0e6 tdf#138223 oox: don't set highlight color if it is transparent It will be available in 7.2.4. 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 in: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
7.2.4 was a hotfix release, updating target in status-whiteboard
(In reply to Justin L from comment #10) > OK - the 100% transparent case is easy/safe enough to handle - which > is what this bug report is about. Cool, thank you, Justin! You did not add a unit test "because the color really ought to be set - it should just be transparent." Doesn't that mean if someone reverts your patch this will not be noticed via the testsuite? I'm a bit worried this may risk a regression...
(In reply to Gerald Pfeifer from comment #15) > (In reply to Justin L from comment #10) > > OK - the 100% transparent case is easy/safe enough to handle - which > > is what this bug report is about. > > Cool, thank you, Justin! > > > You did not add a unit test "because the color really ought to be set > - it should just be transparent." > > Doesn't that mean if someone reverts your patch this will not be noticed > via the testsuite? I'm a bit worried this may risk a regression... +1