Download it now!
Bug 134213 - Changed transparency handling in Draw breaks export to PNG of transparent objects over pictures with just default Layout layer, forces use of additional layer(s) for transparent shape(s)
Summary: Changed transparency handling in Draw breaks export to PNG of transparent obj...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.0.0.0.beta1+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 134905 134911 (view as bug list)
Depends on:
Blocks: SoftEdgeFallout
  Show dependency treegraph
 
Reported: 2020-06-22 00:47 UTC by mwtjunkmail
Modified: 2020-08-31 14:17 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
LO Draw file containing 2 slides, one with a transparency. (610.23 KB, application/vnd.oasis.opendocument.graphics)
2020-06-22 00:50 UTC, mwtjunkmail
Details
This slide's appearance is what is expected upon PNG export. (1.18 MB, image/png)
2020-06-22 00:51 UTC, mwtjunkmail
Details
Unacceptable PNG output with a transparent object (1.08 MB, image/png)
2020-06-22 00:53 UTC, mwtjunkmail
Details
smaple cover with text and transparent backing moved to new layer (1.03 MB, image/png)
2020-06-26 18:37 UTC, V Stuart Foote
Details
riff on the sample document with textual elements moved into a new Draw layer, and layers Z-order arranged (610.79 KB, application/vnd.oasis.opendocument.graphics)
2020-06-26 22:00 UTC, V Stuart Foote
Details
7.0.0b2 export to PNG with a new transparent layer (955.12 KB, image/png)
2020-06-26 22:01 UTC, V Stuart Foote
Details
Bibisect log (3.37 KB, text/plain)
2020-06-27 08:20 UTC, Telesto
Details
LO ODG side-by-side transparency bug comparison (1.46 MB, application/vnd.oasis.opendocument.graphics)
2020-06-27 10:16 UTC, mwtjunkmail
Details
expected appearance of exported PNG image (708.56 KB, image/png)
2020-06-27 10:26 UTC, mwtjunkmail
Details
inappropriate appearance of exported PNG image (729.39 KB, image/png)
2020-06-27 10:29 UTC, mwtjunkmail
Details
LO Draw comparison test 2020.07.12 (1.28 MB, image/png)
2020-07-12 12:10 UTC, mwtjunkmail
Details
Expectation of PNG output with a transparent object (957.04 KB, image/png)
2020-08-18 22:22 UTC, mwtjunkmail
Details
PNG export result with skia rendering (1020.24 KB, image/png)
2020-08-18 22:23 UTC, mwtjunkmail
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mwtjunkmail 2020-06-22 00:47:07 UTC
Description:
I build book covers using LO Draw and save them out as PNG files. This bug, apparently new in 7.0.0.0, kills that. All my existing LO book cover templates are absolutely total crap now. I really don't feel like having to find a new program to do them in at this point. That's a lot of rework.

In 7.0.0.0 beta v2, when a transparent object, like a title shade box, is placed over an image, LO Draw now assigns the underlying picture the same transparency property as the object on top of it. BAD.

Steps to Reproduce:
1. Launch LO Draw.
2. Paste a photo onto the canvas.
3. Draw a geometrical shape, like a square, on top of the photo.
4. Set the transparency property of the geometrical shape to solid 40%.
5. Export the page as PNG.

Actual Results:
The entire canvas is rendered as dark as the transparent object. Doesn't even matter if the transparent object is not black. A pink transparent object will produce the exact same darkening of the underlying photograph.

Expected Results:
The underlying image should not be affected by the properties of any object on top of it.

I am using hardware rendering, not SKIA, because SKIA is too slow with high-resolution images and zooming in and out with SKIA is pure death.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.beta2 (x64)
Build ID: 1c213561a365b5666167321de68c9977500c9612
CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 1 mwtjunkmail 2020-06-22 00:50:08 UTC
Created attachment 162279 [details]
LO Draw file containing 2 slides, one with a transparency.

