Bug 35365 - Wrong automatic text color "dark grey" with black background for some GNOME themes
Summary: Wrong automatic text color "dark grey" with black background for some GNOME t...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
3.3.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:3.7.0 target:3.6.6
: 63594 (view as bug list)
Depends on:
Reported: 2011-03-16 12:05 UTC by Benjamin Drung
Modified: 2017-12-03 15:50 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

text-on-black-background.odp (13.53 KB, application/vnd.oasis.opendocument.presentation)
2011-03-16 12:05 UTC, Benjamin Drung
automatic-text-on-black-background.png (118.58 KB, image/png)
2011-03-17 16:58 UTC, Benjamin Drung
black-background.odg (13.51 KB, application/vnd.oasis.opendocument.graphics)
2011-03-18 06:50 UTC, Benjamin Drung
black-background.odt (13.02 KB, application/vnd.oasis.opendocument.text)
2011-03-18 06:50 UTC, Benjamin Drung
draw-black-background.png (120.34 KB, image/png)
2011-03-18 06:51 UTC, Benjamin Drung
writer-black-background.png (118.00 KB, image/png)
2011-03-18 06:51 UTC, Benjamin Drung
0001-fdo-35365-Set-the-default-font-color-to-black-and-th.patch (2.11 KB, patch)
2012-06-24 07:49 UTC, Benjamin Drung

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Drung 2011-03-16 12:05:49 UTC
Created attachment 44517 [details]

In Libreoffice Impress the text with the color "automatic" is hard to read if the background color is set to black (example file attached). I have to change the color from "automatic" to white.

Please map the "automatic" color to white if the background color is set to black.

I initially filed this bug in Ubuntu: https://launchpad.net/bugs/734428
Comment 1 Yifan Jiang 2011-03-16 22:46:27 UTC
I could not reproduce this problem in 3.3.1 SLED 11 sp1.

1. In attached sample,  set the font color to automatic =>the text is normally white

2. Change page background as solid white => the text turns to be black as expected

3. Change page background as solid black back => the text turns to be white again.
Comment 2 Rainer Bielefeld Retired 2011-03-16 23:54:01 UTC
NOT Reproducible with "LibreOffice 3.3.2RC1  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:201 / tag]". I opened sample document, all teext looks white, I modified character color of 1 word in the text from "Auto" to "white" and I did not see any difference to color of "auto" colored characters.

Transferred information from Ubuntu bug tracking system:

DistroRelease: Ubuntu 11.04
Package: libreoffice-impress 1:3.3.1-1ubuntu5
Uname: Linux 2.6.38-997-generic x86_64
Architecture: amd64
Date: Sun Mar 13 18:09:02 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100921.1)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to natty on 2011-03-11 (2 days ago)

Several information is missing! 

@Benjamin Drung:
May be hints on <http://wiki.documentfoundation.org/BugReport> can be useuful for you?
- Attach screenshots with comments (you can add information using LibO DRAW
  and then attach your screenshot with comments as PDF) 
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem
- add information 
  -- what exactly is unexpected (what color do characters have)
  -- and why do you believe it's unexpected
  -- concerning your PC (especially: video card)
  -- concerning your LibO version and localization, It seems that that is a 
     special Ubuntu LibO pack, not the vanilla LibO pack?
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- Whether the problem is limited to Presentation or also is visible in 
     other LibO applications
  -- how you launch LibO
  -- everything else crossing your mind after you read a.m. URL
Can you please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide? Thank you!
Comment 3 Benjamin Drung 2011-03-17 16:58:58 UTC
Created attachment 44565 [details]

I downloaded LibO_3.3.2rc1_Linux_x86-64_install-deb_en-US.tar.gz and installed it (with dpkg -i *.deb) on an up-to-date Ubuntu 11.04 (natty). Then I ran "/opt/libreoffice/program/simpress text-on-black-background.odp". The text "This text should be white!" has the color "automatic" and is gray (see screenshot), but I expect it to be white.

> Can you please file Bug reports with status UNCONFIRMED if your are not
> absolutely sure that you contributed all required background information and
> that the problem will be reproducible with information you can provide?

I will remember that for the next time. The status is hidden by default (-> Show Advanced Fields). I didn't change the status when I initial filed the bug (default was NEW).
Comment 4 Rainer Bielefeld Retired 2011-03-17 22:44:50 UTC
@Benjamin Drung:
Do you see that problem only in Presentation or also in other applications?
If in WRITER, only for DRAWing text boxes or also for standard text?
We urgently need some more information.

The color I see in your screenshot seems to be not grey, but grey 70%. Can you please check and if necessary correct your report?

