Bug 113637

The bug seems to be worse cause the tweaj I tell you seems to render the fonts
uglier.

It is not due to the BYTECODE_INTERPRETER disabled cause you seems to have
compiled freetype2 with the bytecode patch applied and I've rebuilt it by myself
to see.

Take a look to the 2 attachments, you will see that the fonts are not the same
and look better in SuSE 9.3. It is quite subtle here but believe me, it's uggly,
especially for web browsing for example ;o)

The bug as already been reported earlier in the KDE bugzilla for a kde 3.3.2 but
they said it was corrected in the 3.4 branch. It was true for the KDE used in
SuSE 9.3, not in the one from beta3.

The bug seems to be worse cause the tweaj I tell you seems to render the fonts
uglier.

It is not due to the BYTECODE_INTERPRETER disabled cause you seems to have
compiled freetype2 with the bytecode patch applied and I've rebuilt it by myself
to see.

Take a look to the 2 attachments, you will see that the fonts are not the same
and look better in SuSE 9.3. It is quite subtle here but believe me, it's uggly,
especially for web browsing for example ;o)

The bug as already been reported earlier in the KDE bugzilla for a kde 3.3.2 but
they said it was corrected in the 3.4 branch. It was true for the KDE used in
SuSE 9.3, not in the one from beta3.

Created attachment 47898 [details]
Nice fonts rendering on SuSE 9.3

Created attachment 47899 [details]
Ugly fonts on SuSE 10.0 beta3

suse's fontconfig is overriding the kde settings. I already reported this bug 
too, but it wasn't fixed.  
 
see /etc/fonts/suse-pre-user.conf especially the  
 
       <!-- 
            Using the autohinter and anti-aliasing. 
            This is a good default for most fonts. 
        --> 
        <match target="font"> 
                <edit name="autohint"> 
                        <bool>true</bool> 
                </edit> 
                <edit name="antialias"> 
                        <bool>true</bool> 
                </edit> 
        </match> 
 
 
 
section. there is really no need to recompile packages anymore, you just have 
to edit config files.  

Yeah right, thank you very much !!! I've disabled both autohint and antialias
and now I've a perfect rendering with the beta3 !!! I will perhaps stay with it
;o) No need to switch back to 9.3 ;o)

If this is a bug, it should be fixed. If it is a feature, it should be
documented somewhere in the SuSE manual in order people could set their fonts as
they like it.

Or if it stay system-wide, a little Yast utility could be a good stuff in order
to find the setting and change it easilly.

Else, it's funny cause before reporting a bug, I try to search on bugzilla but I
didn't see your bug with my keywords. A bugzilla is too a good way to fix a beta
release in order to have a good environment to continue finding bug ;o)

Dirk Müller> suse's fontconfig is overriding the kde settings.

No, it doesn't. 

Dirk Müller> see /etc/fonts/suse-pre-user.conf especially the  

In /etc/fonts/fonts.conf you can see that suse-pre-user.conf
is included before ~/.fonts.conf. That means that a rule like

        <match target="font"> 
                <edit name="autohint"> 
                        <bool>true</bool> 
                </edit> 
                <edit name="antialias"> 
                        <bool>true</bool> 
                </edit> 
        </match> 

can be overridden in ~/.fonts.conf. And ~/.fonts.conf is the file
where KDE stores these settings. To make doubly sure I just tried it
again and switched of anti-aliasing in the KDE control center and it
works.

Sorry Dirk, I don't know if /etc/fonts/suse-pre-user.conf overrides KDE conf or
not, but one stuff is sure, I have the issue of the non-fonctionnal disabling of
the anti-aliasing via the KDE control-center interface and as soon as I've set
both autohint and antialias to false in /etc/fonts/suse-pre-user.conf, the issue
was solved !

