Created attachment 44517 [details] text-on-black-background.odp 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
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.
NOT Reproducible with "LibreOffice 3.3.2RC1 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:201 / tag 3.3.2.1)]". 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) ProcEnviron: LANGUAGE=de_DE:en LANG=de_DE.UTF-8 SHELL=/bin/bash 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? Please: - 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!
Created attachment 44565 [details] automatic-text-on-black-background.png 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).
@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.
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?
@Tor Lillqvist: <http://wiki.documentfoundation.org/User:RBd/Why_Does_He_Do_As_He_Does>
OK, sure, if you *want* to do it, all is good then.
Created attachment 44578 [details] black-background.odg 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?
Created attachment 44579 [details] black-background.odt
Created attachment 44580 [details] draw-black-background.png
Created attachment 44581 [details] writer-black-background.png
@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.
> 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.
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.
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.
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.
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?
Created attachment 63403 [details] 0001-fdo-35365-Set-the-default-font-color-to-black-and-th.patch Here's the patch that I proposed on the mailing list to fix this bug.
Comment on attachment 63403 [details] 0001-fdo-35365-Set-the-default-font-color-to-black-and-th.patch Review of attachment 63403 [details]: ----------------------------------------------------------------- Looks good to me.
pushed to gerrit as: https://gerrit.libreoffice.org/#/c/238/
Benjamin Drung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d06094c701262ef54604be206c25dd87a77d224 fdo#35365 Set the default font color to black and the document color to white.
patch got pushed to master, closing
Benjamin Drung committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f10bb02eb3083a089e3ca28c45983e616ef84d58&h=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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 63594 has been marked as a duplicate of this bug. ***
Looks like Impress has regressed, see bug #67529.
Nevermind the above comment.
Seems this creates a nasty a11y bug; see bug#71511 - input there appreciated.