Bug Hunting Session
Bug 96922 - EXPORT to GIF, PNG, EPS: background transparency is lost ( THIS BUG IS BLOCKED - DO NOT WRITE NEW COMMENTS )
Summary: EXPORT to GIF, PNG, EPS: background transparency is lost ( THIS BUG IS BLOCKE...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:5.2.0 target:5.1.2 target:5.0.6
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-01-06 12:27 UTC by tydenicek
Modified: 2019-08-07 08:48 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A drawing's background is not transparent after export (20.92 KB, application/vnd.oasis.opendocument.graphics)
2016-01-06 12:27 UTC, tydenicek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tydenicek 2016-01-06 12:27:50 UTC
Created attachment 121747 [details]
A drawing's background is not transparent after export

A drawing is exported to GIF, PNG or EPS alwyas with white background, even if the "save transparency" checkbox is set.
For comparison, OpenOffice Draw exports the same drawing using the same export options correctly with transparent background.
Comment 1 V Stuart Foote 2016-01-06 15:57:05 UTC
Confirmed on Windows 10 Pro  64-bit (10586) with
Version: 5.0.4.2 (x64)
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: en-US (en_US)

Alpha channel is being generated, and can then take the PNG or GIF through GIMP and set it clear. But as noted it is not transparent on export.

Just checked a 3.3.0/4.0.6.2 no transparency support yet there.

But, alpha channel and transparency was correct with 4.1.5.3/4.2.7.2

Goes bad by the 4.3.0.4 release--IIRC we did quite a bit with frames and transparency at that point.

EPS of course is a crap shoot, but seems like GIF and PNG filters should be reliable.
Comment 2 raal 2016-01-10 04:19:27 UTC
This seems to have begun at the below commit.
Adding Cc: to Michael Stahl ; Could you possibly take a look at this one?
Thanks

1c4215aa279646c5fac0a4d3715d6212ecd06662 is the first bad commit
commit 1c4215aa279646c5fac0a4d3715d6212ecd06662
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Thu May 28 21:56:33 2015 +0800

    source-hash-aa68e1309450f79d1b40545ad6c340a49eff51c6
    
    commit aa68e1309450f79d1b40545ad6c340a49eff51c6
    Author:     Michael Stahl <mstahl@redhat.com>
    AuthorDate: Sat May 17 00:08:34 2014 +0200
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Sat May 17 00:43:25 2014 +0200
    
        fdo#78149: set the ViewPort even when painting to a MetaFile
    
        ObjectContactOfPageView::DoProcessDisplay() has a special case for
        painting to MetaFiles, and does not set the ViewPort from the passed-in
        RedrawArea unless it's a printing or PDF export, with the result
        that for a plain MetaFile all fly-frames in a Writer document
        are painted, whether visible or not.
    
        Since e2eda70f2746f08376d8cdf5e5360df217335aef now calls
        GetPreviewMetaFile() after every document load, this issue is more
        visible.
    
        Since there is no obvious reason to ever ignore a passed RedrawArea,
        simply always use it for the ViewPort, not just when printing.
    
        Change-Id: I256710f1476181f567069b45a2a494b0d2064d6b

:040000 040000 4f64073ce90ced7cb36df897b89a42eedcffbe6c 830fe55d9d95e982beb6cfc8fb75206b76de00d2 M	opt

bibisect-43max$ git bisect log
# bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64
# good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3
git bisect start 'latest' 'oldest'
# good: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f
git bisect good e289d9d328719fd70e9a2680fd0e4f586a97b3be
# good: [3e807472869ed7d72b026c12cd1e7c3cb990591f] source-hash-6390dd9777ff63ca75a088e56dd444a355439343
git bisect good 3e807472869ed7d72b026c12cd1e7c3cb990591f
# good: [badf3854a52f4805b58cb5d82c7f5008bb08d70e] source-hash-a911f866623db7a03b12f0143df8d54a95805581
git bisect good badf3854a52f4805b58cb5d82c7f5008bb08d70e
# good: [f68a3ffd75febb1be3f68d578bba9d65d43317e6] source-hash-34509a0805d408cd45c1b95f5afdafdc46c1501e
git bisect good f68a3ffd75febb1be3f68d578bba9d65d43317e6
# good: [979807345606fff7e86f0607844bf5b46d889320] source-hash-a4f32eec653596483088c6e5aa37de031278d74c
git bisect good 979807345606fff7e86f0607844bf5b46d889320
# bad: [cf73c50a38c18a713cdc9acb5301df4772e385a1] source-hash-85500add33b7cdb647b61c83aa6b84a94f3b98a1
git bisect bad cf73c50a38c18a713cdc9acb5301df4772e385a1
# good: [324e9b4ecf9ea24191503d95c43b024e9686bca0] source-hash-73ad72e820ed3de346efa1914432a7f2c6264dde
git bisect good 324e9b4ecf9ea24191503d95c43b024e9686bca0
# bad: [1c4215aa279646c5fac0a4d3715d6212ecd06662] source-hash-aa68e1309450f79d1b40545ad6c340a49eff51c6
git bisect bad 1c4215aa279646c5fac0a4d3715d6212ecd06662
# good: [02b5168e9af6f4c4a79d66e760002dff16e9c78b] source-hash-980f6b505844ffa29d3b78e0abeeb781ed12d57d
git bisect good 02b5168e9af6f4c4a79d66e760002dff16e9c78b
# good: [e366d80b3f2c5f04191bd8d7b9c9daa7a1a4945a] source-hash-df51f7d486cafb2795a38ae9fedd8fde8827d8a4
git bisect good e366d80b3f2c5f04191bd8d7b9c9daa7a1a4945a
# good: [b353f4d4e48701e8c63b6438bbdab4efb86844ff] source-hash-8ae06100856964d849e8c6ecbc85cbb44bcf0414
git bisect good b353f4d4e48701e8c63b6438bbdab4efb86844ff
# good: [edc7e9a1855eb5edaefc91d8dc5d032dba4f11b3] source-hash-280eed820fdd7fccb4fe6f4095b80f7ec504444c
git bisect good edc7e9a1855eb5edaefc91d8dc5d032dba4f11b3
# good: [f3508914c34ad2af011353a193630a852579c014] source-hash-53130f7afb3fcf39f95f69e3752cec1fa00d6d93
git bisect good f3508914c34ad2af011353a193630a852579c014
# good: [dde3260644e91b8293a86e0746a74fb6899561c8] source-hash-44c81ce21825554aad8dcebd58388cb5c0f81df8
git bisect good dde3260644e91b8293a86e0746a74fb6899561c8
# first bad commit: [1c4215aa279646c5fac0a4d3715d6212ecd06662] source-hash-aa68e1309450f79d1b40545ad6c340a49eff51c6
Comment 3 Michael Stahl (CIB) 2016-03-02 12:35:45 UTC
the intermediate GDIMetaFile differ here:

8a9,19
>    <fillcolor color="#ffffff"/>
>    <linecolor color="#000000"/>
>    <polypolygon>
>     <polygon>
>      <point x="0" y="0"/>
>      <point x="35999" y="0"/>
>      <point x="35999" y="19999"/>
>      <point x="0" y="19999"/>
>      <point x="0" y="0"/>
>     </polygon>
>    </polypolygon>
107c118
<     <dxarray>885 1384 1884 2079 2273 2468 2637 3137 3636 4060 4521 5021 5520 6020 139885356317592 </dxarray>
---
>     <dxarray>885 1384 1884 2079 2273 2468 2637 3137 3636 4060 4521 5021 5520 6020 -7378697629483820556 </dxarray>

the problem is that drawinglayer::primitive2d::BackgroundColorPrimitive2D
decomposes to nothing if there is no view port set (before the patch from
comment #2), but a PolyPolygonColorPrimitive2D with a view port set.
Comment 4 Michael Stahl (CIB) 2016-03-02 13:24:12 UTC
the BackgroundColorPrimitive2D was created with "0" transparency already,
from ViewObjectContactOfPageBackground::createPrimitive2DSequence()

            aInitColor = pPageView->GetApplicationDocumentColor();

            if(Color(COL_AUTO) == aInitColor)
            {
                const svtools::ColorConfig aColorConfig;
                aInitColor = aColorConfig.GetColorValue(svtools::DOCCOLOR).nColor;
            }


we get COL_AUTO and then it's overwritten by white.
Comment 5 Armin Le Grand 2016-03-02 16:05:30 UTC
The assumption ("Since there is no obvious reason to ever ignore a passed RedrawArea, simply always use it for the ViewPort, not just when printing.") is wrong. It is useful for geometry processing/extracting without any clipping. In that case the drawinglayer::primitive2d::BackgroundColorPrimitive2D decomposes to nothing by purpose.
Nonetheless all this is part of the EditView visualization and thus should in principle be dependent on the IsPageVisible() setting. Th eproblem with that is described in the comment at ViewObjectContactOfPageBackground::createPrimitive2DSequence:

    // Initialize background. Dependent of IsPageVisible, use ApplicationBackgroundColor or ApplicationDocumentColor. Most
    // old renderers for export (html, pdf, gallery, ...) set the page to not visible (SetPageVisible(false)). They expect the
    // given OutputDevice to be initialized with the ApplicationDocumentColor then.

It is just too dangerous to identify all these places (currently nine) and to give all of them a working replacement for initializing the Background for whatever paint target may be used.

For the future there is the idea(C) to have all EditView-dependent primitives (overlay, page, page background, ...) encapsulated in a group primitive for that purpose that is only handled when it is an EditView processing, but we are not at that yet.

For now, the best solution will/should be to use the existing SetPagePaintingAllowed at the SdrView which gets used as SetPageProcessingActive(rView.IsPagePaintingAllowed()) when the sdr::contact::DisplayInfo is created. With that set to false, all the VOCs involved in EditView PageVisualisation, including PageBackground, will be invisible (see ViewObjectContactOfPageSubObject::isPrimitiveVisible).
Comment 6 Armin Le Grand 2016-03-02 16:08:29 UTC
@comment4: the vcl Color does not reliably support 'transparence' in the upper bits, it is used for various purposes in the office. For that reason primitives use basegfx::BColor (a B3DTuple) and transparence(better handled as opacity) separated.
Comment 7 Armin Le Grand 2016-03-02 16:20:35 UTC
Checked planned change with gif and PNG, with and without selection in the save dialog (makes quite some difference internally), with and without saving transparence, looks good. Preparing gerrit commit...
Comment 8 Armin Le Grand 2016-03-02 16:29:33 UTC
Okay, patch is at gerrit, @MicaelStahl: Could you have a look if that writer stuff to prevent too expensive fly rendering still works with this - it should.
Comment 9 Commit Notification 2016-03-02 21:32:09 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3ff67d3c3047de3ad43f8bb3f805d82eaef0479

tdf#96922 Suppress EditView PageVisuailsation in GraphicExporter

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2016-03-02 21:59:06 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a8245d23d765035a6d618f2cdff6cefd3ed996cf&h=libreoffice-5-1

tdf#96922 Suppress EditView PageVisuailsation in GraphicExporter

It will be available in 5.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2016-03-02 22:13:47 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=79288ac239ebf1916ffbf3c386482d00e6060f8d&h=libreoffice-5-0

tdf#96922 Suppress EditView PageVisuailsation in GraphicExporter

It will be available in 5.0.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Michael Stahl (CIB) 2016-03-03 16:55:46 UTC
ok ALG fixed the bug, thanks!
Comment 13 Eugene Markow 2016-03-26 12:59:59 UTC
The same issue still NOT resolved in Liberoffice Writer. In earlier versions, exporting a PNG file having a transparency in Writer worked well. Not anymore. Please fix.
Comment 14 V Stuart Foote 2016-03-26 13:40:33 UTC
(In reply to Eugene Markow from comment #13)
> The same issue still NOT resolved in Liberoffice Writer. In earlier
> versions, exporting a PNG file having a transparency in Writer worked well.
> Not anymore. Please fix.

Sorry, not "reopenable" as this issue is specific to the Draw module. An issue in export from Writer requires its own fully described issue with test case and Steps to Reproduce.

Please do not make such substantial changes to issue meta data. Rather, check for duplicates and only if not fully duplicate--open a new BZ issue.
Comment 15 Armin Le Grand 2016-03-30 07:40:50 UTC
Please add me to cc when there is a new task.
P.S.: AOO just offers pdf and HTML, LO ignores 'selection', thus seems a new feature in LO. I doubt that Writer was ever capable of keeping a transparent BG for bitmap exports in Writer, making it more a incomplete feature than a bug.
Comment 16 tydenicek 2016-03-31 13:31:33 UTC
Excuse me, but I installed LO 5.1.1.3, build 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d, downloaded from cs.libreoffice.org, and the bug is still there...
where can I find the fixed version? Thanks
Comment 17 steve -_- 2016-03-31 13:55:22 UTC
@tydenicek@seznam.cz sounds expected.
Whiteboard has target:5.2.0 target:5.1.2 target:5.0.6, so 5.1.1 will not have the fix.

Right?
Comment 18 raal 2016-03-31 14:00:48 UTC
(In reply to tydenicek from comment #16)
> Excuse me, but I installed LO 5.1.1.3, build
> 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d, downloaded from
> cs.libreoffice.org, and the bug is still there...
> where can I find the fixed version? Thanks

You can download dev  version here:
http://dev-builds.libreoffice.org/daily/master/
Comment 19 tydenicek 2016-04-01 10:43:59 UTC
I upgraded to 5.1.2.1, confirm that the bug is fixed. Thanks guys!
Comment 20 theenterprisemagazine 2019-08-07 08:19:03 UTC Comment hidden (spam)
Comment 21 we-love-home 2019-08-07 08:34:11 UTC Comment hidden (spam)
Comment 22 naturalhealthbase 2019-08-07 08:46:40 UTC Comment hidden (spam)