Currently I see only the following problem with the settings in the KDE control centre:    1) There should be a button to disable the autohinter in      case you want to use the byte code interpreter.       To make it perfect, it would be necessary to give a list      of fonts for which this setting should be used as it doesn't      make sense for most fonts.     2) KDE should not use point size for the range to disable      the anti-aliasing. Only pixelsize makes sense here.      Currently KDE lets you select only point size but then      writes rules for both pointsize and pixelsize into ~/.fonts.conf.      The pixelsize is probably calculated from the pointsize for      the current display. This will fail when the same home directory      is used on machines with different monitors (NFS mounted home      directory).   If there were a button to disable the autohinter in the KDE control centre and a help text which explains clearly what is achieved by doing this, this would be the best solution.  Until then I can only recommend to copy the following rule from /etc/fonts/suse-pre-user.conf to your ~/.fonts.conf if you like that style of rendering:  <!-- ************************************************************ --> <!-- Hinting and antialiasing                                     --> <!-- ************************************************************ -->  <!--     Fonts which have high quality byte code interpreter instructions     can look very good in small sizes when rendered in black and white     (antialias=false) using the byte code interpreter (autohint=false).     The results look as good as high quality bitmap fonts.      On the other hand, most Fonts do not have good byte code interpreter     instructions and look *very* ugly when rendered like this.     I.e. for most fonts autohint=true and antialias=true gives best     results.      For fonts which do have good byte code instructions, it seems     to be a matter of taste. Most users apparently do not like the     bitmaps no matter how good they are and prefer to render     these fonts with anti-aliasing as well.      When rendering fonts which do have good byte code with anti-aliasing     (antialias=true), the byte code apparently doesn't help much, to     the contrary, it produces strange rendering artifacts.     Therefore it is usually better to always use the autohinter (autohint=true)     when rendering with anti-aliasing.  -->          <!--             Using the autohinter and anti-aliasing.             This is a good default for most fonts.         -->         <match target="font">                 <edit name="autohint">                         <bool>true</bool>                 </edit>                 <edit name="antialias">                         <bool>true</bool>                 </edit>         </match>          <!--             The following rule sets up black and white rendering with             the byte code interpreter for a small list of fonts which             are known to have good byte code and give bitmap quality             results at small sizes.             The pixelsize limit is set to '0' though, which effectively             disables this rule by default because most users don't like             that bitmap look and feel.             If you like a bitmap look and feel of your desktop,             copy this rule into your ~/.fonts.conf file and replace the '0'             with non-zero pixelsize limit. Using '18' as the pixelsize             limit is a good choice if you have the fonts in this list installed             and like a bitmap look and feel.          -->         <match target="font">                 <test name="family">                         <string>Andale Mono</string>                         <string>Arial</string>                         <string>Comic Sans MS</string>                         <string>Georgia</string>                         <string>Impact</string>                         <string>Trebuchet MS</string>                         <string>Verdana</string>                         <string>Courier New</string>                         <string>Times New Roman</string>                         <string>Tahoma</string>                         <string>Webdings</string>                         <string>Albany AMT</string>                         <string>Thorndale AMT</string>                         <string>Cumberland AMT</string>                 </test> 		<test name="pixelsize" compare="less_eq"> 				<double>0</double>        <!-- use a non-zero pixel size to enable this rule --> 		</test>                 <edit name="autohint">                         <bool>false</bool>                 </edit>                 <edit name="antialias">                         <bool>false</bool>                 </edit>         </match>   and replace the '0' for the pixelsize limit with something non-zero, for example 18 if you want to do it the same way as on Windows XP.  By the way, this style of rendering makes sense *only* for the fonts I listed in that rule above. Most other fonts do not have any reasonably good bytecode, the result is that for most fonts the rendering gets very bad when using the byte code interpreter and switching off anti-aliasing. Using the byte code interpreter *with* anti-aliasing is always bad, I could not find any font so far where this produces reasonable results.  The fonts in the above list have excellent byte code, if you use the byte code interpreter for these fonts and switch off anti-aliasing, you get a bitmap look and feel which is almost as good as hand-tuned bitmaps. This style is the default on Windows XP but not on Mac OSX where the default seems to be to use anti-aliasing always.  I made this bitmap like rendering the default for one beta (I think it was Beta1), but the overwhelming majority didn't like it.  Dirk, I think you also reported this as a bug "Antialiasing doesn't work anymore" ...  As the KDE control centre currently does not allow to fine tune these settings I recommend that you use the above rule in ~/.fonts.conf and do it manually.  Maybe, if time permits, I'll introduce a variable in /etc/sysconfig/fonts-config which can be used to set this bitmap like rendering as the system wide default.

