Bug 193369

Created attachment 33861 [details]
Bitmap font, Air panel theme

Created attachment 33862 [details]
Bitmap font, Oxygen panel theme

Created attachment 33863 [details]
Bitmap font, Rhapsody panel theme (via Get Hot New Stuff)

I could go on, but I hope the trend is made clear.

*** Bug 217540 has been marked as a duplicate of this bug. ***

Version:           4.3.3
OS:                Linux
Installed from:    Gentoo Portage

I can confirm this behavior in my case. The bitmap fonts, in particular Japanese and Chinese characters are rendered white in the taskbar. This is the case when the user leaves the default font configuration for taskbar as "Sans Serif". Configuring any vector-based font like BitStream Cyberbit or Arial Unicode MS as taskbar font alleviates this problem.

I can't confirm it now, but I remember that this bug was present since the early releases of KDE 4.0. Back then, the default color scheme was dark, and with white foreground color, both Latin and Japanese characters appeared correctly white on the dark background in the taskbar. Once I attempted to configure this scheme to a brighter color, the incorrect color of the Japanese characters was revealed.

*** Bug 217540 has been marked as a duplicate of this bug. ***

I can not reproduce this bug with KDE 4.4 SVN 1068732 | Qt 4.6.0. For me when browsing on a webpage containing CJK characters in its title, these characters display in the same font color than latin characters in the taskbar (that is, in black in Air theme). I tested using Sans Serif for the taskbar, but also Kochi Gothic.

However, I'm not 100% sure I was reproducing the good steps because JR (the initial reporter of this bug) talks about enabling "bitmap fonts", and i'm not sure I did it well. Can someone detail how to achieve this?

dear kolia,

 have a look at this dupe where I describe how to enable bitmap fonts.
(Works for me on Ubuntu)
https://bugs.kde.org/show_bug.cgi?id=217540

Stefan

2010/1/2 Kolia <thelwyn@gmail.com>:
> https://bugs.kde.org/show_bug.cgi?id=193369
>
>
> Kolia <thelwyn@gmail.com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |thelwyn@gmail.com
>
>
>
>
> --- Comment #7 from Kolia <thelwyn gmail com>  2010-01-02 23:04:05 ---
> I can not reproduce this bug with KDE 4.4 SVN 1068732 | Qt 4.6.0. For me when
> browsing on a webpage containing CJK characters in its title, these characters
> display in the same font color than latin characters in the taskbar (that is,
> in black in Air theme). I tested using Sans Serif for the taskbar, but also
> Kochi Gothic.
>
> However, I'm not 100% sure I was reproducing the good steps because JR (the
> initial reporter of this bug) talks about enabling "bitmap fonts", and i'm not
> sure I did it well. Can someone detail how to achieve this?
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Hi Stefan,

OK i check your description and it was what I did so it seems that I enabled bitmap fonts. Still I can't reproduce the problem, the japanese characters display correctly in the color of the theme font color :/

Created attachment 39868 [details]
Vertex font, Aya panel theme in 4.4rc1

Original reporter here.

I'm now using 4.4rc1, and the task manager applet doesn't seem to want to use bitmaps font anymore. Even with fontconfig set up properly so that other apps use it (including the application menu widget), window titles in the task manager have their fonts drawn as vertex fonts.

That's one way to solve the bug, I guess, but I would have liked bitmap fonts with some shadow behind them. At least fuzzy characters are easier to read than white-on-white characters, but not always by much. (See attachment.)

Created attachment 39869 [details]
Vertex font, Aya panel theme in 4.4rc1 (new)

New screenshot of the 4.4rc1 behavior, better illustrating the difference between vertex rendering and bitmaps of fonts.

Actually, it shouldn't be called a bug of code, but a bug of theme.

In #5, Kaorukun@gmx.net said that's the problem of theme, in fact, it is.

KDE fans can change another color for "Active Titlebar Text" in "System Settings" -> "Appearance" -> "Colors" -> "Colors", default is white. And you ma want to change color of "Selection Text" too.

Note: there is only two color for text:
        QColor shadowColor(Qt::black);
        if (defaultTextColor.value() < 128) {
            shadowColor = Qt::white;
        }
line 1231-1234 in svn 1085662, just above Plasma::PaintUtils::shadowText.
For API of shadowText, please refer to http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/namespacePlasma_1_1PaintUtils.html#a935ab826ba21bbd42c826118956f47b8

But why when the color is white, but the non-bitmap font displays in black, I still don't know.

sorry, i post correct code... should be in tasks/abstracttaskitem.cpp, not pager/pager.cpp

Can you reproduce using KDE 4.4.4 or 4.5beta?

Created attachment 47840 [details]
Screenshot of krunner displaying Japanese and English characters

Krunner in KDE 4.5beta2 (Kubuntu package) displays Japanese text in white while English text in black. This is done with the google-translator-runner plugin.

Created attachment 47841 [details]
Screenshot of task list showing Japanese and English text

Task list in KDE 4.5beta2 (Kubuntu package) shows Japanese text in white while English text in black.

(In reply to comment #15)
> Created an attachment (id=47840) [details]
> Screenshot of krunner displaying Japanese and English characters
> 
> Krunner in KDE 4.5beta2 (Kubuntu package) displays Japanese text in white while
> English text in black. This is done with the google-translator-runner plugin.

Some Japanese characters are black in the screenshot, because they are not in a bitmap font. I have a few Chinese fonts installed, so sometimes a piece of Japanese text gets displayed in mixed fonts.

*** Bug 248365 has been marked as a duplicate of this bug. ***

Hi, are you still experiencing this issue with a newer version of KDE?

Closing for lack of feedback. Feel free to reopen this report if you can reproduce it with KDE 4.8.3 or later.