Bug 138223 - FILEOPEN PPTX: text shown black on black (instead of black on white)
Summary: FILEOPEN PPTX: text shown black on black (instead of black on white)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.3.0 target:7.2.5
Keywords: bibisected, bisected, filter:pptx, regression
Depends on:
Blocks: PPTX-Paragraph PPTX-Characters
  Show dependency treegraph
 
Reported: 2020-11-15 01:05 UTC by Gerald Pfeifer
Modified: 2021-12-13 12:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample slide (PPTX) (1.44 MB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2020-11-15 01:06 UTC, Gerald Pfeifer
Details
Visual comparison Office 365 vs LibreOffice 7.1 (296.07 KB, image/png)
2020-11-15 01:07 UTC, Gerald Pfeifer
Details
Updated rendering with LibreOffice 7.2 (87.23 KB, image/png)
2021-06-09 10:26 UTC, Gerald Pfeifer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2020-11-15 01:05:07 UTC
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.
Comment 1 Gerald Pfeifer 2020-11-15 01:06:21 UTC
Created attachment 167305 [details]
Sample slide (PPTX)
Comment 2 Gerald Pfeifer 2020-11-15 01:07:00 UTC
Created attachment 167306 [details]
Visual comparison Office 365 vs LibreOffice 7.1
Comment 3 zcrhonek 2020-11-20 14:29:45 UTC
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
Comment 4 zcrhonek 2020-11-20 14:41:04 UTC
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 sha: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
Comment 5 Gerald Pfeifer 2021-06-09 10:26:24 UTC
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.
Comment 6 Xisco Faulí 2021-06-09 10:39:50 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2021-06-09 10:47:06 UTC
(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 ?
Comment 8 Justin L 2021-11-22 12:10:18 UTC
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.
Comment 9 Justin L 2021-11-22 14:24:05 UTC
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.
Comment 10 Justin L 2021-11-22 17:41:47 UTC
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
Comment 11 Commit Notification 2021-11-23 05:58:40 UTC
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.
Comment 12 Commit Notification 2021-11-23 10:51:39 UTC
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.
Comment 13 NISZ LibreOffice Team 2021-12-06 09:15:29 UTC
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
Comment 14 Christian Lohmaier 2021-12-06 13:28:48 UTC
7.2.4 was a hotfix release, updating target in status-whiteboard
Comment 15 Gerald Pfeifer 2021-12-10 17:08:08 UTC
(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...
Comment 16 Xisco Faulí 2021-12-13 12:35:39 UTC
(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