Currently I see only the following problem with the settings in the
KDE control centre:

1) There should be a button to disable the autohinter in case you want
to use the byte code interpreter.

To make it perfect, it would be necessary to give a list of fonts for
which this setting should be used as it doesn't make sense for most
fonts.

2) KDE should not use point size for the range to disable the
anti-aliasing. Only pixelsize makes sense here.  Currently KDE lets
you select only point size but then writes rules for both pointsize
and pixelsize into ~/.fonts.conf.  The pixelsize is probably
calculated from the pointsize for the current display. This will fail
when the same home directory is used on machines with different
monitors (NFS mounted home directory).  If there were a button to
disable the autohinter in the KDE control centre and a help text which
explains clearly what is achieved by doing this, this would be the
best solution.  Until then I can only recommend to copy the following
rule from /etc/fonts/suse-pre-user.conf to your ~/.fonts.conf if you
like that style of rendering:

<!-- ************************************************************ -->
<!-- Hinting and antialiasing                                     -->
<!-- ************************************************************ -->

<!--
    Fonts which have high quality byte code interpreter instructions
    can look very good in small sizes when rendered in black and white
    (antialias=false) using the byte code interpreter (autohint=false).
    The results look as good as high quality bitmap fonts.

    On the other hand, most Fonts do not have good byte code interpreter
    instructions and look *very* ugly when rendered like this.
    I.e. for most fonts autohint=true and antialias=true gives best
    results.

    For fonts which do have good byte code instructions, it seems
    to be a matter of taste. Most users apparently do not like the
    bitmaps no matter how good they are and prefer to render
    these fonts with anti-aliasing as well.

    When rendering fonts which do have good byte code with anti-aliasing
    (antialias=true), the byte code apparently doesn't help much, to
    the contrary, it produces strange rendering artifacts.
    Therefore it is usually better to always use the autohinter (autohint=true)
    when rendering with anti-aliasing.

-->

        <!--
            Using the autohinter and anti-aliasing.
            This is a good default for most fonts.
        -->
        <match target="font">
                <edit name="autohint">
                        <bool>true</bool>
                </edit>
                <edit name="antialias">
                        <bool>true</bool>
                </edit>
        </match>

        <!--
            The following rule sets up black and white rendering with
            the byte code interpreter for a small list of fonts which
            are known to have good byte code and give bitmap quality
            results at small sizes.
            The pixelsize limit is set to '0' though, which effectively
            disables this rule by default because most users don't like
            that bitmap look and feel.
            If you like a bitmap look and feel of your desktop,
            copy this rule into your ~/.fonts.conf file and replace the '0'
            with non-zero pixelsize limit. Using '18' as the pixelsize
            limit is a good choice if you have the fonts in this list installed
            and like a bitmap look and feel. 
        -->
        <match target="font">
                <test name="family">
                        <string>Andale Mono</string>
                        <string>Arial</string>
                        <string>Comic Sans MS</string>
                        <string>Georgia</string>
                        <string>Impact</string>
                        <string>Trebuchet MS</string>
                        <string>Verdana</string>
                        <string>Courier New</string>
                        <string>Times New Roman</string>
                        <string>Tahoma</string>
                        <string>Webdings</string>
                        <string>Albany AMT</string>
                        <string>Thorndale AMT</string>
                        <string>Cumberland AMT</string>
                </test>
		<test name="pixelsize" compare="less_eq">
				<double>0</double>        <!-- use a non-zero pixel size to enable this rule -->
		</test>
                <edit name="autohint">
                        <bool>false</bool>
                </edit>
                <edit name="antialias">
                        <bool>false</bool>
                </edit>
        </match>


