Description: Applying a graphical shadow to a text object in LibreOffice draw creates odd output in PNG, effectively creating a cut-out effect of any object beneath the text as well as leaving borders behind when no borders are selected. NOT having a graphical shadow applied to a copy of the same text object leaves borders behind. The sample background box had borders on it when it was set not to have any. Steps to Reproduce: 1. Launch LO Draw 2. Draw a shape (I chose a box, fill it black, and set its border property to None 3. type text over part of the box (see attachment). 4. Set the shadow property (not the text shadow property) of the text object to be black with a 1,1 offset. 5. Output the slide as PNG 5a. In its entirety 5b. as just a selection 6. Repeat 1-5b, but this time do not apply a shadow effect to the text object. Actual Results: Shadowed text creates a cutout of the object beneath it and leaves borders behind where no borders are defined, but does so differently depending whether the entire slide was exported or only a selection exported. Unshadowed text does not cut out the object beneath it, but borders are present when no borders are defined. Expected Results: In the PNG output, no cutout should occur in objects beneath a shadowed text object, and no borders should appear in the output where no borders are defined. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 8; OS: Windows 10.0 Build 20190; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL BuildVersion=<buildversion> buildid=82189fdc93ac337e1de3379d678eca6b7654e6fc ExtensionUpdateURL=http://updateexte.libreoffice.org/ExtensionUpdateService/check.Update MsiProductVersion=7.1.0.0.alpha0 ProductCode={B9BAD41C-55C4-4886-9539-48BB387F388E} ReferenceOOoMajorMinor=4.1 UpdateChannel= UpdateID=LibreOfficeDev_7
Created attachment 164455 [details] Expected output Expected output.
Created attachment 164456 [details] Testing file Testing file
Created attachment 164457 [details] shadowed text exported as selection PNG output of slide contained a shadowed text objects with "selection" checked on the export dialog.
Created attachment 164458 [details] output of entire slide with shadowed text PNG output of entire slide contained a shadowed text objects (with "selection" NOT checked on the export dialog.)
Created attachment 164459 [details] unshadowed text exported as selection PNG output of slide contained NO shadowed text objects with "selection" checked on the export dialog. The cut-out effect does not appear when the text object does not have a graphical shadow applied to it, but borders appear where no border is defined, and the text is apparently anti-aliased in a white fringe.
Created attachment 164460 [details] unshadowed text exported as entire slide PNG output of an entire slide contained NO shadowed text objects (with "selection" NOT checked on the export dialog). Similar results as the selection output, including the border around the shape object where no border is defined.
Repro with master
The image quality simply horrific (but off topic) with 6.4 or 7.1 but export looks normal with 6.4 (if export the selection, I get transparent area where at the position of the textbox (not in 6.4)
Follow up/spin off of bug 134213
Not in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 166415 [details] zip of test results using 2020.10.16 64-bit windows daily build Still happening in Windows version (using Skia and AA). Version: 7.1.0.0.alpha0+ (x64) Build ID: df74aef7159d7155addf78cfc4d139485945d794 CPU threads: 8; OS: Windows 10.0 Build 20236; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded In the zip, the draw file renders on the screen as expected (continuing to pretend, of course, that the white background on the slide with no background isn't really white but transparent as we've set it to be but that's a different issue). The two PNG output files should look exactly like their respective slides in the draw file. You can see on the lower text sample on the black background slide that the text is rendered to white (faint white outlines where there should be none). Basically this is the same problem that's been happening with other elements on a draw slide when the background is transparent, things render to white instead of alpha. Also different issue is the top and left failing to render when the background is not transparent (this is logged already).
Created attachment 167504 [details] anti-aliasing still happening on shadowed text Still a problem in 7.2.0.0 alpha 0. The shadow appears correctly over an object, but LO Draw is still trying to anti-alias the rest of the text that is not over the object to white even when the background is transparent. Version: 7.2.0.0.alpha0+ (x64) Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5 CPU threads: 8; OS: Windows 10.0 Build 20262; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded In the attachment, I set the shadow offset to 2 rather than 1 to make it more obvious. Remember, this is the object shadow setting, not the text shadow option.
(In reply to mwtjunkmail from comment #12) > Created attachment 167504 [details] > anti-aliasing still happening on shadowed text > > Still a problem in 7.2.0.0 alpha 0. The shadow appears correctly over an > object, but LO Draw is still trying to anti-alias the rest of the text that > is not over the object to white even when the background is transparent. > > Version: 7.2.0.0.alpha0+ (x64) > Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5 > CPU threads: 8; OS: Windows 10.0 Build 20262; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: threaded > > In the attachment, I set the shadow offset to 2 rather than 1 to make it > more obvious. Remember, this is the object shadow setting, not the text > shadow option. My browser in the bug tracker is showing the background as white when it is not. It's transparent. Same image from Imgur: https://i.imgur.com/lotGMQ8.png
Still a problem in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7eb289c49cc7245ef3001a39be0c15d06bbe875b CPU threads: 8; OS: Windows 10.0 Build 21296; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Note that if the background is black, a black shadow aliased to a black background is fine. When the background is other than black, the black shadow anti-aliases to that color and later putting the PNG export against a black background makes it very obvious. Shadow should alias to alpha when the background color on the draw page is set to none.
I cannot reproduce in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c088d26578d1be352efa49bd164a8217627648de CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
The biggest remaining problem I see (when testing in Windows) isn't the cut-out, which seems to be gone, but the inappropriate anti-aliasing. Whether that should be considered part of this bug or another bug, I don't know. Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5e53fe7b53017068d183e923f6a77f0afaf31d67 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I didn't read all this, but decision must be done. I understand that main bug as reported is gone, so I remove bibisectRequest. As for remaining, please search existing bugs and write here if found and close this one. This one is already to long and nobody will read all.
(In reply to Timur from comment #17) > I didn't read all this, but decision must be done. > I understand that main bug as reported is gone, so I remove bibisectRequest. > As for remaining, please search existing bugs and write here if found and > close this one. > This one is already to long and nobody will read all. Hopefully whatever bug(s) I research to associate with remaining issues are short enough for people to bother to read.
This was as close as I found https://bugs.documentfoundation.org/show_bug.cgi?id=139251 and wasn't able to reproduce it, and it's not the precise same problem.
[Automated Action] NeedInfo-To-Unconfirmed
I will document the inappropriate anti-aliasing in another bug.