Plasma panel and menu don't follow font hinting

Version: (using KDE 4.2.2)
Installed from: Debian testing/unstable Packages

Plasma applets and kwin Decoration feature sub-pixel hinting, altough it is not explicitly enabled in systemsettings.

So i would like to be able to enable only simple antialias, without sub pixel hinting.
The attached pictures show the difference.

Created attachment 33091
Plasma and kwin colour fringes

Notice that the taskbar has colour fringes, the decoration too, but the inside of Kate window does not.

Created attachment 33092
KWin menu and Kate

Notice that the decoration menu (Alt+F3) has colour fringes, while Kate menu does not. You may need to magnify the image.

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

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

Created attachment 34984
Blue fringes in the window title, while menu is OK

I can confirm the bug on KDE 4.2.4 on Fedora 11. The subpixel rendering is disabled on the system but the window title shows very nasty blue fringe. The menu text is correct, using only grayscale.

This may be a bug in Qt that forces subpixel hinting for ARGB windows. Could you test application "Konsole" and report your findings?

Created attachment 35011
konsole test

Tested with konsole, see attachment:

 * image on the left - subpixel rendering switched off
 * image on the right - subpixel rendering set to RGB in system settings

Environment:

Qt: 4.5.2
KDE: 4.2.4
Konsole: 2.2.3
X.Org X Server 1.5.3
X.Org opensource ati driver 6.12.1 (with RV280 [Radeon 9200 PRO])

Additional note:

I don't experience this issue on a machine with the same set of software but running on NVidia GeForce 6600 with nvidia binary driver

On Kubuntu 9.10 with KDE 4.3.2, the same is on Fedora 21 beta:

1. Sub-pixel rendering enabled and the air theme selected: black text on gray taskbar is using grayscale rendering.

2. Sub-pixel rendering disabled and the oxygen theme selected: white text on dark taskbar is using sub-pixel rendering.

I could reproduce this bug using KDE SC 4.3.4 and Qt 4.5.3

A few days ago I tried screen rotation with xrandr. Since this will change RGB subpixel order, I changed from RGB to BGR in systemsettings. However, newly started applications did not pick up that change. Then I changed it back to RGB, and suddenly, newly started applications appeared in BGR! Changing back to BGR made them appear in RGB again. When I hit "Apply" without changing anything, then the "nothing changed" is still picked up, and applications start with the last set mode.

So in total, it looks like there is some caching done inside fontconfig, which makes it respect settings delayed. It could be an upstream issue.

Additional notes: This would also explain differing font sizes in KWin with respect to other applications. When settings are applied delayed, KWin as the first application that uses fonts might get different settings than all other applications started later. I remember there was a bug report, but cannot remember right now.

I was referring to bug 179962.

*** This bug has been confirmed by popular vote. ***

Can you reproduce using KDE 4.4.4 or 4.5beta?

Created attachment 47783
KDE 4.4.4 - menu & task manager - air_subpixel

Created attachment 47784
KDE 4.4.4 - menu & task manager - air_grayscale

Created attachment 47786
KDE 4.4.4 - menu & task manager - oxygen_subpixel

Created attachment 47787
KDE 4.4.4 - menu & task manager - oxygen_grayscale

I'm running KDE 4.4.4 on Kubuntu 10.4 with Intel graphics.
I've attached 4 screenshots of the bottom left corner of the screen: air_subpixel.png, air_grayscale.png, oxygen_subpixel.png, and oxygen_grayscale.png.
There you can see an application launcher menu, a task manager and a part of a running application (Krusader).

The application (text "F4 Edit") is always rendered correctly according to the subpixel settings.
The menu does not depend on the settings - the application descriptions are always grayscale and everything else is subpixel-antialiased.
The task manager antialiasing depends on the current theme - it's grayscale on Air and subpixel-antialiased on Oxygen.

On my system (KDE 4.5.4, Qt 4.7.1, Oxygen theme, subpixel rendering enabled, infinality subpixel patchset) I also observed that all ARGB related texts (i.e. those from plasma desktop in taskbar/desktop widgets) only had grayscale AA, but no subpixel AA.

After the assumption regarding an ARGB related bug, played a bit with ARGB test code. It looked as if the raster backend has difficulties with subpixel rendered texts. After changing Qt to the old native backend, all fonts were rendered correctly on my KDE desktop!

- Do you have the new Qt raster backend enabled?
- Can you please revert to the old native backend, for testing?

My guess is all of this is related to the raster backend. This ticket might have to do with it:
http://bugreports.qt.nokia.com/browse/QTBUG-11268

Re comment #19 and comment #20:

What you are seeing is indeed a problem of the way text is rendered in Plasma. Some text (for example in the taskbar) is first rendered to an image to apply shadow and halo effects on it. Since with an image you do not know where it is displayed, and Qt cannot apply sub pixel hinting to text.