and replace the '0' for the pixelsize limit with something non-zero,
for example 18 if you want to do it the same way as on Windows XP.  By
the way, this style of rendering makes sense *only* for the fonts I
listed in that rule above. Most other fonts do not have any reasonably
good bytecode, the result is that for most fonts the rendering gets
very bad when using the byte code interpreter and switching off
anti-aliasing. Using the byte code interpreter *with* anti-aliasing is
always bad, I could not find any font so far where this produces
reasonable results.  The fonts in the above list have excellent byte
code, if you use the byte code interpreter for these fonts and switch
off anti-aliasing, you get a bitmap look and feel which is almost as
good as hand-tuned bitmaps. This style is the default on Windows XP
but not on Mac OSX where the default seems to be to use anti-aliasing
always.

I made this bitmap like rendering the default for one beta (I think it
was Beta1), but the overwhelming majority didn't like it.

Dirk, I think you also reported this as a bug "Antialiasing doesn't
work anymore" ...

As the KDE control centre currently does not allow to fine tune these
settings I recommend that you use the above rule in ~/.fonts.conf and
do it manually.  Maybe, if time permits, I'll introduce a variable in
/etc/sysconfig/fonts-config which can be used to set this bitmap like
rendering as the system wide default.

Florent> Sorry Dirk, I don't know if /etc/fonts/suse-pre-user.conf
Florent> overrides KDE conf or not,

No, it doesn't, as I explained above. And I verified on Beta3
that it doesn't. Therefore I will close this bug as WORKSFORME.

Florent> but one stuff is sure, I have the issue of the
Florent> non-fonctionnal disabling of the anti-aliasing via the KDE
Florent> control-center interface and as soon as I've set both
Florent> autohint and antialias to false in
Florent> /etc/fonts/suse-pre-user.conf, the issue was solved !

As I explained above, you should not do this for all fonts,
because the rendering gets really bad for many free fonts when
you od this.

And I recommend not to do this in /etc/fonts/suse-pre-user.conf,
better do this by copying the rule to you ~/.fonts.conf and
change it there. By doing it in your ~/.fonts.conf you have
the benefit that your change survives a system update, setup
in your home directory will not be overwritten.

/etc/fonts/suse-pre-user.conf doesn't override the KDE settings
→ WORKSFORME.

Even if it works for you and if /etc/fonts/suse-pre-user.conf doesn't override
the KDE settings (I haven't tried but I trust you on this point), for me it's a bug.

The bug is perhaps a KDE one but on SuSE 9.3, unchecking the box works, there is
no reason it isn't the case on SuSE 10.0.

It doesn't matter for me now as I know the trick but chance there will be users
who will hate the default fonts rendering and would prefer a "MS Windows" like
sharp rendering.

As you said in the press release when opening SuSE : 

"Novell hopes that its new openSUSE project will make the process of obtaining a
working Linux environment easy for both end users and developers"

It should be easy for newbies to disable anti-aliasing as you would do in M$
Windows.

Believe me, a bad rendering of fonts could be a serious handicap for adopting a
distro.

I've already tried SuSE 9.3 (and perhaps 9.1 or 9.2) briefly cause the fonts
were ugly for me and I didn't find a patched freetype with BYTECODE.

I've made a diff between the ~/.fonts.conf with and without the checkbox checked
and the file is the same.

The file is too similar to the one from my SuSE 9.3 where I've unchecked the
box. So, why a same file between SuSE 9.3 and SuSE 10.0 doesn't produce the good
 result on SuSE 10.0 and I'm obliged to deal with /etc/fonts/suse-pre-user.conf ?

I'm my opinion, there is a problem somewhere. Perhaps it's KDE related, perhaps
this is another issue but you should be able to disable anti-aliasing if you
dislike.

But you're probably right that a good render for some fonts (like MS TT Core
Fonts and for the Tahoma I import from Windows) is not the same for free fonts.

Perhaps, SuSE should contain an utility in Yast where you can choose to enable
or disable anti-aliasing, and where there is a default configuration for each
fonts possible with the best font setup with or without anti-aliasing.

For example, I perfectly now that M$ Fonts render better with hinting disabled
if anti-aliasing is disabled.

Sorry to reopen the bug again, for me there is no issue now but I think it's
important for others users that have not the skills to setup the fonts better
but would like to gain a better rendering.

