Created attachment 130470 [details]
Example file

Confirmed in

Version: 5.4.0.0.alpha0+
Build ID: 36afb355ac37122d32d624db079def123ef548a2
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Bibisect points to the commit referenced below. Adding Cc: to Armin Le Grand, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=f3ff67d3c3047de3ad43f8bb3f805d82eaef0479
author		Armin Le Grand <Armin.Le.Grand@cib.de>	2016-03-02 16:21:10 (GMT)
committer	Michael Stahl <mstahl@redhat.com>	2016-03-02 21:29:48 (GMT)

"tdf#96922 Suppress EditView PageVisuailsation in GraphicExporter"

Maybe double to tdf#122155, same commit identified

Just for the record after eed83764088bfdfcc6513778f7dc83d649f550a3, I got:
a) the png seems ok with "Save transparency" is disabled
b) empty transparent PNG if "Save transparency" is enabled
so still KO

Yes, case (b) *somehow* does not export PageBackground -> all visible objects are on MasterPage, none is on the page directly...

Well, there are two options:
(a) in the save-dialog (file-dialog), choose 'selection' or not
(b) in the PNG-options dialog, choose 'Save transparency' or not

not b -> all OK
b -> fully transparent PNG

Thus the problem seems (b).
(a) has no effect, probably because there is no selection (and none possible - no objects on the page, only on MasterPage)

Will take a look what makes the difference...

Diff is 'mbTranslucent' in ExportSettings (rSettings) of GraphicExporter::GetGraphic. This represents (b).

If false, line 638 ff is used, else 697 ff. The if-statement to decide is:

            // generate a bitmap to convert it to a pixel format.
            // For gif pictures there can also be a vector format used (bTranslucent)
            if ( !bVectorType && !rSettings.mbTranslucent )

The comment obviously 'mixes' vector format (for gif...?) with transparency, so very strange already.

If true (1), a pixel representation is created using CreatePageVDev and it's impl, that seems to correctly take care of MasterPage(s)

If false (2) the comment says
            // create a metafile to export a vector format
and a metafile is created. Right at the end there is

                if( rSettings.mbTranslucent )
                {
                    Size aOutSize;
                    aGraphic = GetBitmapFromMetaFile( aGraphic.GetGDIMetaFile(), CalcSize( rSettings.mnWidth, rSettings.mnHeight, aNewSize, aOutSize ) );
                }

which then *also* creates a bitmap graphic. That metafile stuff seems
- *not* to handle a MasterPage & it's content correctly
- *or* the conversion to bitmap just goes wrong...

The question is why for true == rSettings.mbTranslucent the conversion is *forced* to metafile creation at all, thus (2) when (1) seems to work fine, and - the target is no vector format anyways...?

The metafile for (2) only contains 8 actions, mainly push/pop & clip stuff -> empty. This is correct for only the page due to having no objects, but definitely does not contain the MasterPage objects...

false == rDisplayInfo.GetPageProcessingActive in ViewObjectContactOfMasterPageDescriptor::isPrimitiveVisible. That comes from
        aDisplayInfo.SetPageProcessingActive(rView.IsPagePaintingAllowed()); // #i72889#
in SdrPageWindow::RedrawAll. That again is ue to

                // tdf#96922 completely deactivate EditView PageVisualization, including
                // PageBackground (formerly 'wiese').
                pView->SetPagePaintingAllowed(false);

in GraphicExporter::GetGraphic::724.
This *should* be true (what is the default, so not set to false), but as can be seen fixed another bug which I would have to check...?

BTW, good proof of concept for comment 4 already showing the right relevant change :-)

After thinking a while about it, I would say the following:
The granularity of 'hiding' page content is just not fine enough. The used 'SetPagePaintingAllowed' disables the whole stuff in ViewContactOfSdrPage, except page hierarchy itself.

NOTE: The 11 sub-VOCs in ViewContactOfSdrPage are always created, their visibility & what primitives they produce depends on the VOC-implementations.

Thus, true == SetPagePaintingAllowed allows all to be 'painted' (better: to create primitives), additionally dependent on 'old' settings at the SdrView which are acessed using the OC-abstraction (which replaces the view).
This 'paints' all the VOCs dependent on other additional settings.

