243227 - font rendering inconsistent with certain system settings

Status: RESOLVED INCOMPLETE

(Core Graveyard :: GFX: Gtk, defect)

Description

[Wojciech Dzierzanowski]

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

Comment 1

[Wojciech Dzierzanowski]

Attachment: The relevant part of /etc/fonts/fonts.conf

Comment 2

[Wojciech Dzierzanowski]

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 :)

Comment 3

[Marciano Siniscalchi]

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

M

Comment 4

[Aleks Geraschenko]

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)

Comment 5

[Christopher Blizzard (:blizzard)]

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.

Comment 6

[nulldomain]

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

Comment 7

[Wojciech Dzierzanowski]

Attachment: a fix that breaks something else

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.

Comment 8

[Wojciech Dzierzanowski]

Attachment: a "better" entry in /etc/fonts/fonts.conf

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....

Comment 9

[nulldomain]

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.

Comment 10

[Mats Palmgren (inactive)]

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

Comment 11

[Kevin Brosnan]

No response from reporter - Incomplete