Florent> Even if it works for you and if /etc/fonts/suse-pre-user.conf
Florent> doesn't override the KDE settings (I haven't tried but I
Florent> trust you on this point), for me it's a bug.

Just try it, you will see it doesn't.

Florent> The bug is perhaps a KDE one but on SuSE 9.3, unchecking the
Florent> box works, there is no reason it isn't the case on SuSE 10.0.

You said you compiled your own freetype on SuSE 9.3. I don't know how you
did that, anything can happen then, it's not easy for me to guess what
you did when you compiled your freetype. Maybe you disabled the
Florent> autohinter.

Florent> I've already tried SuSE 9.3 (and perhaps 9.1 or 9.2) briefly cause the
Florent> fonts were ugly for me and I didn't find a patched freetype with
Florent> BYTECODE.

It was always documented in the freetype2.spec file in SuSE Linux how
to do this.  I already had the patch to enable the byte code
interpreter included in our freetype package for ages. Long ago it was
even applied.  Then we stopped to apply it, because the majority of
user didn't like this rendering style.

Now, with recent versions of freetype and fontconfig it has become
possible to select the byte code interpreter at run time, i.e. even it
the byte code interpreter is compiled in, you can still choose with
the fontconfig configuration whether to use it or not. Therefore I decided
to enable the byte code interpreter again.

Florent> I've made a diff between the ~/.fonts.conf with and without the
Florent> checkbox checked and the file is the same.

No, it's not the same. Maybe you forgot to save. You need to click on
the "Apply" button in the kde contsol centre. Changing the checkbox
only is not enough.

Let's assume there is no ~/.fonts.conf file at the start.

Then, when you disable the anti-aliasing from 8 to 15 point, the following ~/.fonts.conf
is written when you click on "Apply":

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintmedium</const>
  </edit>
 </match>
 <match target="font" >
  <test compare="more" name="size" qual="any" >
   <double>8</double>
  </test>
  <test compare="less" name="size" qual="any" >
   <double>15</double>
  </test>
  <edit mode="assign" name="antialias" >
   <bool>false</bool>
  </edit>
 </match>
 <match target="font" >
  <test compare="more" name="pixelsize" qual="any" >
   <double>11</double>
  </test>
  <test compare="less" name="pixelsize" qual="any" >
   <double>20</double>
  </test>
  <edit mode="assign" name="antialias" >
   <bool>false</bool>
  </edit>
 </match>
</fontconfig>

If you enable the anti-aliasing again by and click "Apply", the file is shortened to:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintmedium</const>
  </edit>
 </match>
</fontconfig>

And this is read *after" suse-pre-user.conf and therefore not
overwritten by suse-pre-user.conf.

Therefore this bug is WORKSFORME.

You told me in private mail that you want that better documented in the
SuSE user manual.

In that case open a bug against the documentation and put me in to the CC:.

But don't reopen this bug because it talks about completely different
stuff.  The subject says "Unchecking "Use anti-aliasing for fonts" in
the KDE control center has no effect" which is wrong, it has an effect.

There is definitely something different compared to SuSE 9.3. And aa is not 
disabled via the ckeckbox in kcontrol, as it should be. Disabling only works, if 
excluding a range while having aa enabled, but not if one has it completely 
disabled.

In 9.3 I re-compiled freetype2 after altering the spec-file, i.e. removing the % 
in the bytecode-line. I then disabled the anti-aliasing in kcontrol. The result 
is no Anti-Aliasing.

Same steps with SuSE 10 beta 4, generate an freetype2 RPM without the -bytecode 
in the filename, which was part of it in 9.3. Also, I did not have to remove the
 % in front of the bytecode-line, as there was already just one %.
The result is not the same, as anti-aliasing is not disabled, if I uncheck the 
box in kcontrol.

There is one mistake in comment 17!

- Enabling anti-alias and disabling it for 8-15 generates the stated .fonts, 
which disables the aa for those font-sizes, true.

- Enabling just the checkbox, i.e. enabling aa, results in the stated .fonts-
file and enables aa without excluding anything, true.

+ Yet disabling the checkbox results in the same .fonts as enabling it and not 
giving any range to exlude.

