Closed
Bug 236739
Opened 20 years ago
Closed 20 years ago
Font smoothing/antialias does not work after fix of bug 197037
Categories
(Core Graveyard :: GFX: Gtk, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: cozmic.fi, Assigned: blizzard)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040307 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040307 (nightly build 20040306) I have just verified bug 197037 with the nightly build 20040306 and discovered that font smoothing does not work anymore. The font smoothing behaviour depends on settings in /etc/fonts/local.conf: I use <match target="font"> <test qual="all" name="size" compare="more"><int> 7</int></test> <test qual="all" name="size" compare="less"><int>12</int></test> <edit name="antialias" mode="assign"> <bool>false</bool></edit> </match> to disable antialiasing of fonts in this size range. I did not encounter any problems until now. Mozilla seems to ignore this and disables antialiasing of fonts completely. I have tried to change the ranges with no effect. However if I leave this out completely, Mozilla smoothes all fonts. And if I add a statement to antialias fonts in the range <8 and >11 after the statement above, Mozilla smoothes all fonts, too. So I assume that Mozilla follows the last <edit antialias> statement for all fonts regardless of size. Software versions: freetype - 2.1.7 fontconfig - 2.2.0 Reproducible: Always Steps to Reproduce: This may be related to the fix of bug 197037, but it may also be a bug in libfreetype or fontconfig.
Updated•20 years ago
|
Assignee: roland.mainz → blizzard
Component: GFX: Xlib → GFX: Gtk
QA Contact: timeless → ian
So I'm not alone with missing AA. Confirming, freshly built Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040310 doesn't anti-alias fonts despite being built with GTK2/Xft support enabled. In fact, I didn't change .mozconfig for ages, and build from one month ago works ok. Removing following statements from /etc/fonts/local.conf fixes the problem, just like in reporter's case: <match target="font"> <test qual="all" name="size" compare="less"> <int>9</int> </test> <edit name="antialias" mode="assign"><bool>false</bool></edit> </match>
Reporter | ||
Comment 2•20 years ago
|
||
Changed System from SuSE 8.1 to Gentoo 2004.1 and I'm using KDE 3.2.1 now. The font config is done in the home directory, using $HOME/.fonts.conf: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <dir>~/.fonts</dir> <match target="font" > <test compare="more" name="size" qual="any" > <double>8</double> </test> <test compare="less" name="size" qual="any" > <double>14</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> <match target="font" > <test compare="more" name="pixelsize" qual="any" > <double>11</double> </test> <test compare="less" name="pixelsize" qual="any" > <double>20</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> </fontconfig> ... and fonts are antialiased correctly in Mozilla 1.7RC1! I did not yet test what happens if I remove the pixelsize attributes.
Reporter | ||
Comment 3•20 years ago
|
||
... well I did test now and if I remove the 'pixelsize' part, ALL fonts are antialiased. So I assume, that font size is now set in pixels instead of points(?) and fontconfig/freetype separates the two size types strictly.
It sounds more like a bug in your fonts.conf if your fonts.conf specifies that fonts requested in point sizes should be antialiased and fonts requested in pixel sizes should not be. What distro ships a fonts.conf like that?
Comment 5•20 years ago
|
||
I confirm. Everything worked fine with Firefox 0.8, Thunderbird 0.6 and Mozilla 1.6 and every other gtk2 app. And stopped working with FF 0.9, Tb 0.7 and Mozilla 1.7. I use Fedora Core 2. I had to rewrite local.conf file changing "size" to "pixelsize" and ajusting numbers. fontconfig-2.2.1 freetype-2.1.7-4
Reporter | ||
Comment 6•20 years ago
|
||
@David: The font.conf is correct. Both entries specify a size range that should NOT be antialiased. So it looks like the cause for this problem is not Mozilla, but bad font configuration files that do not take care of pixel sized fonts. I'll set the status of this bug to INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•