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.
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.
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
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.
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.
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).
@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.
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...
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.
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.
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.
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.
ok ALG fixed the bug, thanks!
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.
(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.
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.
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
@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?
(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/
I upgraded to 5.1.2.1, confirm that the bug is fixed. Thanks guys!
Thanks for writing this motivative article for me really enjoy your all articles as a CEO of Digital Marketing Agency Pakistan In the last words I just thanks you for this awesome information https://www.theenterprisemagazine.com
Mmm.. good to be here in your article or post, whatever, I think I should also work hard for my own website like I see some good and updated working in your site. https://www.we-love-home.com
Its a great pleasure reading your post.Its full of information I am looking for and I love to post a comment that "The content of your post is awesome" Great work. https://www.naturalhealthbase.com
(In reply to Armin Le Grand from comment #15) > 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. Hi Armin, there is still another bug: Semitransparent areas of objects are not visible in the exported .eps file, just the border (see: https://bugs.documentfoundation.org/show_bug.cgi?id=83389). Maybe you as an expert can also help there :-)