Bug 104560 - Fonts look different
Summary: Fonts look different
Status: VERIFIED INVALID
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: X.Org (show other bugs)
Version: Beta 1
Hardware: All Linux
: P5 - None : Normal
Target Milestone: ---
Assignee: Mike Fabian
QA Contact: Stefan Dirsch
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-13 09:24 UTC by Jan Engelhardt
Modified: 2005-09-10 10:21 UTC (History)
0 users

See Also:
Found By: Beta-Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
2.2.99 (19.84 KB, image/png)
2005-08-13 09:27 UTC, Jan Engelhardt
Details
2.3.2 (20.95 KB, image/png)
2005-08-13 09:28 UTC, Jan Engelhardt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Engelhardt 2005-08-13 09:24:30 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.
Comment 1 Jan Engelhardt 2005-08-13 09:27:22 UTC
Created attachment 45964 [details]
2.2.99
Comment 2 Jan Engelhardt 2005-08-13 09:28:03 UTC
Created attachment 45966 [details]
2.3.2
Comment 3 Mike Fabian 2005-08-15 09:47:50 UTC
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.


Comment 4 Mike Fabian 2005-08-15 09:49:34 UTC
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>

Comment 5 Mike Fabian 2005-08-15 10:05:08 UTC
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).