Bug 186109

Created attachment 90073 [details]
Screenshots

Please don't compress pictures but only attach them the next time.
Mike please add a comment.

I already noticed that as well. I doesn't happen only with the Déjà Vu fonts,
it happens with several other fonts as well.

Created attachment 90622 [details]
arial.png

The problem occurs only when sub-pixel hinting is on.

Seems to be a problem in freetype2.

@Michael: Sorry, me was inspired by the advice for attaching y2logs.
@Mike: Oh. Arial is not autohinted nor anti-aliased by default (/etc/fonts/suse-hinting.conf), so I did not notice the fact that it behaves similar.

Arial is autohinted and antialiased by default because the
rule in /etc/fonts/suse-hinting.conf which switches off the
auto-hinter and anti-aliasing is not activated by default.
By default it contains:

                <test name="pixelsize" compare="less_eq">
                                <double>0</double>
                </test>

and the comparison <= 0 is always false.

Only if you set a limit different from 0 in the variable

    BYTECODE_BW_MAX_PIXEL="0"

in /etc/sysconfig/fonts-config the anti-aliasing and auto-hinting is
switched off by default for the fonts which are known to have good
byte code (This can be overridden again by the settings in ~/.fonts.confg
which is written by the KDE control centre).

I'm just upgrading freetype to 2.2.1 for the next version of SUSE
Linux.  Even with freetype 2.2.1 this bug still exists.

@Mike: Duh. I forgot my change of /etc/sysconfig/fonts-config when I installed msttfonts. Sorry.

I have finished the upgrade of freetype to 2.2.1 for the next version
of SUSE Linux now.

If you like to test the rendering, you can find packages for
SUSE Linux 10.1 here:

ftp://ftp.suse.com/pub/projects/m17n/10.1/RPMS

(freetype2 and ft2demos packages).

These packages don't improve anything for the particular problem
in this bugreport though.

Created attachment 91205 [details]
rgb-autohinting-on.png

created with

    ftview 12 /usr/X11R6/lib/X11/fonts/truetype/DejaVuSans.ttf

Then switching the rendering mode to "LCD-optimized rendering on (RGB)"
by pressing 'L' twice, then switching to "forced autohinting on"
by pressing 'f'.

Created attachment 91206 [details]
rgb-autohinting-off.png

created with

    ftview 12 /usr/X11R6/lib/X11/fonts/truetype/DejaVuSans.ttf

Then switching the rendering mode to "LCD-optimized rendering on
(RGB)" by pressing 'L' twice (and then *not* switching to "forced
autohinting on" by pressing 'f').

According to comment #11 and #12 this seems to be a problem in
the autohinter when horizontal LCD hinting is on.

