Bug 150610 - FILEOPEN PPTX: text shows very light instead of dark green (low contrast)
Summary: FILEOPEN PPTX: text shows very light instead of dark green (low contrast)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Patrick Luby
URL:
Whiteboard: target:24.2.0 target:7.6.2 target:7.5.7
Keywords:
Depends on:
Blocks: PPTX-Characters
  Show dependency treegraph
 
Reported: 2022-08-25 14:52 UTC by Gerald Pfeifer
Modified: 2023-09-19 10:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample slide (PPTX) (2.44 MB, application/vnd.ms-powerpoint)
2022-08-25 14:52 UTC, Gerald Pfeifer
Details
Visual comparison Impress (top, issues highlighted) vs PowerPoint (bottom) (104.13 KB, image/png)
2022-08-25 14:53 UTC, Gerald Pfeifer
Details
How it looked in Impress 6.4 (40.46 KB, image/png)
2022-08-29 06:26 UTC, Mike Kaganski
Details
How it looks in Impress 7.4 (57.76 KB, image/png)
2022-08-29 06:26 UTC, Mike Kaganski
Details
Reference: How it looks in PowerPoint 2016 (53.43 KB, image/png)
2022-08-29 06:26 UTC, Mike Kaganski
Details
How it looks with current head as of 20221020 in EDIT mode (73.83 KB, image/png)
2022-10-20 08:46 UTC, Gerald Pfeifer
Details
How it looks with current head as of 20221020 in PRESENTATION mode (79.20 KB, image/png)
2022-10-20 08:47 UTC, Gerald Pfeifer
Details
Slideshow snapshot on macOS after fix (1.23 MB, image/png)
2023-08-27 17:43 UTC, Patrick Luby
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2022-08-25 14:52:54 UTC
Created attachment 182024 [details]
Sample slide (PPTX)

Comparing the sample document between Powerpoint and Impress, there
is some text that renders much lighter in Impress and thus is hardly
readable.


Seen with 

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 46dc9f3bbac67e9240adc44ab017f905482ef786
CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

This looks like a regression between 

Version: 6.4.8.0.0+
Build ID: 99b065ec31d032fc08ab14f66430dac4fef904a5
CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-4, Time: 2020-10-08_08:57:08
Locale: en-US (en_US.UTF-8); UI-Language: en-US

and

Version: 7.0.7.0.0+
Build ID: 54e9dd41dc9dd45af12c9346199f601ea4a5994d
CPU threads: 8; OS: Linux 5.19; 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
Comment 1 Gerald Pfeifer 2022-08-25 14:53:46 UTC
Created attachment 182025 [details]
Visual comparison Impress (top, issues highlighted) vs PowerPoint (bottom)
Comment 2 Stéphane Guillou (stragu) 2022-08-25 23:01:17 UTC
I can confirm that it looks bad in:

Version: 7.2.7.2 / LibreOffice Community
Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

and

Version: 7.4.0.2 / LibreOffice Community
Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

but looks good in:

Version: 6.4.7.2
Build ID: 1:6.4.7-0ubuntu0.20.04.4
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

It looks the same as in the MSO screenshot and LO 6.4 when opened in OnlyOffice.

Colour of text is #0C322C in version 6.4 but it is #3E3E3E in buggy versions.

Putting 7.1 alpha version as first affected because we don't have 7.0.7 in the list.
Comment 3 raal 2022-08-28 19:16:25 UTC
This seems to have begun at the below commit.
Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one?
Thanks
 602d48159d7f669e4513c5153b10ef3477cd7202 is the first bad commit
commit 602d48159d7f669e4513c5153b10ef3477cd7202
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Sat May 30 12:44:19 2020 +0200

    source c644b2b4abe3051c0e0fc91674154c796fd326f6

https://git.libreoffice.org/core/+/c644b2b4abe3051c0e0fc91674154c796fd326f6
Comment 4 Mike Kaganski 2022-08-29 06:25:18 UTC
This is not a regression at all.
Additionally, the text is not black nor grey ;P

