176334 - [GTK1+Xft]mozilla ignores disabling anti aliasing in fonts.conf with xft2/fontconfig

Status: RESOLVED WONTFIX

(Core :: Layout: Text and Fonts, defect)

Description

[Andrew Dolgov]

User-Agent:       TorMozilla/1.0 (X; PDP-11; 8-bit)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021023

I have AA disabled for some fonts in fonts.conf like this:

<match target="font">
        <test qual="any" name="size" compare="less_eq">
                <int>14</int>
        </test>
        <test qual="any" name="size" compare="more_eq">
                <int>7</int>
        </test>
        <edit name="antialias" mode="assign">
                <bool>false</bool>
        </edit>
</match> 

Mozilla ignores this completely and small fonts are anti aliased. Maybe is a
fontconfig interaction problem? The file (/etc/fonts.conf) is read by Mozilla
(it outputs warnings if I mess up with the syntax). 

The excerpt above works fine for all other applications (gnome2, for example).

BTW, font family matching like this:

<match target="font">
        <test qual="any" name="family">
                <string>Tahoma</string>
        </test>
        <edit name="antialias" mode="assign">
                <bool>false</bool>
        </edit>

does work fine.



Reproducible: Always

Steps to Reproduce:
1. Build Mozilla with XFT2
2. Run it :)
3.

Comment 1

[Christopher Hoess (gone)]

blizzard, this is you, right?

Comment 2

[Christopher Hoess (gone)]

oops, wrong address (please don't hurt me!)

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

->blizzard.  Confirming too, since I've noticed this as well.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(To be more specific, what I noticed was that the global setting in RH |
Preferences | Fonts doesn't do anything.  I suspect it's the same underlying
problem, and that setting may even manipulate fonts.conf, but not per-font
settings in fonts.conf.)

Comment 5

[Moses Lei]

I see the same problem here. Everything is antialiased even when it's turned off
in fonts.conf.

I know in certain cases Mozilla uses pixel heights for font sizes internally;
might this be part of the problem? (fonts.conf is in points unless another unit
is specified, iirc)

Here I'm running fcpackage2 with XFree 4.2.1, freetype 2.1.2 on Debian unstable.

Comment 6

[Christopher Blizzard (:blizzard)]

Yeah, I need to read those settings.  The DPI settings are actually handled in
another bug hanging off the tracking bug, but everything else should be done here.

Comment 7

[Christopher Blizzard (:blizzard)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Creating a module constructor and calling FcInit() there fixes this for me
(although I'm not sure exactly what Preferences | Fonts is using).  I'll attach
the patch I used (which also cleans up some build warnings in the same file).

However, I suspect there's a better place to call FcInit, I just can't think of
it right now...

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch to call FcInit in module constructor

Comment 10

[Christopher Blizzard (:blizzard)]

Comment on attachment 114233 [details] [diff] [review]
patch to call FcInit in module constructor

Can you attach a patch that just makes those changes?

On that note, though, shouldn't those FT2 changes be in an #ifdef for freetype,
not corexfonts?

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: perhaps a better approach?

This calls it in NS_IsXftEnabled, only if it's enabled.

With diff -uw (ignoring whitespace), this looks like this:

Index: nsFontMetricsUtils.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/gtk/nsFontMetricsUtils.cpp,v
retrieving revision 1.1
diff -u -3 -w -r1.1 nsFontMetricsUtils.cpp
--- nsFontMetricsUtils.cpp	12 Oct 2002 02:03:32 -0000	1.1
+++ nsFontMetricsUtils.cpp	16 May 2003 21:50:54 -0000
@@ -93,12 +93,10 @@
	 been_here = PR_TRUE;
	 nsCOMPtr<nsIPref> prefService;
	 prefService = do_GetService(NS_PREF_CONTRACTID);
-	 if (!prefService)
-	     return PR_TRUE;

-	 nsresult rv;
-
-	 rv = prefService->GetBoolPref("fonts.xft.enabled", &cachedXftSetting);

+	 if (prefService) {
+	     nsresult rv = prefService->GetBoolPref("fonts.xft.enabled",
+						    &cachedXftSetting);

	 // Yes, this makes sense.  If xft is compiled in and there's no
	 // pref, it's automatically enabled.  If there's no pref, check
@@ -113,6 +111,10 @@

	     cachedXftSetting = PR_TRUE;
	 }
+	 }
+
+	 if (cachedXftSetting)
+	     FcInit();
     }

  end:

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(I haven't tested that this still fixes the bug, though, since the fonts
preference in the KDE control panel doesn't seem to affect Mozilla.  Either that
means the bug isn't fixed, or that the KDE control panel is tweaking a different
setting from the one in the GNOME settings, or perhaps that I just can't see the
difference.)

Comment 13

[Christopher Blizzard (:blizzard)]

I think there's another bug related to not recognizing the AA setting.  I think
that nalin pointed me at the code to do that, but I can't find it at the moment.

Comment 14

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I actually can't reproduce the bug in a GTK2+Xft build, so I suspect the bug may
exist only for GTK1+Xft.  Back when I had such a build, calling FcInit() fixed
the bug, so I suspect the patch above should work...

Comment 15

[keithp]

Mozilla passes pixel size, not point size to fontconfig, so you need to compare
pixel sizes instead of point sizes in your configuration.  I'd rather see
Mozilla pass point sizes so that it would reflect the Xft configured DPI, but
it's always used pixel sizes in the past...

Comment 16

[Bernhard Walle]

I never had such a problem in the past.

I updated to Firefox 0.9 and the problem occured. It's also present in Mozilla
Thunderbird. (Cannot test Mozilla nightly builds because there seems to be no
nightly builds for Gtk2/Xft.)

Comment 17

[Marciano Siniscalchi]

I can confirm this on Firebird 0.9, and Thunderbird 0.6 and 0.7. Sadly, Firebird
<= 0.8 and Thunderbird <= 0.5 were OK... :-(

This is using fontconfig-2.2.1, XFree86-4.3.0.1 both from SuSE 9.0 RPM packages.
Fontconfig works as intended under both Gnome 2.6 and KDE 3.2.3

M

Comment 18

[kmike]

I think bug 236739 is related (if not duplicate). It is regression from the fix
of   bug 197037.

Comment 19

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't think it's related.  And I was under the impression that this bug was
present in Gtk1+Xft builds but not Gtk2+Xft builds.

Comment 20

[Bernhard Walle]

The bug *is* present in Gtk2/Xft build. And in my opinion, it makes the browser
unusable (the most important thing of a browser is to render text ...).

Comment 21

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This bug, or the recent regression due to a broken fonts.conf shipped by your
distro that's described in bug 236739, which is a *different bug*, and a bug in
your fonts.conf rather than a bug in Mozilla?

Comment 22

[Bernhard Walle]

Yes, your're right. It was a "bug" in my fonts.conf (but generated by KDE
originally).

Comment 23

[nulldomain]

This bug is still present on my firefox .10.1 gtk2+xft linux builds.  It makes
the browser very unpleasant and pretty much unuseable.

Comment 24

[Mats Palmgren (inactive)]

Gtk1/xlib widget code has been removed on trunk and this bug doesn't seem
like a branch candidate.  Please reopen only if it can be reproduced in
a recent trunk build (cairo-gtk2).

-> WONTFIX