krunner: broken font rendering

Sun Sep 16 13:49:27 BST 2012

I know what kerning is.  I know about the autohinter and I have it 
disabled.  I know how env vars are exported and how to check for them.

And it's not driver related.  It occurs with both an NVidia GPU and the 
official driver, as well as with an AMD GPU and fglrx as well as with 
the open source xf86-video-ati driver.

You should consider writing books :-P

On 16/09/12 06:27, Duncan wrote:
> 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).
>

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