Created attachment 112095 [details] Sample showing white background in slide Steps to reproduce: 1. Open BackgroundBug.odp in OpenOffice or LO <= 4.3 2. Open BackgroundBug.odp in LO > 4.3 3. Compare results It seems that text boxes in slides with black backgrounds are changed to white.
Created attachment 112096 [details] Comparison Impress 4.3 vs 4.4
confirmed under Win8.1 x64 using 4.5.0.0.alpha0+ Build ID: 90d8f4fca566e46171b260ee3aadc655871c92ba TinderBox: Win-x86@42, Branch:master, Time: 2015-01-10_00:24:59 nasty regression. probably a mab4.4 needs bibisecting.
The file does not contain a draw:opacity="0%" attribute, but only a "draw:fill="none" attribute. If draw:opacity="0%" exists in addition, the background becomes really transparent. I have seen a similar error in issue 86578. There it is worse, because transparency of 100%, which is set in the UI, is removed on saving, in case of draw:fill="none". The reason might be inherited and now triggered by a change, that does not consider the wrong behavior, see https://issues.apache.org/ooo/show_bug.cgi?id=20209
git bisect start # bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 git bisect bad 4a3091e95fa263d3e2dd81e56e83996f0bb12287 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect good 812c4a492375ac47b3557fbb32f5637fc89d60d9 # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # good: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721 git bisect good 1a63057f6378db7c6b8af1171b7b140f7583f246 # bad: [2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7] source-hash-d4a8fa7db0ed4faae00408fbda2352379774cfc0 git bisect bad 2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7 # bad: [98aed8015d7af3a5a132192a34a4b11d8125a220] source-hash-91573182c8474297ef893f98bb04e830f3095cc2 git bisect bad 98aed8015d7af3a5a132192a34a4b11d8125a220 # bad: [ffdd7450b8a7b29a46647c85dd6d3291b1b96003] source-hash-a3fc7f20089062afa4f778e70ba8be84032a30a7 git bisect bad ffdd7450b8a7b29a46647c85dd6d3291b1b96003 # skip: [cd207063d6706c302b4d6ebe44c0ea9fcb29bd47] source-hash-057613c6864204ac5c09260e93a8f14cc9768b90 git bisect skip cd207063d6706c302b4d6ebe44c0ea9fcb29bd47 # bad: [8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2] source-hash-4a1a94dff6a76d70ee72c6c840a24953eca0a9f0 git bisect bad 8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2 # bad: [2db4c8167c9eb9e581214397fb612cbe6c3978d7] source-hash-2e0561c9962e1205b68ae0c9971c4df7b141f535 git bisect bad 2db4c8167c9eb9e581214397fb612cbe6c3978d7 # good: [626531d9052fe067359170d41bd943b59766b551] source-hash-3d3401a6397e893808309ec374f5d8f890144906 git bisect good 626531d9052fe067359170d41bd943b59766b551 # first bad commit: [2db4c8167c9eb9e581214397fb612cbe6c3978d7] source-hash-2e0561c9962e1205b68ae0c9971c4df7b141f535 2db4c8167c9eb9e581214397fb612cbe6c3978d7 is the first bad commit commit 2db4c8167c9eb9e581214397fb612cbe6c3978d7 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sat Oct 18 16:06:03 2014 +0000 source-hash-2e0561c9962e1205b68ae0c9971c4df7b141f535 commit 2e0561c9962e1205b68ae0c9971c4df7b141f535 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Jul 23 09:41:29 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Jul 23 09:41:44 2014 +0100 drop helpids that go nowhere Change-Id: I64c060ac849f8b055f8b63bba8ecb59ee3ef2d9a :100644 100644 b391ec5c393bfbdebe23856804c8800dde651c47 43fb8398ebdbb1b5eb0ef801ece3c2b2da163599 M ccache.log :100644 100644 9a64b0cd10a8cc4dee22c0e39c09d021785b4ae4 60bdee1e20a903e87848e9283c36ee473cb650da M commitmsg :100644 100644 8a01c44c0f06098104f46919f6aa96bac40b68fc 2ca6a0bc36134411753082f4c8f5a0070e06bd3c M make.log :040000 040000 1675303dcebc64f8a6f1aa07ad912cbe1e89c502 4003b047e7418bd8da81a1dcec3ba214584f4c53 M opt
The behaviour seems to have changed in the below commit. commit 0f47de0cff673d298af63926e15e3dff40ee80db Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Tue Jul 22 15:25:27 2014 -0400 Fix the font handling esp wrt font colors. Change-Id: I7dda03368f67ea6a12dfb39115f4546277abb76b
I can confirm that reverting 0f47de0cff673d298af63926e15e3dff40ee80db resolves this issue. Thanks Matthew! Can someone please contact Kohei? This is serious issue for Impress users that we should try to get resolved ASAP.
Just updated from 4.3 to 4.4.0.3 and ran into this immediately. I can set a black background and everything looks fine. but after saving and reloading the document, the (automatic) white text shows with a white background during editing. I'm going to have to go back to 4.3 for now.
Setting priority to highest as this is a 4.4 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Impress is also adding a white background on PowerPoint import/export. See Bug 90013 / Bug 90014
*** Bug 90014 has been marked as a duplicate of this bug. ***
For anybody wondering, yes this is still an issue and yes there's a workaround. I had created a presentation with a black background and experienced the exact same symptoms when saving and opening it later. If I focus the text box, the problem is gone (until I unfocus). The workaround I found is to (ugh) export to ppt. Opening the ppt does not render this problem
Going into slideshow mode, correctly renders the images. Bryan Leaman and godlike64, Could you please attach examples of this issue that you're running into? I'd like to confirm what we're all dealing with the same issue here.
Created attachment 115656 [details] White blocks instead of text, no matter the background color Attaching a trimmed-down odp file which reproduces this issue. In my case, I tried changing the background color to see if I could workaround the issue in that way, to no avail. It appears that no matter what background color is set, the problem persists
I also have this problem. Has there been any progress on fixing this bug? It's really impacting my work.
*** Bug 91733 has been marked as a duplicate of this bug. ***
OP or QA guys: please check with one of the daily builds that contain fix for bug 88055 (i.e. as of today 10th June or newer) if this also fixes this particular problem
Sadly, fix for bug 88055 has only effect on newly created documents and documents created in older versions of LibO ( 4.3 and below). Both attachments to this bug have been saved by LibO >= 4.4 which made them broken beyond repair as now nobody can tell if white text background was really meant to be white, or if it is a transparent background screwed up by buggy LibO export code and saved as white. bug 88055, comment 5 describes how to repair such documents. Alternatively, one can use new UI (bug 88276) to set transparent background to all unwanted white areas. Sorry about this, guys. Shouldn't have happened
Katarina, Thank you for getting to the root of this issue. I can confirm that http://cgit.freedesktop.org/libreoffice/core/commit/?id=321f4925a79b74cfd0aea2221a74dd2717e6b8b2 Fixes the issue when the source PPT and PPTX doc is still available. Are sure that keeping 0f47de0cff673d298af63926e15e3dff40ee80db + your commit is the correct approach to this problem? If so, we'll just have to manually repair the broken files.
*** Bug 90012 has been marked as a duplicate of this bug. ***
*** Bug 88055 has been marked as a duplicate of this bug. ***
> Are sure that keeping 0f47de0cff673d298af63926e15e3dff40ee80db + your commit > is the correct approach to this problem? If so, we'll just have to manually > repair the broken files. Without 0f47de0cff673d, Calc formula input field contains black font on black background (or white on white, in any case, it's unreadable). My commit corrects saving of documents, so that transparent text background is saved as really transparent (instead of white). Another approach to the problem would be not to save text background at all, if it is transparent. Unfortunately, no code fix at all can now repair documents that have been broken. Users have to do it themselves. As I mention in comment 17, it is now impossible to distinguish if background (in a style, paragraph, character properties etc.) is white because the user wanted it to be white, or if it was originally transparent, but LibO saved it as white.
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0957fd55a62056d4417aacd52c4f0a42c6698232&h=libreoffice-5-0 tdf#88295: Don't export transparent background colour as white It will be available in 5.0.0.0.beta4. 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.
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3b51162b68acc7b22c2c5b41a8b29038153afab Bugfix test for tdf#88295 It will be available in 5.1.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.
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf1ea5197ca0d76de23d1d21a4701b38ddec15f1&h=libreoffice-4-4 tdf#88295: Don't export transparent background colour as white It will be available in 4.4.5. 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.
Let's set this to fixed then
thanks Katarina, as said in comment 2 this one was a really nasty regression
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-4-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3782eb93ffb68a1291c95467176a703b1dad9b6d&h=libreoffice-4-4-4 tdf#88295: Don't export transparent background colour as white It will be available in 4.4.4. 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.
that fix deserved a 4.4.4 RC3. well done.
*** Bug 92675 has been marked as a duplicate of this bug. ***
*** Bug 91104 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
The fact this bug keeps on showing up means that someone coding LibreOffice Impress keeps "turning it back on". Just saying....
(In reply to Roland Taylor from comment #32) > The fact this bug keeps on showing up means that someone coding LibreOffice > Impress keeps "turning it back on". > > Just saying.... The two recent duplicates for this bug appear to be from <4.4.4, which is the version this fix was introduced.