If you shut down LibO, rename your user profile (for WIN that's in "AppData", I do not know the folder name for Linux), relaunch LibO, do you still see that problem?

And yes, this default-status NEW is very worrying, but it seems that can not be changed with the current Bugzilla version.
Comment 5 Don't use this account, use tml@iki.fi 2011-03-18 00:51:01 UTC
Note, my personal opinionns:

I don't think we need to worry about this NEW vs. UNCONFIRMED thing, just ignore the difference. I doubt we want to use our resources on making sure the Bugzilla Process is perfect. We don't neeed to try to make it work exactly like OOo's bug workflow did; for instance, I don't necesarily see that much value in having a strict difference between CLOSED and RESOLVED. I much prefer just getting useful bug reports, and somebody asking for more information when necessary, i.e. just what you have been doing Rainer, thanks!

But others might disagree of course, maybe even some Document Foundation steering group wants to eventually decide something, or maybe they have?
Comment 6 Rainer Bielefeld Retired 2011-03-18 01:56:55 UTC
@Tor Lillqvist:
Comment 7 Don't use this account, use tml@iki.fi 2011-03-18 02:23:19 UTC
OK, sure, if you *want* to do it, all is good then.
Comment 8 Benjamin Drung 2011-03-18 06:50:18 UTC
Created attachment 44578 [details]

I see that problem in all applications. Example files and corresponding screenshots attached for Writer and Draw.

The color is some kind of gray (not the Gray from the color pallet). It's lighter than Gray 80% and darker than Gray 70% (see attached screenshots).

Removing the user profile (deleting ~/.libreoffice) has no effect.

BTW, I updated LibO to the latest 3.3.2 RC2 version as you can see in the screenshots.

Anything I forgot to provide or to test?
Comment 9 Benjamin Drung 2011-03-18 06:50:43 UTC
Created attachment 44579 [details]
Comment 10 Benjamin Drung 2011-03-18 06:51:04 UTC
Created attachment 44580 [details]
Comment 11 Benjamin Drung 2011-03-18 06:51:22 UTC
Created attachment 44581 [details]
Comment 12 Rainer Bielefeld Retired 2011-03-18 08:58:19 UTC
@Benjamin Drung:
Only one last question from Comment 4: problem only for DRAWing text boxes or also for standard text? (please delete keyword with your answer!).

Currently I do not have any more ideas what could be tested, and I'm afraid developers will not show interest before some more users will be affected. May be you can gamble with all settings referring to color, but I doubt that that will lead to anything useful.
May be you can publish your problem on an user mailing list, may be someone can contribute a good new idea.
Comment 13 Benjamin Drung 2011-03-18 10:09:24 UTC
> problem only for DRAWing text boxes or also for standard text?

As you can see in the black-background.odt, standard text is also affected.

I made a very interesting discovery: Debian unstable (which ship a very similar package of LibreOffice) is not affected. Then I discovered that the color depends on the GNOME theme. 'Automatic' translates to white on a black background for themes like Clearlocks and Skiki-Colors, but it translates to "dark grey" for Ambiance (the default theme for Ubuntu since 10.04) and Radiance.
Comment 14 Benjamin Drung 2011-03-23 15:41:50 UTC
The "automatic" text color maps to the GTK text color instead of mapping to white or black.

Open your gtk theme (in /usr/share/themes/<name>/gtk-2.0/gtkrc on Ubuntu) and search for ntext_color. Replace the following color with FF0000 (red) for example and you will see that Libreoffice maps the automatic color to red on all kinds (white and black) of backgrounds.
Comment 15 Scott Severance 2011-09-07 21:00:50 UTC
There are two issues here. The first is that LibreOffice doesn't correctly handle cases where the GTK theme's text color is something other than black or white. (See comment 14.) This is the case in Ambiance, Ubuntu's default theme. Thus, all Ubuntu users are potentially affected by this bug. This should be fixed to work correctly with all arbitrary colors.

Additionally, there's the issue of what behavior is correct here. In my opinion, LO should ignore the GTK theme entirely and default to black text on a white background. Here's a use case to illustrate: When I produce a document, the difference between the Ambiance default text color (#3C3C3C) and black isn't readily apparent on the screen unless the two colors are next to each other. (This probably explains why there haven't been too many bug reports about this issue.) However, when I print a document using auto colors on a black and white laser printer, the printer dithers the text to create a dark gray. That makes the text look messy.

Following the GTK theme is useful for situations where the content will blend in with other content on the screen. But for Writer, what counts is the paper and printer, not the on-screen appearance. And for Impress, presentations are shown without reference to the current theme. In fact, in general, a good GTK theme wouldn't make a good presentation theme, just as a good GTK theme wouldn't be good for a printed document.

At the very least, please set the auto text color for light backgrounds to black, without reference to the GTK theme.
Comment 16 Scott Severance 2011-12-23 20:15:11 UTC
This is just a quick ping to note that this bug persists. I hope that someone with the requisite skills can take a look at it, now that the problem has been identified.
Comment 17 Scott Severance 2012-04-17 19:32:06 UTC
Someone commented in the downstream bug (https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/734428/comments/27) that this is independent of GTK. He reported this bug in KDE with the GTK packages uninstalled.

Is there anything holding up work on this bug?
Comment 18 Benjamin Drung 2012-06-24 07:49:46 UTC
Created attachment 63403 [details]

Here's the patch that I proposed on the mailing list to fix this bug.
Comment 19 Scott Severance 2012-06-24 14:26:04 UTC
Comment on attachment 63403 [details]

Review of attachment 63403 [details]:

Looks good to me.
Comment 20 Björn Michaelsen 2012-06-26 06:58:03 UTC
pushed to gerrit as:
Comment 21 Not Assigned 2012-07-04 06:22:43 UTC
Benjamin Drung committed a patch related to this issue.
It has been pushed to "master":


fdo#35365 Set the default font color to black and the document color to white.
Comment 22 Caolán McNamara 2012-07-17 16:12:48 UTC
patch got pushed to master, closing
Comment 23 Not Assigned 2013-02-14 19:35:13 UTC
Benjamin Drung committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":


fdo#35365 Set the default font color to black and the document color to white.

It will be available in LibreOffice 3.6.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:
Affected users are encouraged to test the fix and report feedback.
Comment 24 plasticbeach 2013-04-17 09:39:35 UTC
*** Bug 63594 has been marked as a duplicate of this bug. ***
Comment 25 Emilio Pozuelo Monfort 2013-07-30 11:40:51 UTC
Looks like Impress has regressed, see bug #67529.
Comment 26 Emilio Pozuelo Monfort 2013-07-30 16:46:00 UTC
Nevermind the above comment.
Comment 27 Michael Meeks 2013-12-23 14:03:37 UTC
Seems this creates a nasty a11y bug; see bug#71511 - input there appreciated.