I think the problem is that in 9.3 there was no rule that set aa by default, so 
there was not need to override it. aa was only enabled, if it was explicitely 
stated in the .fonts file.
However in SuSE 10 the .fonts-file would have to override the default setting, 
thus un-checking the box in kcontrol must add some lines to .fonts that clearly 
state that aa is disabled. At the moment disabling aa is more like not enabling 
it and thus not sufficient to override any previous rules.

Sven> + Yet disabling the checkbox results in the same .fonts as
Sven> enabling it and not giving any range to exlude.

Yes, you are right. I think this is a bug in KDE. KDE should write
a rule to disable the anti-aliasing in that case. Like this:

 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>false</bool>
  </edit>
 </match>

This bug also existed on 9.3. If KDE doesn't write this, there
is no guarantee that anti-aliasing is turned off, the global default
could be anything.

Sven> I think the problem is that in 9.3 there was no rule that set aa by
Sven> default,

You are right that there was no rule set in the global /etc/fonts/
to enable anti-aliasing in SuSE 9.3. 

Sven> so there was not need to override it. aa was only enabled, if
Sven> it was explicitely stated in the .fonts file.

No, even if not stated in the ~/.fonts.conf file, anti-aliasing was
nevertheless enabled. At least for me it was always like that.

I see now in the fontconfig sources, fontconfig.h line 71

    #define FC_ANTIALIAS	    "antialias"		/* Bool (depends) */
    #define FC_HINTING	    "hinting"		/* Bool (true) */

Looks like the default value of FC_ANTIALIAS is not always true but
"depends" (on what??).

The default value for subpixel hinting depended on the monitor, it was
usually enabled automatically for TFT displays.  But as most people
prefer grayscale rendering even on TFT displays (I had bugreports
requesting this), we did set this variable never to use subpixel
rendering by default.

I'll try to find out on what the default for anti-aliasing "depends".

Reassigning to kde-maintainers@suse.de
because kcontrol should write

 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>false</bool>
  </edit>
 </match>

into ~/.fonts.conf if the "antialiasing" checkbox is disabled without
selecting a range.

I think this is necessary to make sure that anti-aliasing is really
turned off.

Mike> I'll try to find out on what the default for anti-aliasing "depends".

It seems to depend on the screen/monitor used:

xorg-x11/xc/lib/Xft/xftdpy.c around line 467:

    if (FcPatternGet (pattern, FC_ANTIALIAS, 0, &v) == FcResultNoMatch)
    {
	FcPatternAddBool (pattern, FC_ANTIALIAS,
			   XftDefaultGetBool (dpy, FC_ANTIALIAS, screen,
					      True));
    }

Same file around line 419:

    Bool
    XftDefaultGetBool (Display *dpy, const char *object, int screen, Bool def)
    {
	FcResult	    r;
	FcValue	    v;

	r = _XftDefaultGet (dpy, object, screen, &v);
	if (r != FcResultMatch || v.type != FcTypeBool)
	    return def;
	return v.u.b;
    }

I.e. if anti-aliasing is neither set to true nor false in
the fontconfig setup,

    if (FcPatternGet (pattern, FC_ANTIALIAS, 0, &v) == FcResultNoMatch)

will be true and the default will be determined depending on the type
of screen.

I.e., if the global fontconfig setup in /etc/fonts does not set
anti-aliasing, it may default to true or false depending on the
screen.

A quick test with a 9.3 machine I have here reveals that anti-aliasing
defaults to true when I start an application (example here "xfd")
locally:

    mike@nozomi:/etc/fonts$ grep -ri anti *
    mike@nozomi:/etc/fonts$ FC_DEBUG=4 xfd -fa sans | grep -i anti
	    antialias: FcTrue(s)
	    antialias: FcTrue(s)
	    antialias: FcTrue(s)
	    antialias: FcTrue(s)
	    antialias: FcTrue(s)

    mike@nozomi:/etc/fonts$