PowerPoint defines the text in question to use "Dark Green, Text 2" color, solid fill, 50% transparency (visible in "Format Shape" panel under Text Options->Text Fill).

Before the commit identified in comment 3, Impress ignored the transparency completely, rendering the text much darker than in PowerPoint (it just used the color #0C322C, which is the value of the "Dark Green").

The mentioned commit made Impress *correctly* treat the transparency value, *resulting in correct match* of the PowerPoint resulting color.

The problem here is how anti-aliasing is handled together with transparency. There is some (pre-existing) bug here, and since this text is rather small, giving around 1-2 pixel wide strokes at normal resolution, AA gives a huge distortion here. You may see a very different picture at e.g. 400% zoom.
Comment 5 Mike Kaganski 2022-08-29 06:26:01 UTC
Created attachment 182065 [details]
How it looked in Impress 6.4
Comment 6 Mike Kaganski 2022-08-29 06:26:25 UTC
Created attachment 182066 [details]
How it looks in Impress 7.4
Comment 7 Mike Kaganski 2022-08-29 06:26:59 UTC
Created attachment 182067 [details]
Reference: How it looks in PowerPoint 2016
Comment 8 Mike Kaganski 2022-08-29 09:53:45 UTC
Seems to be related to bug 135910 comment 9.
Comment 9 Mike Kaganski 2022-10-05 14:11:34 UTC
Since recent changes that Armin made to this rendering, this could change/fix (I can't test it myself at this moment, unfortunately - I'm still at a conference). Could you please check using current master?
Comment 10 Gerald Pfeifer 2022-10-20 08:46:12 UTC
Created attachment 183158 [details]
How it looks with current head as of 20221020 in EDIT mode

(In reply to Mike Kaganski from comment #9)
> Since recent changes that Armin made to this rendering, this could
> change/fix [...] Could you please check using current master?

It now looks essentially fine in edit mode...
Comment 11 Gerald Pfeifer 2022-10-20 08:47:09 UTC
Created attachment 183159 [details]
How it looks with current head as of 20221020 in PRESENTATION mode

...alas still not fine (= too weak) in presentation mode.

In case this makes a difference, this is with a HiDPI display.
Comment 12 Patrick Luby 2023-08-17 16:53:17 UTC
I can reproduce this bug as well on macOS and it appears to be related the following bugs that I have been working on:

https://bugs.documentfoundation.org/show_bug.cgi?id=156629
https://bugs.documentfoundation.org/show_bug.cgi?id=156630

Here is what I know about this bug. Running the latest master code on macOS with Retina display, I see the following depending on the Skia settings in LibreOffice's preferences:

- Skia/Metal or Skia/Raster enabled: all text has the correct resolution in a document window, but the vertical text is drawn at a lower resolution in a slideshow or when exporting to PDF.
- Skia disabled: all text have the correct resolution in a document window, a slideslow, and when exporting to PDF. But, in a slideshow, the vertical text has a nearly white background.

Since I see no downscaling with Skia disabled, I think we are downscaling the image's alpha mask in the Skia code. Interestingly, if I disabled my fix for the above two bugs, the low resolution vertical text problem goes away when exporting to PDF but the problem in slideshow remains.

I will investigate the Skia code and see if I can figure out how to prevent the downscaling like the old non-Skia drawing code.
Comment 13 Patrick Luby 2023-08-21 14:18:35 UTC
(In reply to Patrick Luby from comment #12)
> I will investigate the Skia code and see if I can figure out how to prevent
> the downscaling like the old non-Skia drawing code.

Update: with my local build with the latest master code, I am no longer seeing downscaling when exporting to PDF so now I only see this bug when running a slideshow.

After some debugging, I have narrowed down the cause of the slideshow bug to the following two things:

1. The downscaling is occurring in the alpha mask in the following line in vcl/source/outdev/transparent.cxx:686:

   AlphaMask aPaintAlpha(aPaint.GetAlphaMask());

   Disabling antialiasing improves the vertical text rendering so it appears that LibreOffice is misinterpreting the semi-transparent edges of the vertical text. The green text itself is at a Retina display level of resolution so if I draw without the alpha mask, the text is crisp. That is not a fix since no alpha mask results in a white background, but it does indicate that somewhere in BitmapEx::GetAlphaMask() is where the bug is occurring.

2. The last character of the vertical text is partially clipped. I will need to see if I can expand the size of the VirtualDevice that the vertical text is being drawn to.


I will post an update when I have any news to report.
Comment 14 Patrick Luby 2023-08-25 23:52:12 UTC
Update: I have a fix for the first case that I listed in https://bugs.documentfoundation.org/show_bug.cgi?id=150610#c13:

https://gerrit.libreoffice.org/c/core/+/156098

Still debugging the second case. When running in a slideshow, the text is being scaled down slightly in cppcanvas/source/mtfrenderer/transparencygroupaction.cxx:219, but if I forcefully set the scale to 1, the clipped text no longer occurs. So, I think some code is miscalculating the scaling for this text.
Comment 15 Patrick Luby 2023-08-27 17:21:28 UTC
(In reply to Patrick Luby from comment #14)
> Still debugging the second case. When running in a slideshow, the text is
> being scaled down slightly in
> cppcanvas/source/mtfrenderer/transparencygroupaction.cxx:219, but if I
> forcefully set the scale to 1, the clipped text no longer occurs. So, I
> think some code is miscalculating the scaling for this text.

I have found a fix for the second case and it is included in the latest patch in:

https://gerrit.libreoffice.org/c/core/+/156098

Before I commit the patch, I am hoping that someone can test the fix on Windows or Linux.
Comment 16 Patrick Luby 2023-08-27 17:43:57 UTC
Created attachment 189172 [details]
Slideshow snapshot on macOS after fix
Comment 17 Patrick Luby 2023-08-27 17:45:22 UTC
(In reply to Patrick Luby from comment #16)
> Created attachment 189172 [details]
> Slideshow snapshot on macOS after fix

For comparison, I have posted a screen snapshot of https://bugs.documentfoundation.org/attachment.cgi?id=182024 running in a slideshow on macOS with my fix.
Comment 18 Gerald Pfeifer 2023-08-27 20:06:45 UTC
(In reply to Patrick Luby from comment #15)
> Before I commit the patch, I am hoping that someone can test the fix on
> Windows or Linux.

I'll be happy to test (and am the original reporter). Alas the only
access I have to new builds are the daily dev builds.

How if you go ahead and push your patch based on your testing on macOS
and I'll then swiftly test/confirm on Linux within 24 hours?
Comment 19 Commit Notification 2023-08-27 21:12:06 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e7496f41562b75ea9732ca48f9aa0c07b69e424f

tdf#150610 fix broken rendering of text meta actions

It will be available in 24.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.
Comment 20 Patrick Luby 2023-08-27 21:21:35 UTC
(In reply to Gerald Pfeifer from comment #18)
> I'll be happy to test (and am the original reporter). Alas the only
> access I have to new builds are the daily dev builds.
> 
> How if you go ahead and push your patch based on your testing on macOS
> and I'll then swiftly test/confirm on Linux within 24 hours?

Another developer was able to test the patch on Windows so I went ahead and committed it. The change should be in tomorrow's (28 August 2023) "nightly" master build.
Comment 21 Gerald Pfeifer 2023-08-28 08:29:12 UTC
Great, thank you, Patrick!

I am happy to confirm this all looks fine on Linux as well with your
patches, both in EDIT mode (as before) and PRESENTATION mode.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e7496f41562b75ea9732ca48f9aa0c07b69e424f
CPU threads: 8; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Comment 22 Commit Notification 2023-08-28 11:31:14 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/e644d4da25e1b6cd211d51dbd2dc7de84648c708

tdf#150610 fix broken rendering of text meta actions

It will be available in 7.6.2.

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 23 Commit Notification 2023-09-19 10:47:41 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/e2b4dcec5c9bf4e8c053c34a72ace5193d670695

tdf#150610 fix broken rendering of text meta actions

It will be available in 7.5.7.

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.