Bug 105362 - FILEEXPORT: Slides nearly black and unreadable when exported to PNG with transparency enabled
Summary: FILEEXPORT: Slides nearly black and unreadable when exported to PNG with tran...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Armin Le Grand
Whiteboard: target:24.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Presentation-Export Graphics-Export
  Show dependency treegraph
Reported: 2017-01-16 10:03 UTC by Telesto
Modified: 2023-10-23 13:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example file (19.17 KB, application/vnd.oasis.opendocument.presentation)
2017-01-16 10:03 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-01-16 10:03:29 UTC
Slides nearly black and unreadable when exported to PNG with transparency enabled

Steps to Reproduce:
1.Open attached file
2. Click File -> Export 
3. Select PNG
4. Click save
5. Click OK

Actual Results:  
Slides nearly black and unreadable

Expected Results:
Slides should be exported the same way LibO does

Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Build ID: 99eed82939999d9a9689788a4134dd05d5c20c5a
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_23:37:40
Locale: nl-NL (nl_NL); Calc: CL

and in
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: nl-NL (nl_NL)

but not in
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: en-US (nl_NL)

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Telesto 2017-01-16 10:03:56 UTC
Created attachment 130470 [details]
Example file
Comment 2 Xisco Faulí 2017-01-16 16:10:24 UTC
Confirmed in

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
Comment 3 Aron Budea 2017-01-25 21:15:16 UTC Comment hidden (bibisection)
Comment 4 Aron Budea 2017-01-25 21:17:21 UTC
Bibisect points to the commit referenced below. Adding Cc: to Armin Le Grand, please take a look.

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"
Comment 5 QA Administrators 2018-07-25 02:38:56 UTC Comment hidden (obsolete, spam)
Comment 6 QA Administrators 2021-04-09 03:46:45 UTC Comment hidden (obsolete)
Comment 7 Armin Le Grand 2022-01-05 09:45:22 UTC
Maybe double to tdf#122155, same commit identified
Comment 8 Julien Nabet 2022-03-05 16:51:45 UTC
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
Comment 9 Armin Le Grand 2023-06-30 09:06:20 UTC
Yes, case (b) *somehow* does not export PageBackground -> all visible objects are on MasterPage, none is on the page directly...
Comment 10 Armin Le Grand 2023-07-06 14:30:19 UTC
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...
Comment 11 Armin Le Grand 2023-07-06 14:42:54 UTC
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...?
Comment 12 Armin Le Grand 2023-07-06 14:54:56 UTC
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...
Comment 13 Armin Le Grand 2023-07-06 15:11:14 UTC
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').

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...?
Comment 14 Armin Le Grand 2023-07-06 15:12:10 UTC
BTW, good proof of concept for comment 4 already showing the right relevant change :-)
Comment 15 Armin Le Grand 2023-07-10 11:23:32 UTC
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...
Comment 16 Armin Le Grand 2023-07-10 13:01:33 UTC
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 (!)
Comment 17 Armin Le Grand 2023-07-11 10:23:45 UTC
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...
Comment 18 Armin Le Grand 2023-07-11 11:21:07 UTC
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...
Comment 19 Armin Le Grand 2023-07-11 11:57:08 UTC
Same result with

Version: (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...
Comment 20 Armin Le Grand 2023-07-11 12:01:29 UTC
Solution on gerrit: https://gerrit.libreoffice.org/c/core/+/154301
Let's see if that will go through the tests
Comment 21 Armin Le Grand 2023-07-11 12:05:01 UTC
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
Comment 22 Commit Notification 2023-07-12 16:00:20 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 23 Commit Notification 2023-10-23 13:27:10 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.