Bugzilla – Bug 104560
Fonts look different
Last modified: 2005-09-10 10:21:39 UTC
fontconfig-2.2.99 from SUSE 9.3 vs fontconfig-2.3.2 from SUSE 10.0 Beta 1. The font remained the same (Tahoma), but it looks different, e.g. the "m" in xterm is has become wider in 10.Beta1.
Created attachment 45964 [details] 2.2.99
Created attachment 45966 [details] 2.3.2
First of all, that is looks "different" is not a bug. It looks different on purpose, see the CHANGES file of freetype 2.1.10: LATEST CHANGES BETWEEN 2.1.10 and 2.1.9 I. IMPORTANT BUG FIXES [...] - Another serious bug in handling TrueType hints caused many distortions. It has been introduced in version 2.1.8, and it is highly recommended to upgrade. [...] Whether the new rendering is better or worse is a matter of taste. Font rendering is so much a matter of taste, other people think it is great what you think looks awful. Really. It is absolutely impossible to make everybody happy by default. With the freetype2 and fontconfig packages from Beta 1 you have more possibilities then ever to finetune for you personal preferences though.
Have a look at the file /etc/fonts/suse-pre-user.conf. There you will find: <!-- ************************************************************ --> <!-- 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>
The byte code interpreter is compiled into the freetype2 package now. That means you don't have to recompile your freetype2 package to enable the byte code interpreter any more. To enable the byte code interpreter, you only need to set autohint=false in the fontconfig setup. But the byte code interpreter works best only for a short list of fonts which have good byte code (all such fonts I know of are listed in comment #4). And it works only well when antialiasing is not used. With this setting, you get look and feel as if using high quality bitmap fonts (By the way, rendering like this for pixelsize < 18 is the default on Windows XP). I made this the default for an early preview of SuSE Linux 10.0. Some people thought it is great but the huge majority didn't like it. Therefore I disabled this rule again by using pixelsize <= 0 as the limit. If you want to enable it, you can add such a rule in your ~/.fonts.conf and use a non-zero pixelsize. When using the byte code interpreter (autohint=false) with antialiasing, you get many distortions. With anti-aliasing, always use the autohinter. When using the autohinter, you have 3 different options for the hintstyle: hintnone hintmedium hintfull For example, you can use <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintnone</const> </edit> </match> to use the hintstyle "hintnone" for all your fonts. With "hintnone" you get more gray but the glyphs keep their shape best. With "hintfull" you get less gray because stems of glyphs are adjusted to fit the pixel grid but you get some deformation of the glyphs. "hintmedium" is inbetween. Try to configure it to a setting you like best. The current defaults are a compromise which seems to be what most people like. Closing as INVALID. (It is not a bug that it looks different, many people think it is OK like that).