This bug, however, is about a completely unrelated issue. The first application(s) that uses text (usually the Plasma Workspace or KWin) completely ignores font related settings from .fonts.conf file, such as anti aliasing settings or font sizes. As the title says, it is therefor even possible that those applications _have_ sub pixel hinting enabled, while it is disabled in System Settings. I still think it is an upstream bug, see comment #10.

I can confirm this in kde 4.6.5..

The inside of the application windows seem to honor the setting..
But every thing else plasma-related seems to have sub-pixel enabled, even though I have it disabled, and it looks ugly.. For example, the title-bar texts, and any menu related to plasma, like if I right-click on the desktop background, or task bar or system tray icons etc..

Weirdly, I think this only started happening now that I switched to the open-source radeon driver.. I was using nvidia proprietary for a while, and then I switched to an ATI card and started using fglrx......And finally, today I switched to the open-source radeon driver, and I am almost completely positive that this issue didn't happen on non-free nvidia, or the fglrx, but only after I started using radeon driver.. Otherwise I would have looked this bug up before today because sub-pixel hinting is very obvious (and very ugly) to me..

I am now on KDE 4.7.4 and this issue still remains for me for plasma-related stuff.. (I am also still using open-source radeon driver, not sure if that has any thing to do with it or not..)
I am using debian testing..

Comment #21 has it right! Until this gets fixed, I use this hacky little script, anytime after KDE has started, and the nasty subpixel rendering in plasma/kwin goes away:

#!/bin/sh
killall plasma-desktop
killall kwin
plasma-desktop &
kwin &

I don't know how those apps are managing to ignore every font config file in my system, or why they are then suddenly honored later in the KDE startup process. I also think it's very rude for any application to default to subpixel rendering, which even on LCDs looks awful. Whatever optical illusion the technique relies on is incompatible with my eyes, and I'm not the only one.

I am on 4.8.4 now on debian testing, and the bug remains..
I agree with comment #24 that I don't like sub-pixel hinting even on my LCD monitor.. I can always tell when fonts have it some how.. Always has ugly cyan and magenta fringes..

It seems like it would be an easy and quick bug to fix once some one decides to work on it.. Because it seems like it can already do it if you restart plasma and kwin like comment #24 said....

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

Created attachment 81051
Homerun Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering.

Created attachment 81052
KDE IM Contacts (kde-telepathy) showing poorly rendered fonts i nthe conversation pane alongside same text typed into the message input textbox, with nicer font rendering.

Created attachment 81053
Kick Off Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering.

To each his own... I like sub-pixel RGB font rendering. Perhaps it's my eyes, or the LCD I am using, but I find the fonts to appear more crisp and smooth.

However, as this bug report implies, some parts of KDE display grayscale sub-pixel rendered fonts, while other parts of KDE obey (my) system-settings and display sub-pixel RGB antialiased fonts. For example the text in Homerun, KDE IM Contacts (kde-telepathy), and Kick Off is fuzzy. But the text in Kate or the text input box in KDE IM Contacts is rendered nicely.

I am running KDE 4.10.4 on an x64 on a machine with Intel graphics. I have selected "native" for the QT Graphics system setting, but notice no difference between this and "raster."

I've attached some scren shots showing the difference. In each of the screen shots, I've typed the same text in Kate, and pasted it alongside the font displayed by KDE to highlight the difference. The screen shots are of Homerun (https://bugs.kde.org/attachment.cgi?id=81051), KDE IM Contacts (https://bugs.kde.org/attachment.cgi?id=81052), and Kick Off (https://bugs.kde.org/attachment.cgi?id=81053).

By the way, Owenswerk's script in Comment 24 (https://bugs.kde.org/show_bug.cgi?id=190627#c24) does nothing to correct this issue on my system.

Please read comment #21, and report the issues separately to Plasma, KTelepathy, and Homerun developers.

Chris,

Thanks for your feedback.

I can open bugs against these specific application, but the issue is more prevalent, affecting many KDE applications, not just the example applications I cited (Homerun, KDE IM Contacts / kde-telepathy, and Kick Off).

Do you think this is an issue with QT, or with Plasma (if these apps rely on some common Plasma component).
Or,.. is it true that the majority of applications written for KDE simply ~ignore~ font anti alias settings?!! (In which case, we would have to open a bug with almost every KDE application!).

I'd like to hit this bug at the root. It might make more sense to open bug(s) against QT or Plasma. What do you think?

Report it for each application where you see it. Qt cannot be fixed, because rendering into a bitmap cannot add subpixel hinting, because Qt does not know which screen (if at all) the bitmap is going to be copied into.

The respective application developers can then decide to change the code not to render into a bitmap, but directly to the widget's painter. Or maybe they are using Plasma text rendering calls, without being aware of the issue. Or they use Plasma calls intentionally, to get the blurred shadows to be better readable with transparent themes.

You might point them to this bug report, especially comment #21 and comment #33.

Plasma developers could check, if rendering the shadows could be decoupled from rendering the text, but that might cause issues when the metrics does not match accurately.

Anyway, what you see is related, but a completely different issue what this bug is about. Since bug 260943 has been marked upstream, I will do the same for this one.