Nikos Chantziaras posted on Sun, 16 Sep 2012 01:52:31 +0300 as excerpted:
It seems that krunner displays fonts in a somewhat broken manner,
including "System Activity" (which is launched by krunner.)
To demonstrate, here's a screenshot of "System Activity" through
krunner:
http://i46.tinypic.com/2n7ktnq.png
Look at how "Shared Mem" is rendered, for example.
If I'm seeing the same problem you are, it's called font "kerning", the
way letter spacing is adjusted to account for shape in variable-spaced
fonts. For example, the capital letters VA when appearing together look
too far apart unless the top of the V overhangs the bottom of the A.
http://en.wikipedia.org/wiki/Kerning
Especially on discreet-pixel displays such as LCD monitors and dot-matrix
printers but to a lessor extent on blur-pixel displays such as CRTs and
inkjet printers, a related-effect (but different technology, and it works
in 2D, not just horizontal spacing) is hinting, aka grid-fitting.
There's also anti-aliasing and (on color LCDs) sub-pixel rendering.
http://en.wikipedia.org/wiki/Hinting
http://en.wikipedia.org/wiki/Spatial_anti-aliasing
http://en.wikipedia.org/wiki/Subpixel_rendering
Some people are way more sensitive to these than others. I'd have not
noticed the problem without your mention thereof as I'm not particularly
sensitive to it. You, OTOH, must be quite sensitive to it in ordered for
it to bother you enough to be worth posting about.
Here's an XKCD comic that expresses it quite well. (As always with XKCD,
be sure and hover for the alt-text as it generally expresses another
level of the joke, and if you miss it, you miss half the fun! =;^)
http://xkcd.com/1015/
You're the guy on the left, "ARGH!" I'm the guy on the right, "What?"
I'm sure the sign bugs you, like the guy on the left, to no end. I see
it when I look for it, but ordinarily (as, just walking down the street
and seeing it, as presented in the comic), I'd just read it, oblivious to
the distress it's causing others, and think nothing of it, much like the
guy on the right.
And here's the same process list display, but through "System Monitor":
http://i50.tinypic.com/r23saq.png
Notice how "System Monitor" has correct font display. I found out that
I can trigger the same bug in System Monitor if I launch it with:
ksysguard -graphicssystem native
Then it looks like this:
http://i45.tinypic.com/vwq53k.png
Look for example at how the word "Table" (in "Process Table") is
rendered compared to the previous screenshot.
Another application that has the same problem is KSnapshot. And indeed,
if I launch it manually with:
ksnapshot -graphicssystem raster
then the problem goes away.
In System Settings, in the Desktop Effects section's "Advanced" tab, I
have "Raster" set as the "Qt graphics system". My Linux distro (Gentoo)
also has this set in the environment:
QT_GRAPHICSSYSTEM=raster
So why is this happening? How can I make krunner (and KSnapshot) use
the raster engine by default and not have broken font rendering?
The problem as you're seeing it almost certainly has to do with the
graphics system, the combination of hardware, drivers, and rendering
method and graphics acceleration options chosen. Switching between qt-
raster and qt-native (there's also qt-opengl mode, as you're on gentoo as
I am, try eselect qtgraphicssystem list, but opengl mode really IS
experimental, and last time I tried it resulted in a kde/qt display so
bugged out it was pretty much unusable) switches acceleration and
rendering methods, with obviously one method using different kerning, or
more likely hinting, than the other. Actually, probably the one
activates freetype's autohinting mode, while the other bypasses it, using
either no hinting or a different hinting method.
On the raster vs native qt-graphics-system question, I don't know. If
both gentoo/eselect/environment and kde's advanced desktop effects tab
are set to raster and you're still getting, presumably, native -- that
is, if you're still seeing a difference between how they're run normally
and what happens if you run them with the -graphicssystem raster switch,
I'd say you've likely hit a bug.
How are you starting kde, from a text login using startx (with kde4 set
as the xsession), or from *DM (graphical/x-based login, kdm, xdm, gdm,
etc), and if from *DM, which one? A first guess would be that you're
either using a *DM and it's somehow missing the environment setting that
would select raster, or alternatively, that you're using a text login
with startx, and that it's missing the hook that would set raster.
Either way, you need to ensure that the var is actually being set in the
environment kde's actually getting. To see what environment kde's
actually getting, try running this from krunner:
env > $HOME/kde.env
You can then open (or simply cat, in konsole) that file, to see the
environment as kde sees it.
(Note that you can't do that from konsole, because konsole opens a shell,
which sources ~/.bashrc or the like, so the environment you get there may
well not represent the environment kde gets. But running env from krunner
directly, results in the environment krunner exports to env being printed
to STD, which can be redirected to a file, thus giving you a way to
examine it. =:^)
(A geekier alternative would be to cat the /proc/<pid>/environ file for
some kde-app PID, but that's more complicated since you have to map a kde
app to its pid first, and depending on your security settings, you may
only be able to access the files for /proc/self/ not those of other pids.)
FWIW I use the text mode login and startx so I'm most familiar with it,
but as I said, this stuff doesn't bother me enough to really notice, so
I'd very likely be oblivious to any problem with that and font kerning
here. However, I DID experiment with switching the qt-graphicssystem
around, and DID see some noticeable differences (especially with the
experimental opengl mode, which as I said, in my experience is
"experimental" for a reason!), so I'm reasonably sure it's working here,
regardless.
Other than trying the other one of *DM vs text login and startx, and
setting the variable in your .bashrc or .xinitrc or whatever, kde itself
has a mechanism for setting environmental vars. Before kde starts, it
looks in $KDEHOME/env/ for files to source. (If $KDEHOME isn't set it
defaults to ~/.kde as set by upstream, but some distros change that to
~/.kde4 or the like. I've forgotten what gentoo does as I've long been
setting it myself, to ~/kde as I don't like it hidden, for ages.)
Obviously these run /before/ kde has started, in ordered to get any
variables set into the environment, so you can't run X/KDE apps there
(there's other ways to do that), but it's perfect for setting up vars
before kde starts, its intended purpose. =:^)
So if the diagnostic above doesn't show QT_GRAPHICSSYSTEM, try setting it
in a file in $KDEHOME/env/.
Meanwhile, in addition to the qt-graphicssystem angle of attack above,
there's at least four different alternative angles of attack you can try:
1) As it's graphics system and graphics accel related (I know as I had a
hinting issue with early r5xx series hd4650 Radeon I was running back
when the only way to get opengl with the native freedomware drivers was
to run live-git versions of mesa/xf86-video-ati/kernel-drm/xorg-server,
etc, but THAT one was bad enough entire chunks of letters were entirely
disappearing, rather worse than a kerning issue!), you can of course try
tinkering with that, different kernels, driver versions, freedomware vs
servantware drivers (if you can agree to waive your rights as required to
have permission to run the latter, I can't and don't, so that's not an
option here), maybe even different graphics cards if you're not running a
laptop without a slot for it, etc. If you have anti-aliasing options,
try fiddling with that in particular.
2) Try tinkering with kde's font hinting settings. This one I know can
affect the problem as it's what I used to work around the graphics accel
related problem I mentioned above, but you'll have to experiment to see
if it helps for your case or makes it worse. KDE settings, common
appearance and behavior, application appearance, fonts. Down under the
individual font selectors, try toggling the use antialiasing option, and/
or with it on, click on configure and you'll get a dialog with options
for hinting weight and sub-pixel rendering, plus a place to put in a font-
size exclusion range if desired. (If you read the wikipedia entry on
hinting, you'll understand how a size exclusion range could be of help
since hinting has to balance readability at small sizes with font detail
at larger sizes.)
In my case, I disabling hinting entirely, until the graphics drivers bug
was worked out, was my workaround. While I was actually missing chunks
of letters, a far worse issue than you're seeing, if the kerning/hinting
is incorrect as it appears to be in your case, simply disabling it may
still help even if the default kerning isn't ideal, since the hinting can
actually make the problem worse instead of better. OTOH, maybe you need
to enable or turn up the hinting, if it's off or low.
3) Simply try a different font. You'll need to experiment a bit to see
which font roles affect the areas where you see the bug, but given the
dramatic differences between fonts in the way they handle hinting/
kerning, it may well be that whatever font you're using tickles the bug
you're seeing, and selecting an alternative font could easily be the
simplest way around the problem.
4) Given that you're running gentoo, you have the additional option of
fiddling with freetype USE flags. (Binary distro users would just have
to take what was installed, unless they wanted to do the rebuild entirely
on their own.) In particular, take a look at USE=autohinter. The
"hinting instructor" used for truetype fonts was patented for many years,
and thus the unpatented autohinter was the former default. But a couple
years ago, the patent expired, and freetype now defaults to using the
previously patented truetype "hint instructor". However, in addition to
some people preferring the autohinter or unhinted, a LOT of FLOSS (as
well as servantware designed to work on FLOSS) had been designed to work
without the then-patented technology, and it's reasonable to assume
there's still lingering bugs with some fonts and some software, when used
with the now patent-expired and thus new default. Thus, flipping this
USE flag and rebuilding freetype could make a difference, particularly if
the affected font is truetype-based (see #3 about testing a different
font).