This is a mock-up of a cover. Actual covers are far more complicated, but I just created enough of one to get the point across.

The first slide has no transparency set on the title bar at the bottom and exports as PNG normally.

The second slide's title bar at the bottom of the book cover has a solid 40% transparency on it. That property subsequently is applied to the underlying photograph when the image is exported as a PNG.
Comment 2 mwtjunkmail 2020-06-22 00:51:29 UTC
Created attachment 162280 [details]
This slide's appearance is what is expected upon PNG export.

This is an export of the first slide of the LO Draw file attached to this submission.
Comment 3 mwtjunkmail 2020-06-22 00:53:34 UTC
Created attachment 162281 [details]
Unacceptable PNG output with a transparent object

This is the second slide in the LO Draw document attached to this bug submission as output as PNG. The result is unacceptable. It's quite obvious what happened, when you compare the 2nd page in LO draw with this output, is that the underlying photograph has been assigned the same transparency property as the object on top of it.
Comment 4 Telesto 2020-06-22 04:30:44 UTC
(In reply to mwtjunkmail from comment #3)
I am using hardware rendering, not SKIA, because SKIA is too slow with high-resolution images and zooming in and out with SKIA is pure death.

Please create a bug report for this
Comment 5 mwtjunkmail 2020-06-24 15:53:29 UTC
I hope this graphical bug doesn't take as long as this one 
https://bugs.documentfoundation.org/show_bug.cgi?id=123973
to get addressed, which I logged back in March of 2019 and STILL hasn't been touched because of the huge backlog of graphical problems.

This transparency issue really sucks, and considering that this is a new version of LO going out, shouldn't involve such problems.
Comment 6 mwtjunkmail 2020-06-26 12:58:05 UTC
The work around is to export as TIFF, and then go into some other program and convert the TIFF file to PNG (the final program that needs what I create in LO Draw can't read TIFF, just PNG).

So me and everyone who has ever downloaded my carefully crafted LO Draw templates containing transparent effects:

https://i.imgur.com/d21po0Z.png

must now wait an interminable amount of time before jumping on the 7.0x LO bandwagon when this bug is fixed, or forever remain on 6.4.x and employ an extra step post-production to convert the images to PNG.
Comment 7 V Stuart Foote 2020-06-26 18:37:00 UTC
Created attachment 162434 [details]
smaple cover with text and transparent backing moved to new layer

So for OP, if your sample attachment 162279 [details] is an indicator of how you have been doing your layouts, why are you not placing the cover text with transparency into a layer of its own?

When I do so, moving the Draw Text box, and rectangular shapes into a new layer. Setting Z-order with an Arrangement action, so Text box is on top of its backing shape and the base image is on the bottom--I get correct transparency of just the title backing.

So, is it a simple layering issue?
Comment 8 V Stuart Foote 2020-06-26 20:44:04 UTC
Can't tell if this is intentional. But confirm export to PNG of transparent Draw shapes changed from 6.4 -> 7.0

If intentional need documentation change guiding use of additional layers when set transparent over default Layout layer.
Comment 9 mwtjunkmail 2020-06-26 21:14:34 UTC
(In reply to V Stuart Foote from comment #7)
>  why are you not placing the cover text
> with transparency into a layer of its own?


The position of the gray box is not always going to be 1:1 with the text within it, and by design, the final product very well have a vector-converted set of text that extended well above and below that transparent box.
Comment 10 mwtjunkmail 2020-06-26 21:18:06 UTC
(In reply to mwtjunkmail from comment #9)
> (In reply to V Stuart Foote from comment #7)
> >  why are you not placing the cover text
> > with transparency into a layer of its own?
> 
> 
> The position of the gray box is not always going to be 1:1 with the text
> within it, and by design, the final product very well have a
> vector-converted set of text that extended well above and below that
> transparent box.

Plus I've never had to before. 
And things get worse, and I'll probably have to log a separate bug for this, but placing an SVG vector graphic, something that I've done countless times before, if it is made up of multiple paths and not just one path, causes the bounding rectangle of the graphic to export the entire thing as black, or worse, exporting leaves it alone and the rest of the entire page turns black. Again, this messes up with PNG but fine with TIFF, but I don't have any use for TIFFs and would have to convert everything post-process once done with Draw.
Comment 11 mwtjunkmail 2020-06-26 21:23:15 UTC
This is what I mean about the text not necessarily being placed within the gray box, i.e., why the text is its own object and not an object with its area black with a transparency applied:

https://i.imgur.com/BE76ypv.png
Comment 12 mwtjunkmail 2020-06-26 21:27:21 UTC
(In reply to V Stuart Foote from comment #8)
> Can't tell if this is intentional. But confirm export to PNG of transparent
> Draw shapes changed from 6.4 -> 7.0
> 
> If intentional need documentation change guiding use of additional layers
> when set transparent over default Layout layer.

Which is information that I'll have to spread far and wide to everyone using my various templates. Some of them have adopted using my templates without any experience having used LO before, so they'll be in absolute tears if they upgrade to 7.0 and still using these templates with this bug in it, nothing they do will come out right, and like me, are forced to use PNG, not TIFF, because we're all using the same program to import our work.

This change to how PNG handles transparency upon export is highly impactful, and not just for myself.
Comment 13 V Stuart Foote 2020-06-26 22:00:32 UTC
Created attachment 162437 [details]
riff on the sample document with textual elements moved into a new Draw layer, and layers Z-order arranged

(In reply to mwtjunkmail from comment #11)
> This is what I mean about the text not necessarily being placed within the
> gray box, i.e., why the text is its own object and not an object with its
> area black with a transparency applied:
> 
> https://i.imgur.com/BE76ypv.png

Hmm, I've really no problem arranging multiple layers and transparency. Here is a riff on your sample document with the Lucida Calligraphy 96pt w/Scaled width 75%.

Not seeing an issue, other than there *has* been an export filter change requiring the transparent layers be separated--here I moved them out of the default "Layout" layer to a new "Textual_elements" layer.
Comment 14 V Stuart Foote 2020-06-26 22:01:52 UTC
Created attachment 162438 [details]
7.0.0b2 export to PNG with a new transparent layer
Comment 15 mwtjunkmail 2020-06-26 22:15:55 UTC
https://i.imgur.com/JpyvCYG.png is a side-by-side comparison of the original non-transparent image next to me cutting up the image (on a new slide because I had no idea how to move layers above and below each other).

I don't know if you can tell, but the image on the right has lost detail. The overall image is dimmer, the highlights in the hat are far fainter, and her face has lost detail. I hope that's not the permanent end result of these changes, because I've no way to compensate for that.

If it comes down to it, I can rebuild all 30-odd template documents into layers and republish them, not that everyone will get the memo to use the new templates, and Lord knows how long it'll take me to cut them all up.


The point of using LO was 1. Free and 2. point-and-click for the end users just to replace the pictures. That was the glory of using this technique.

That said, there's no promising that someone won't attempt to modify one of my templates in such a way, while making their own book cover, painting template for a Sims4 object mesh, or whatever, that they correctly place each and every element in its own layer to accommodate the PNG export.  

This change from 6.4 to 7.0 produces a lot more work, only to achieve the same result.

Changes in LO should not force users to update all their drawing documents to retrofit these changes. This retrofit will be huge.
Comment 16 V Stuart Foote 2020-06-26 22:32:43 UTC
(In reply to mwtjunkmail from comment #15)
> https://i.imgur.com/JpyvCYG.png is a side-by-side comparison of the original
> non-transparent image next to me cutting up the image (on a new slide
> because I had no idea how to move layers above and below each other).
> 
> I don't know if you can tell, but the image on the right has lost detail.
> The overall image is dimmer, the highlights in the hat are far fainter, and
> her face has lost detail. I hope that's not the permanent end result of
> these changes, because I've no way to compensate for that.
> 

Careful, the source PNG embedded in the ODF archive is sized 473 x600 x 24 BPP. It will be scaled to place on a canvas you've defined (here 8.5 x 11 inches of the cover). So the loss of detail is the resampling that has to occur to expand the pixel count--nearest neighbor, bilinear, bicubic--I don't know which gets used, just that a resampling occurs, and can appear fuzzy. Very noticeable on the pillow tassel.

To compare "apples to apples" for image quality on export the Draw page/canvas size would have to be set to the size of the image.
Comment 17 mwtjunkmail 2020-06-27 00:52:46 UTC
That's confusing, because the two images in the side-by-side example are identical in size, and in the same document just different slides, so sorry for me being dense, but I'm not understanding why one slide's content would would be resampled but the other not. I can play with it and see what's going on.
Comment 18 V Stuart Foote 2020-06-27 04:26:08 UTC
(In reply to mwtjunkmail from comment #17)
> That's confusing, because the two images in the side-by-side example are
> identical in size, and in the same document just different slides, so sorry
> for me being dense, but I'm not understanding why one slide's content would
> would be resampled but the other not. I can play with it and see what's
> going on.

The source PNG is held in the ODF archive. Unzip it and look in the /Pictures directory. If the source PNG is not the size of the drawing page it is being scaled.

When filter parsed onto canvas, or when canvas selection is filter exported to a new PNG (or other format), it is being resampled. Resulting pixels are not the same size as the original, and color bands for each resulting pixel will also change depending on the sampling type and also for any filter applied (color, gamut, transparency).

So, to eliminate effects of scaling (and isolate the filtering) the drawing page size would have to match the size of the source PNG.  

But that is not the issue here of changed handling of transparency on the 'Layout' layer.
Comment 19 Telesto 2020-06-27 08:20:42 UTC
Created attachment 162440 [details]
Bibisect log

Bisected to:
author	Mike Kaganski <mike.kaganski@collabora.com>	2020-05-28 20:13:50 +0200
committer	Mike Kaganski <mike.kaganski@collabora.com>	2020-05-29 10:31:40 +0200
commit	c644b2b4abe3051c0e0fc91674154c796fd326f6 (patch)
tree	391c0d15daa02bae90325a2d44b9a4cbbba01756
parent	f510bdfa98014ca0ae596dcd0dfd487cfc90f3eb (diff)
Use buffer with alpha in VclProcessor2D::RenderUnifiedTransparencePrimitive2D
This allows UnifiedTransparencePrimitive2D to produce truly transparent image,
usable later in the stack - specifically by glow and soft edge effect.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=c644b2b4abe3051c0e0fc91674154c796fd326f6
Comment 20 Telesto 2020-06-27 08:21:23 UTC
Adding cc: to Mike Kaganski
Comment 21 mwtjunkmail 2020-06-27 10:10:51 UTC
The loss of detail that I mentioned when a transparent element is placed over a picture is a real phenomenon. 

I created a new template and used layers to use for transparent objects. One LO draw page has a transparent object, the other does not, but otherwise they are duplicates of each other.

I exported both LO draw pages as PNG, then opened both exported PNG files in paint.net.

Paint.net reveals that what's happening is that the underlying image has a transparency effect applied to it at the time of export (I say time of export, because the transparency property of the object itself in LO Draw not modified, it's still set to 0, so the only way it could have gotten transparent was during the export process).

This https://i.imgur.com/QX6wNcF.png is a side-by-side comparison in paint.net of the PNG exports of the two LO drawing pages. One  page has a transparent object, the other does not. Again, I used layers this time, I didn't just put everything on the layout layer like I've done prior to LO 7.0.


If you examine https://i.imgur.com/QX6wNcF.png, the red stripe on the right actually spans the distance of the entire side-by-side comparison, in its on paint.net layer in the comparison beneath the two exported PNG images. 

That red stripe is actually behind both pictures, but only shows up on the right picture because a transparency effect has been inappropriately assigned to the underlying image residing beneath the transparent object (that being the Liberation Sans narrow text box).

That inappropriate transparency effect on the underlying image upon PNG export is what's causing the loss of detail and blanching. 

I'll attach the LO Draw document that I used to demonstrate this as transparency bug comparison.odg.
Comment 22 mwtjunkmail 2020-06-27 10:16:29 UTC
Created attachment 162445 [details]
LO ODG side-by-side transparency bug comparison

LO ODG file containing two identical slides, one has a transparent object on it, the other does not. Exporting them as PNG causes the one with the transparent object to appear blanched with a loss of detail. 

That's happening because the image beneath the transparent object is being inappropriately assigned a transparency effect, causing blanching and loss of detail, most apparent when flipping between the exported PNG files in Windows' default Photos program, but also obvious in paint.net (which does well to indicate when transparency is applied to something).
Comment 23 mwtjunkmail 2020-06-27 10:26:30 UTC
Created attachment 162446 [details]
expected appearance of exported PNG image

This is what I expect any PNG export to look like. There is no transparent object on this.
Comment 24 mwtjunkmail 2020-06-27 10:29:57 UTC
Created attachment 162447 [details]
inappropriate appearance of exported PNG image

This is not what an LO PNG export should look like. This export had a transparent object on it (the Liberation Sans Narrow text box).

Compared to attachment 162446 [details], which is what the image SHOULD look like, you can see the difference: 


1. The overall image is dimmer. This is occurring because there's no solid background beneath the image. The image (of the glass) is transparent but shouldn't be.

2. Because of this transparency, detail is lost (compare the white area of the lemon rind in both pictures).
Comment 25 mwtjunkmail 2020-06-27 10:32:20 UTC
I should have said the overall image in 162447 is blanched, but the reason is the same.
Comment 26 mwtjunkmail 2020-06-27 10:34:28 UTC
I've just discovered something:

In Microsoft Windows, the default photo viewing program depicts the image with the transparent object on it as dimmer than the original.

In my Firefox browser, that same image is blanched compared to the original.

Regardless how viewed, the loss of detail is apparent. 
Regardless how created, the intensity and tone of the colors shouldn't change.
Comment 27 Telesto 2020-06-27 11:56:14 UTC
(In reply to mwtjunkmail from comment #25)
> I should have said the overall image in 162447 is blanched, but the reason
> is the same.

No need for some many examples :-) First is obvious enough.

The font rendering has changed too, in notice comparing 6.4 with 7.1. I would say improved
Comment 28 mwtjunkmail 2020-07-01 18:04:53 UTC
Still an issue with this

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 9bef09cb2f0c9c9e6819f28ed8e83c0edd6eadb6
CPU threads: 8; OS: Windows 10.0 Build 20152; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

both with everything on the layout layer and well as when separated out into other layers.
Comment 29 mwtjunkmail 2020-07-03 15:53:45 UTC
Perhaps this may help -- 

transparent elements imported from other graphics programs (I used paint.net) render just fine (I only tried with hardware rendering), even when the transparent element and everything else on the LO Draw reside on just the layout layer.

It's when I draw a shape from within LO Draw, fill it, set its transparency property to other than none/0, that I see the bug.
Comment 30 mwtjunkmail 2020-07-11 21:08:14 UTC
This bug kills. I wish I knew how to program LO. Is there anyway to get this elevated?
Comment 31 Telesto 2020-07-11 21:57:39 UTC
(In reply to mwtjunkmail from comment #30)
> This bug kills. I wish I knew how to program LO. Is there anyway to get this
> elevated?

I'm skeptical (and also no clue if it's needed), but lets add a QA manager
Comment 32 Regina Henschel 2020-07-12 00:00:14 UTC
(In reply to Telesto from comment #19)
> 
> Bisected to:
> author	Mike Kaganski <mike.kaganski@collabora.com>	2020-05-28 20:13:50 +0200
> committer	Mike Kaganski <mike.kaganski@collabora.com>	2020-05-29 10:31:40
> +0200
> commit	c644b2b4abe3051c0e0fc91674154c796fd326f6 (patch)
> tree	391c0d15daa02bae90325a2d44b9a4cbbba01756
> parent	f510bdfa98014ca0ae596dcd0dfd487cfc90f3eb (diff)
> Use buffer with alpha in VclProcessor2D::RenderUnifiedTransparencePrimitive2D
> This allows UnifiedTransparencePrimitive2D to produce truly transparent
> image,
> usable later in the stack - specifically by glow and soft edge effect.
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=c644b2b4abe3051c0e0fc91674154c796fd326f6


Reverting that patch solves the problem. Tested with reverting on Version: 7.1.0.0.alpha0+ (x64)
Build ID: b54f7fd93cc300fedac2f1b007dfc4e6a704b515
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL
Comment 33 mwtjunkmail 2020-07-12 12:10:10 UTC
Created attachment 162922 [details]
LO Draw comparison test 2020.07.12

First, thank you for your attention on this bug.

The latest fix on the July 12 daily build still is not working for me.
On the left is the expectation, on the right is the result. Failed for both hardware rendering and Skia.

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 10d42094e6e478823bac047a5afb3d8268eb990a
CPU threads: 8; OS: Windows 10.0 Build 20161; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 34 Regina Henschel 2020-07-12 12:16:43 UTC
(In reply to mwtjunkmail from comment #33)

> The latest fix on the July 12 daily build still is not working for me.

What fix do you mean? I see no fix that is related to this bug.
Comment 35 mwtjunkmail 2020-07-12 12:27:07 UTC
(In reply to Regina Henschel from comment #34)
> (In reply to mwtjunkmail from comment #33)
> 
> > The latest fix on the July 12 daily build still is not working for me.
> 
> What fix do you mean? I see no fix that is related to this bug.

Then I misunderstood this comment: Reverting that patch solves the problem.

Sorry.
Comment 36 Regina Henschel 2020-07-12 12:49:53 UTC
(In reply to mwtjunkmail from comment #35)
> (In reply to Regina Henschel from comment #34)
> > (In reply to mwtjunkmail from comment #33)
> > 
> > > The latest fix on the July 12 daily build still is not working for me.
> > 
> > What fix do you mean? I see no fix that is related to this bug.
> 
> Then I misunderstood this comment: Reverting that patch solves the problem.
> 
> Sorry.

No problem. I have reverted it on my personal, local build to verify, that the mentioned commit has indeed introduced the problem here. I will not revert it on master, because I do not know, which problem Mike Kaganski wants to solve with that commit.
Comment 37 Mike Kaganski 2020-07-12 17:17:56 UTC
(In reply to Regina Henschel from comment #36)
> I will not
> revert it on master, because I do not know, which problem Mike Kaganski
> wants to solve with that commit.

Please check soft edge effect with overlapping semi-transparent objects.
Comment 38 Robert Großkopf 2020-07-18 07:44:22 UTC
*** Bug 134911 has been marked as a duplicate of this bug. ***
Comment 39 Petr Valach 2020-07-18 08:27:37 UTC
*** Bug 134905 has been marked as a duplicate of this bug. ***
Comment 40 Mike Kaganski 2020-08-13 23:04:20 UTC
I believe it's fixed by https://git.libreoffice.org/core/commit/bf021c369f2306ee507da9bd3cc4cd10ac5d234c
Comment 41 mwtjunkmail 2020-08-18 14:19:24 UTC
(In reply to Mike Kaganski from comment #40)
> I believe it's fixed by
> https://git.libreoffice.org/core/commit/
> bf021c369f2306ee507da9bd3cc4cd10ac5d234c

Has this hit the daily builds then to test?
Comment 42 Mike Kaganski 2020-08-18 14:46:43 UTC
(In reply to mwtjunkmail from comment #41)

Of course - it's been several days since then.
https://dev-builds.libreoffice.org/daily/
Comment 43 mwtjunkmail 2020-08-18 22:20:25 UTC
Getting close but we're not there yet. With Skia rendering, there is a white/gray outline around a transparent box on the PNG export where there is no border defined at all in the drawing document.
Comment 44 mwtjunkmail 2020-08-18 22:22:07 UTC
Created attachment 164433 [details]
Expectation of PNG output with a transparent object

This is a screen shot of an LO document. There are no borders set on the transparent box in the upper left of the picture. 
This is the expectation.
Comment 45 mwtjunkmail 2020-08-18 22:23:19 UTC
Created attachment 164434 [details]
PNG export result with skia rendering

This is the output of using Skia rendering with a transparent object with no borders. There should not be the gray outline around it.
Comment 46 mwtjunkmail 2020-08-18 22:24:29 UTC
Forgot the version information. Tested 2020.08.18 with

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

Skia rendering.
Comment 47 mwtjunkmail 2020-08-18 22:26:56 UTC
And the <build version> is what came from the link off of the Help, About window, so apparently that's broken too.
Comment 48 mwtjunkmail 2020-08-18 22:30:06 UTC
And the <build version> is what came from the link off of the Help, About window, so apparently that's broken too.(In reply to mwtjunkmail from comment #45)
> Created attachment 164434 [details]
> PNG export result with skia rendering
> 
> This is the output of using Skia rendering with a transparent object with no
> borders. There should not be the gray outline around it.

And I'm talking strictly about the white/gray outline around the transparent box, not the big white lines on the edges of the screenshot, that's me being sloppy with the screen grab.
Comment 49 mwtjunkmail 2020-08-18 22:30:32 UTC Comment hidden (obsolete)
Comment 50 V Stuart Foote 2020-08-18 22:35:07 UTC
(In reply to mwtjunkmail from comment #47)
> And the <build version> is what came from the link off of the Help, About
> window, so apparently that's broken too.

That is bug 135133, meanwhile correct MD5 hash signature for build is available in the install's program\version.ini if anyone asks.
Comment 51 Mike Kaganski 2020-08-19 08:19:47 UTC
(In reply to mwtjunkmail from comment #43)
> Getting close but we're not there yet. With Skia rendering, ...

No that doesn't work like that. This bug is about Skia-independent problem with export of slide with transparent object, where transparency gets applied to everything. It is fixed now. This issue should be closed, and if there's another issue with Skia, then a new issue should be created to track that.
Comment 52 Telesto 2020-08-19 08:31:10 UTC
(In reply to mwtjunkmail from comment #44)
> Created attachment 164433 [details]
> Expectation of PNG output with a transparent object
> 
> This is a screen shot of an LO document. There are no borders set on the
> transparent box in the upper left of the picture. 
> This is the expectation.

And please use pre-existing sample files or upload the file you're using.. Else it hard to help out :-)
Comment 53 mwtjunkmail 2020-08-19 08:56:06 UTC
(In reply to Mike Kaganski from comment #51)
> (In reply to mwtjunkmail from comment #43)
> > Getting close but we're not there yet. With Skia rendering, ...
> 
> No that doesn't work like that. This bug is about Skia-independent problem
> with export of slide with transparent object, where transparency gets
> applied to everything. It is fixed now. This issue should be closed, and if
> there's another issue with Skia, then a new issue should be created to track
> that.

So while I cannot use the output because the fix leaves artifacts behind, you want that to be a new bug? The output is still very much unusable.
Comment 54 Telesto 2020-08-19 08:59:36 UTC
(In reply to mwtjunkmail from comment #53)
> (In reply to Mike Kaganski from comment #51)
> > (In reply to mwtjunkmail from comment #43)
> > > Getting close but we're not there yet. With Skia rendering, ...
> > 
> > No that doesn't work like that. This bug is about Skia-independent problem
> > with export of slide with transparent object, where transparency gets
> > applied to everything. It is fixed now. This issue should be closed, and if
> > there's another issue with Skia, then a new issue should be created to track
> > that.
> 
> So while I cannot use the output because the fix leaves artifacts behind,
> you want that to be a new bug? The output is still very much unusable.

Multiple causes, multiple bugs :-). Or different developer responsible; anyhow suggest to create a new bug, this one bit long anyhow with 54 comments
Comment 55 Mike Kaganski 2020-08-19 09:00:03 UTC
(In reply to mwtjunkmail from comment #53)
> So while I cannot use the output because the fix leaves artifacts behind,
> you want that to be a new bug? The output is still very much unusable.

Bug tracker is a tool *for developers*. It is not about your usage, it is about specific bugs and their status. One bug is one issue. Otherwise it's impossible to check what is done and what is not.

It is *not* about "someone is not satisfied with the program; let's use this issue to track this user satisfaction level". It's about users helping us to find bugs and do that in manageable manner.

Thank you for helping making LibreOffice better.
Comment 56 mwtjunkmail 2020-08-19 09:00:40 UTC
I don't consider this bug "resolved" because the fix leaves crap behind on the PNG output, meaning the output is just as useless as it was before, but I'll log a "new" bug reflecting that this fix is flawed, and mark this bug "resolved"
Comment 57 Telesto 2020-08-30 13:32:59 UTC
@Mike
Is it not possible to get some kind of unit test for png export; 
Kohei did point this out: sheet 26
https://www.slideshare.net/kohei101/life-after-calc-core-change

The whole approach is currently annoying frustrating, straining, tiresome..

1) From user perspective quality wise; brokenness not great 
2) From user perspective, reporting bugs and bugs over in over in the same area. (I assume mwtjunkmail can vouch for that)
3) From QA perspective, having to confirm/bibisect those bugs 
4) From developer perspective, being hunted by those fall out

It can't be that hard to run an export and do an (automatic) image comparison. Ideally on content/and maybe also file size (compression) and maybe the header of the file format (as extension bmp was stores actually stored as jpg) 

Not asking for doing all possibility's, but a plain case with some transparency to png. samples are there now plenty. Simply to check if the most common thing works 

A single unit test would save so much trouble. 

They only person who does it rather consistently - from my perspective - is Justin L. (and maybe few more people at DOCX/DOC). This really should be the ideal, IMHO.

Bug fixes should ideally come with a unit tests by default, or go without it but coming with an explanation. (Deviate + Explain). The current workflow is not maintainable in the long term.. And Kohei pointed this out long long ago. But somehow people missed the memo? Or interpreted it as Calc only :-). It's waste of time in short time, but is worth the effort in the long term. 

Of course 'bugs' are the QA yard. So developers might not experience time consuming business.. but it is. For users, bug reports & QA members.
Comment 58 Buovjaga 2020-08-31 14:17:13 UTC
(In reply to Telesto from comment #57)
> A single unit test would save so much trouble. 

Single test multiplied by ten thousand. This is not a case of having to educate developers. We can all do our part. I am sure you are capable of converting certain UI tests to cppunit tests, for example:
https://lists.freedesktop.org/archives/libreoffice-qa/2020-July/010903.html
https://lists.freedesktop.org/archives/libreoffice-qa/2020-July/010905.html

Note that these kinds of tests are actually "integration tests", testing functionality in a dirty way rather than purely algorithms without affecting state or something. We should probably clarify the terminology in the wiki.