Closed
Bug 236739
Opened 21 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•21 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
•