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
Created attachment 182025 [details] Visual comparison Impress (top, issues highlighted) vs PowerPoint (bottom)
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.
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
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.
Created attachment 182065 [details] How it looked in Impress 6.4
Created attachment 182066 [details] How it looks in Impress 7.4
Created attachment 182067 [details] Reference: How it looks in PowerPoint 2016
Seems to be related to bug 135910 comment 9.
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?
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...
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.
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.
(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.
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.
(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.
Created attachment 189172 [details] Slideshow snapshot on macOS after fix
(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.
(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?
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.
(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.
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
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.
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.