(It doesn't happen for vertical LCD hinting).

I added the upstream freetype developer Werner LEMBERG <wl@gnu.org> to the
CC:.

Werner, do you have any idea what is causing this?

I'm not sure whether this is related or not:

http://lists.nongnu.org/archive/html/freetype-devel/2005-08/msg00095.html

http://lists.nongnu.org/archive/html/freetype-devel/2005-09/msg00084.html

According to these mails by David Turner this seems to be an old problem:

http://lists.nongnu.org/archive/html/freetype-devel/2005-09/msg00088.html

David TurnerAll I can say now is that there is no difference regarding
David Turnerhinting of 'ö' in DejaVuSans between the current CVS and
David Turnerprevious releases of FreeType.
David Turner
David TurnerI've tested both 2.1.8 and 2.1.9 and they both exhibit the
David Turnerproblem when LCD-decimated rendering is used in "ftview"
David Turner
David TurnerWhat it means is that it's not something that we're going
David Turnerto fix real soon now, mainly because it _probably_ means a
David Turnerlot of tinkering with the hinting algorithm

http://lists.nongnu.org/archive/html/freetype-devel/2005-09/msg00091.html

David Turner> I just tested 2.1.7, and it exhibits the same problem than other
David Turner> releases with the 'ö', at least in 'ftview'.

And according to Frédéric Crozat this problem was only hidden
because of bugs in libXft:

http://lists.nongnu.org/archive/html/freetype-devel/2005-09/msg00099.html

Frédéric Crozat> Ok, I found why Mdk 10.0 was able to render 'ö' correctly : Xft 2.1.2
Frédéric Crozat> was buggy at that time and was not setting FT_LOAD_TARGET_LCD or
Frédéric Crozat> FT_LOAD_TARGET_LCD_V when doing subpixel rendering, which is why 'ö' was
Frédéric Crozat> rendered differently than when using ftview. This bug was fixed in Xft
Frédéric Crozat> 2.1.3, but simply backporting missing FT_LOAD_TARGET_LCD to Xft gave bad
Frédéric Crozat> the 'ö' rendering issue with Mdk 10.0.

I wrote in comment #13:

Mike Fabian> According to comment #11 and #12 this seems to be a problem in
Mike Fabian> the autohinter when horizontal LCD hinting is on.

The Déjà Vu developers told me that they have optimized the
TrueType instructions in the Déjà Vu fonts for anti-aliased
rendering. That means one gets best results for anti-aliased
rendering of the Déjà Vu fonts when the byte code interpreter
is used (which is the case when the autohinter is turned off).

This is different from the Microsoft webfonts and the agfa-fonts where
the TrueType instructions are optimized for black-and-white rendering
(no anti-aliasing). I.e. in case of the Microsoft and the agfa-fonts
it doesn't help to use the byte-code interpreter for anti-aliased
rendering, it helps only for black-and-white rendering. For the Déjà
Vu fonts, the situation is reversed, the byte-code interpreter helps
for anti-aliased rendering but not for black-and-white rendering.

*** Bug 170067 has been marked as a duplicate of this bug. ***

I checked many fonts again carefully with ftview now and found that
high quality TrueType fonts with good byte code always look much
better without the autohinter (i.e. with the byte code interpreter if
the byte code interpreter is enabled in freetype).  It doesn't matter
whether anti-aliasing is used or not these fonts always look much
better with the byte code interpreter.

Almost all TrueType fonts which have byte code look better with the
byte code interpreter although there are a few exceptions. Probably
the byte code is just very bad in these exceptional cases.

TrueType fonts which do *not* have byte code usually look sharper
(less blurry) with the autohinter than without.  If there is no byte
code, switching of the autohinter means no hinting at all.

*But*, the autohinter often severely distorts the metrics, see bug
#215602.

Therefore, it is better to use the autohinter only for fonts where
such bad distortions don't happen until this problem is fixed in the
autohinter.

New fonts-config submitted to STABLE:

-------------------------------------------------------------------
Wed Nov 15 19:20:16 CET 2006 - mfabian@suse.de

- Bugzilla #215602:  don't use the embedded bitmaps in the IPA
  fonts because they are only available in 12, 14, and 16 pixels.
- Bugzilla #215602: Don't use the autohinter for fonts where it
  it distorts the metrics so badly that even the digits which
  should be monospaced are not monospaced at all anymore.
- Don't use the autohinter for good quality TrueType fonts.

-------------------------------------------------------------------

You can download the new package for testing here:

http://software.opensuse.org/download/M17N/SUSE_Factory/noarch/fonts-config-20061025-8.1.noarch.rpm

/usr/sbin/fonts-config generates /etc/fonts/suse-hinting.conf and
/etc/fonts/suse-bitmaps.conf which contain the new setup.

As the misrendering of 'ö' reported in this bug happens only with the
autohinter, not using the autohinter for the Déjà Vu fonts fixes this.
And not only this problem, the Déjà Vu fonts look much better overall
(except for the glyphs which have no byte code. But most important
glyphs in the Déjà Vu fonts have byte code).

Closing as FIXED.