Bugzilla – Bug 113637
Unchecking "Use anti-aliasing for fonts" in the KDE control center has no effect
Last modified: 2005-10-08 07:16:14 UTC
Hi, As I hate the default rendering for fonts (on SuSE 9.3, I've disabled the anti-aliasing, recompiling the freetype RPM with the BYTECODE_INTERPRETER, and setup the fonts as on a scrap M$ Windows OS ;o)), I've tried to uncheck the "Use anti-aliasing for fonts" in the KDE control center. But it has no effect even when restarting X. The fonts remain anti-aliased. I've previously have this beahviour on a Mandriva 10.1 system. There is a tweak around this, perhaps there is a patch from KDE or a way to patch it easilly (but I'm lazy to go in the source code and recompiling KDE ;o)) : If you let the anti-aliasing checkbox checked but if you press on the configure button and check exclude range (I've let the standard setting between 8 and 15 pt), the fonts are now correctly not anti-aliased. The fonts are then ugly but I think this is the normal uglyfication before applying a patched freetype with BYTECODE_INTERPRETER). I don't think this is ugglier with the exclude range checked.
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.
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