krunner: broken font rendering

[Duncan]

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).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.