User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040220 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040320 I'm using Gnome 2.6 and a slightly tweaked "/etc/fonts/fonts.conf" Fontconfig file which tells the renderer to antialias all fonts _except_ for those whose size falls in a certain range. Mozilla seems to "not notice" this setting and antialiases all fonts equally. This applies to the client area and the UI controls alike. Something has changed in the way Mozilla "talks" to FreeType2 and/or Fontconfig and/or XFT (?), I believe. It used to be (up till rv:1.6) that it obeyed _all_ the settings specified via Fontconfig just like all other GTK2-based applications do, now somehow _some_ of the settings are ignored. The font face and size are consistent with the system settings, but the selective anti-aliasing is not. Reproducible: Always Steps to Reproduce: 1. Start Mozilla 2. 3. Actual Results: All fonts (both in the client area and the UI controls) are antialiased equally, contrary to system-wide settings. Expected Results: Fonts (both in the client area and the UI controls) are not antialiased if their size falls within a certain range, as specified through system-wide settings. Here are the versions of the packages on my system that I think might be relevant: xft-2.1.2 fontconfig-2.2.2 freetype-2.1.8

Ok, I seem to have come close to the reason for this change of Mozilla's behavior. I have just compiled Thunderbird 0.6 after substituting two files: gfx/src/gtk/nsFontMetricsXft.h: replaced with revision 1.11 gfx/src/gtk/nsFontMetricsXft.cpp: replaced with revision 1.41 (this one required some additional tuning to get it to compile, e.g. because of the apparent changes of method signatures in nsIDeviceContext) And the problem disappeared! Could someone _please_ take it from here? (And by "someone" I mean "someone who really knows what's going on in this code" -- hey, I'm but an intruder here who's just had his first go at any Mozilla hacking whatsoever and only scratched the surface of it :)

Same thing here, with Thunderbird 0.6, freetype 2.1.4, and fontconfig 2.2.1. M

Same bug in mozilla-1.7-0.2.0.i386.rpm from mozilla.org (Fedora Core 2, freetype-2.1.7, fontconfig-2.2.1)

I'm not sure what's changed there. However, I'm pretty sure that we don't read some of the settings out of the xft settings properly.

I would think this bug would be a blocker for firefox 1.0. It is very relevant to every day usage. I'm running Linux from scratch and here are my package versions: fontconfig-2.2.3 freetype 2.1.9 xft-2.1.2.2

I think this bug was introduced when fixing the bug 197037. The attached patch fixes the inconsistent antialiasing problem by passing the font size to fontconfig in points (as it was done before the fix to bug 197037) instead of pixels (as it is done now). Unfortunately, this "fix" additionally brings back the problems mentioned in bug 197037, so it isn't really a "fix", but a demonstration of the point. Don't really know what an actual fix should look like... PS. The patch was created against and tested with the official Firefox 1.0.2 tarball.

Well, guess what, in addition to "size", there's another property available when matching font patterns in fonts.conf, namely "pixelsize". It looks like you can use this one to get the expected behavior from different kinds of applications, including those based on the current Mozilla tree. The only peeve is that, in your /etc/fonts/fonts.conf, you're forced to select fonts that you don't want antialiased based on pixel size, and not by point size. My first impulse was to fill myself with shame and propose to switch this bug to RESOLVED/INVALID. But then again, it still does feel a bit odd that when you have a fancy to use point sizes in your /etc/fonts/fonts.conf all applications listen to you, but Mozilla does not....

I have reverted patch from bug bug 197037, and it does fix the problem. I think mozilla should pass fonts to fontconfig in points, because every other application on the gnome desktop is passed with points as far as I know.

Does this bug still occur in a recent trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

No response from reporter - Incomplete