but defaults to false when I start an application after logging
in remotely with "ssh -X":

    mike@nozomi:/etc/fonts$ FC_DEBUG=4 xfd -fa sans | grep -i anti
	    antialias: FcFalse(s)
	    antialias: FcFalse(s)
	    antialias: FcFalse(s)
    mike@nozomi:/etc/fonts$

That would explain why Sven and Florent get antialiasing switched
off by default:

Sven> In 9.3 I re-compiled freetype2 after altering the spec-file,
Sven> i.e. removing the % in the bytecode-line. I then disabled the
Sven> anti-aliasing in kcontrol. The result is no Anti-Aliasing.

although I never saw that. Probably happens only on a few displays.

There is a similar problem with the subpixel hinting settings in the KDE
control centre.

See also bug #59409 (problems with /etc/fonts/local.conf and subpixel rendering).

If the checkbox "Use sub-pixel hinting" in the KDE control centre is unchecked,
KDE only writes:

    <?xml version="1.0"?>
    <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
    <fontconfig>
     <match target="font" >
      <edit mode="assign" name="hinting" >
       <bool>true</bool>
      </edit>
     </match>
     <match target="font" >
      <edit mode="assign" name="hintstyle" >
       <const>hintmedium</const>
      </edit>
     </match>
    </fontconfig>

to ~/.fonts.conf which doesn't really guarantee that sub-pixel hinting
is turned off, it can be anything depending on the global default then.

KDE should add a rule like

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const>unknown</const>
      </edit>
     </match>

or

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const>none</const>
      </edit>
     </match>

to guarantee that sub-pixel hinting is really off.

If sub-pixel hinting is turned on in the KDE control centre and
"grayscale" is selected, KDE writes

    <?xml version="1.0"?>
    <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
    <fontconfig>
     <match target="font" >
      <edit mode="assign" name="hinting" >
       <bool>true</bool>
      </edit>
     </match>
     <match target="font" >
      <edit mode="assign" name="hintstyle" >
       <const>hintmedium</const>
      </edit>
     </match>
     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const></const>
      </edit>
     </match>
    </fontconfig>

which is a bit weird as well. Note that there is nothing between
"<const>" and "</const>" in the last rule.

Better write 

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const>none</const>
      </edit>
     </match>

here as well. At least this would be clearer.

I checked and what KDE writes to ~/.fonts.conf when "grayscale" is
selected is really wrong and doesn't work.

When there= is nothing between "<const>" and "</const>", the
value of rgba is not changed as the following test shows:

mfabian@magellan:/etc/fonts$ FC_DEBUG=4 xfd -fa freesans | grep rgba
        Edit rgba Assign ;
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        Edit rgba Assign ;
mfabian@magellan:/etc/fonts$

Here the rule

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const></const>
      </edit>
     </match>

had been written by KDE into ~/.fonts.conf and as you can see
nothing was edited:

    Edit rgba Assign ;

the original value "1" which came from a previously read config
file in /etc/fonts was not changed.

Then I manually changed the rule written by KDE in ~/.fonts.conf
to

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const>none</const>
      </edit>
     </match>

and repeated the test:

mfabian@magellan:/etc/fonts$ FC_DEBUG=4 xfd -fa freesans | grep rgba
        Edit rgba Assign none;
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        rgba: 1(i)(s)
        Edit rgba Assign none;
        rgba: 5(i)(w)
        rgba: 5(i)(w)
        rgba: 5(i)(w)
        rgba: 5(i)(w)
mfabian@magellan:/etc/fonts$

Now you can see that an assignment is really done:

     Edit rgba Assign none;

and the value of rgba changes from 1 to 5.

Looking at the rendering results with xmag confirms what the debug
output says.

I.e. this must be fixed in KDE.

good luck Lubos :) 

Fixed in KDE SVN, when somebody will be updating kdebase3 please add also this 
patch. 
 

Created attachment 51929 [details]
kdebase3 patch

coolo has locked kdebase, IMHO this should also be done for 10.0 

from what I understood KDE SVN, the patch is in the 3.5 branch already, so 
it's part of our packages now. For 10.0: I'm not so sure. It seems broken 
since quite some time and I didn't hear too many complain and the work around 
is pretty easy, so it should be enough to have this fixed for future products