Bug 88295 - FILEOPEN: White Background Appears in Impress Text Boxes
Summary: FILEOPEN: White Background Appears in Impress Text Boxes
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: All All
: highest normal
Assignee: Katarina Behrens (Inactive)
URL:
Whiteboard: odf target:5.0.0.0.beta4 target:5.1.0...
Keywords: bibisected, bisected, regression
: 88055 90012 90014 91104 91733 92675 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2015-01-11 16:56 UTC by Luke
Modified: 2016-10-25 19:17 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample showing white background in slide (1.17 MB, application/vnd.oasis.opendocument.presentation)
2015-01-11 16:56 UTC, Luke
Details
Comparison Impress 4.3 vs 4.4 (324.41 KB, image/png)
2015-01-11 17:04 UTC, Luke
Details
White blocks instead of text, no matter the background color (10.04 KB, application/vnd.oasis.opendocument.presentation)
2015-05-16 15:11 UTC, godlike
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2015-01-11 16:56:11 UTC
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.
Comment 1 Luke 2015-01-11 17:04:01 UTC
Created attachment 112096 [details]
Comparison Impress 4.3 vs 4.4
Comment 2 tommy27 2015-01-11 18:27:05 UTC
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.
Comment 3 Regina Henschel 2015-01-11 19:26:47 UTC
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
Comment 4 Rostislav 'R.Yu.' Okulov 2015-01-12 11:09:34 UTC
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
Comment 5 Matthew Francis 2015-01-13 08:15:59 UTC
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
Comment 6 Luke 2015-01-14 02:17:36 UTC
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.
Comment 7 Bryan Leaman 2015-02-08 21:32:34 UTC
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.
Comment 8 Robinson Tryon (qubit) 2015-03-05 20:06:03 UTC
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.
Comment 9 Luke 2015-03-15 02:32:20 UTC
Impress is also adding a white background on PowerPoint import/export. See Bug 90013 / Bug 90014
Comment 10 Luke 2015-03-15 05:55:43 UTC
*** Bug 90014 has been marked as a duplicate of this bug. ***
Comment 11 godlike 2015-05-13 08:47:46 UTC
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
Comment 12 Luke 2015-05-13 22:49:53 UTC
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.
Comment 13 godlike 2015-05-16 15:11:20 UTC
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
Comment 14 Roland Taylor 2015-06-05 17:18:08 UTC
I also have this problem. Has there been any progress on fixing this bug? It's really impacting my work.
Comment 15 Buovjaga 2015-06-08 15:15:24 UTC
*** Bug 91733 has been marked as a duplicate of this bug. ***
Comment 16 Katarina Behrens (Inactive) 2015-06-10 17:44:03 UTC
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
Comment 17 Katarina Behrens (Inactive) 2015-06-10 20:40:31 UTC
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
Comment 18 Luke 2015-06-11 02:44:51 UTC
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.
Comment 19 Buovjaga 2015-06-11 08:31:29 UTC
*** Bug 90012 has been marked as a duplicate of this bug. ***
Comment 20 Katarina Behrens (Inactive) 2015-06-11 08:36:44 UTC
*** Bug 88055 has been marked as a duplicate of this bug. ***
Comment 21 Katarina Behrens (Inactive) 2015-06-11 09:09:00 UTC
> 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.
Comment 22 Commit Notification 2015-06-11 11:15:34 UTC
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.
Comment 23 Commit Notification 2015-06-18 08:09:39 UTC
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.
Comment 24 Commit Notification 2015-06-18 20:19:36 UTC
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.
Comment 25 Katarina Behrens (Inactive) 2015-06-18 20:42:29 UTC
Let's set this to fixed then
Comment 26 tommy27 2015-06-18 20:53:39 UTC
thanks Katarina, as said in comment 2 this one was a really nasty regression
Comment 27 Commit Notification 2015-06-23 19:35:57 UTC
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.
Comment 28 tommy27 2015-06-25 11:42:35 UTC
that fix deserved a 4.4.4 RC3.
well done.
Comment 29 Katarina Behrens (Inactive) 2015-07-21 21:16:03 UTC
*** Bug 92675 has been marked as a duplicate of this bug. ***
Comment 30 Matthew Francis 2015-08-14 02:59:32 UTC
*** Bug 91104 has been marked as a duplicate of this bug. ***
Comment 31 Robinson Tryon (qubit) 2015-12-17 08:43:36 UTC Comment hidden (obsolete)
Comment 32 Roland Taylor 2016-01-12 21:06:00 UTC
The fact this bug keeps on showing up means that someone coding LibreOffice Impress keeps "turning it back on".

Just saying....
Comment 33 godlike 2016-01-12 21:14:02 UTC
(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.