false == SetPagePaintingAllowed does OTOH disable all of them, except PageHiearchy. It is used in the old fix to disable ViewContactOfPageBackground. That works, but also disables case '3' which is the MasterPage content.

Content is:
0- ViewContactOfPageBackground
1- ViewContactOfPageShadow
2- ViewContactOfPageFill
3- (ViewContactOfMasterPage)
4- ViewContactOfOuterPageBorder
5- ViewContactOfInnerPageBorder
6- ViewContactOfGrid (back)
7- ViewContactOfHelplines (back)
8- (ViewContactOfPageHierarchy)
9- ViewContactOfGrid (front)
10 - ViewContactOfHelplines (front)
11 -?!?!? also ViewContactOfHelplines ?!?

NOTE: Someone seems to have changed this, so now 10 && 11 are double, so in principle, if helplines are at front, they should be painted double (?) which is an error. Have to check that, too...

What we want - and what was intended with SetPagePaintingAllowed - is to disable all 'page decoration' things which I would define as
    0 to 2, 4 to 7, 9 to 10
or the other way around, 3 and 8 are *not* page decoration and should always be created, while the others are and should be suppressed when false == SetPagePaintingAllowed.

So for now it should be fixed by:
- always create (3) - ViewContactOfMasterPage, MasterPage content
- rename SetPagePaintingAllowed to something with 'page decoration' to make clearer what it means
- move it's access to OC (similar to e.g. 'IsPreviewRenderer'), remove *PageProcessingActive from DisplayInfo

Will try that...

Works pretty as expected, so works well.

One caveat: I 1st thought ssth is *wrong* but fact is that for the test file the BG on the MasterPage is a Metafile and the gaps btwn the colore objects is *not* transparent, but *filled* white -> no transparency gets created when using 'transparency' in the dialog.
- I tried to 'break' that metafile in MasterView, did not work (another error?)
- Cut/paste to regular page, also no 'break' offered
- Just 'move' it then on masterpage so areas are 'uncovered' -> works

NOTE: The mbTranslucent in GraphicExporter::GetGraphic and that it forces the way over metafile is *bad* (but works):
- It works since GetBitmapFromMetaFile uses convertToBitmapEx from drawinglayer/source/tools/converters.cxx, so it *handles* transparency correct
- SdrObjects get converte to Primitives, then to Metafile and for painting to Primitives *again*. This is *highly inefficient* and hosts the possible massive quality loss on that double conversion
-> All that GraphicExporter::GetGraphic is *old* an should be re-implemented. It *should* just collect SdrObjects and Primitives from these, then *directly* convert those primitives to needed format (metafile or bitmap) using primitives ... ARGH!

Also relevant: When fixing this *all* previously involved errors have also to be checked (!)

One more relevant point: To not change any behavior by accident it is necessary to also control MasterPage content handling from the beginning - all places where it was set to false before should also disable MasterPage content. Thus I will also have to add a flag for this ASAP...

Adapted changes, works as expected, except that export to gif with transparency produces an unreadable gif. Getting a plain master to see if that's caused by my changes. Since I already checked that the BitmapEx is correct I doubt that...

Same result with

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

-> not caused by my changes.
Will put solution on gerrit...

Solution on gerrit: https://gerrit.libreoffice.org/c/core/+/154301
Let's see if that will go through the tests

NOTE: This is a working solution, but GraphicExporter::GetGraphic should really be re-designed to work on primitives to avoid double conversion (see comment 16). Problem is that that part is used for multiple purposes, so dangerous to touch. When redoing it needs to deliver exactly the same content as it does now

Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3996eed1870ced736d9f4a01550f5c9f0568edfa

tdf#105362 better support for transparency in PNG & GIF export

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.

Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4648764378f42df7dee4a4cf7d1614ee64e1d1a3

tdf#105362: sd_png_export: Add unittest

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.

*** Bug 123973 has been marked as a duplicate of this bug. ***

*** Bug 135258 has been marked as a duplicate of this bug. ***