No subpixel smoothing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Invalid
|
Medium
|
|||
firefox-3.5 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Jaunty |
Invalid
|
Undecided
|
Unassigned | ||
fontconfig (Ubuntu) |
Fix Released
|
Medium
|
Alexander Sack | ||
Jaunty |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
Binary package hint: firefox-3.1
Firefox 3.1b2 has no subpixel smoothing on Jaunty.
Related branches
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #1 |
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #2 |
Thank you for the screenshot. Was this taken at a smaller Zoom size? Are the
differences as obvious on https:/
The difference I see here is that the hinting is different in the "after"
shot. The hinting looks stronger (and it's not very good).
Also, the text in <stronger> is almost indistinguishable from the other text.
I think that may be due to the hinting differences.
Can you provide the output of the following commands, please?
xrdb -query | grep Xft
FC_DEBUG=1 fc-match sans-serif:
Also, do you see similar difference between the text produced with the
following two commands?
pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=cairo
pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #3 |
Created attachment 341853
screenshot
The screenshots i combined above were not mine. I got them from another user.
I'll ask him.
Here is another screenshot of my own desktop, also showing this issue.
I do see a difference between the two pango-view commands.
$ xrdb -query | grep Xft
Xft.antialias: 1
Xft.dpi: 85
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.rgba: rgb
$ FC_DEBUG=1 fc-match sans-serif:
FC_DEBUG=1
FC_DEBUG=1
Match Pattern has 14 elts (size 16)
family: "DejaVu Sans"(w) "Bitstream Vera Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "AR PL UMing HK"(w) "AR PL UMing CN"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w) "Norasi"(w) "Saysettha Unicode"(w) "JG Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax Berbère"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "SimSun"(w) "PMingLiu"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "MS ゴシック"(w) "ZYSong18030"(w) "TSCu_Paranar"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "Waree"(w) "Loma"(w) "Garuda"(w) "Umpush"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) "Code2001"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) "Bitstream-
slant: 0(i)(s)
weight: 200(i)(s)
width: 100(i)(s)
pixelsize: 13.3(f)(s)
hintstyle: 3(i)(s)
hinting: FcTrue(s)
autohint: FcFalse(s)
lang: "en-US"(s)
decorative: FcFalse(s)
Best score 0 0 1e+99 100 0 0 0 0 0 0 0 0 0 0 0 2.14734e+11Pattern has 20 elts (size 20)
family: "DejaVu Sans"(w)
familylang: "en"(w)
style: "Bold"(w)
stylelang: "en"(w)
fullname: "DejaVu Sans Bold"(w)
slant: 0(i)(w)
weight: 200(i)(w)
width: 100(i)(w)
foundry: "unknown"(w)
file: "/usr/share/
index: 0(i)(w)
outline: FcTrue(w)
scalable: FcTrue(w)
charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
0001: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0002: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 008873ff
0003: ffffffff ffffffff f18effff 7c300007 ffffd7f0 ...
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #4 |
Created attachment 341855
pango view
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #5 |
(In reply to comment #3)
> Created an attachment (id=341853) [details]
> screenshot
>
> The screenshots i combined above were not mine. I got them from another user.
Let me know if there is another bug report somewhere else that I should follow.
> Here is another screenshot of my own desktop, also showing this issue.
>
> I do see a difference between the two pango-view commands.
Your screenshot shows a change that is a little different to attachment
341831, but probably related. In your screenshot the difference is that rgb
antialiasing is used on the left (before and pangocairo, I assume), while
grayscale antialiasing is used on the right (after and pangoxft, I assume).
I suspect an issue with the interaction of fontconfig and X resource settings
here.
> Xft.rgba: rgb
So X resources request rgb antialiasing.
The original Xft behavior was that this request would be applied to the
pattern and passed to FcConfigSubstitute to let fontconfig settings have the
final say. This gives fontconfig the chance to modify this setting based on
the requested value and information about the font.
At one stage cairo didn't have any support for fontconfig. Some support has
been added (some time ago), but IMO cairo does not yet have this right. There
is some logic, that sometimes prefers X resource (surface) settings and
sometimes prefers fontconfig settings. I haven't found anyone who knows the
reasoning for this logic.
https:/
https:/
Some changes in bug 385263 restored the Xft behavior.
> $ FC_DEBUG=1 fc-match sans-serif:
There is no rgba property in the pattern here, so fontconfig is not adding its
own rgba property, but this didn't test whether the property was removed.
Your screenshots make me suspect that fontconfig settings are removing the
rgba property. This can be tested using
FC_DEBUG=1 \
pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft |
grep rgb
If you don't see
rgba: 1(i)(s)
in the output then something has removed this property. If that is the case,
can you find out, please, what setting has removed this property, and why?
If there is a good reason for a fontconfig setting that unconditionally
removes the rgba property, then we can consider reapplying the X resource properties if fontconfig has removed any, but I'd like to understand the reason for the setting first.
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #6 |
> FC_DEBUG=1 \
> pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft |
> grep rgb
>
> If you don't see
> rgba: 1(i)(s)
I do see "rgba: 1(i)(s)"
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #7 |
Created attachment 341863
Font rendering options
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #8 |
(In reply to comment #6)
> > FC_DEBUG=1 \
> > pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft |
> > grep rgb
> >
> > If you don't see
> > rgba: 1(i)(s)
>
> I do see "rgba: 1(i)(s)"
Sorry, that only checked the FcConfigSubstitute pass with FcMatchPattern
(target="pattern"). There is another pass with FcMatchFont (target="font"),
which is actually the one called after X resource settings are applied.
Both passes can be debugged using
FC_DEBUG=4 \
pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft
but the output is very verbose, containing patterns for many fonts even
though only one of them gets used.
Try putting the output through "| grep -B 4 'Edit rgba'",
Or searching for rgba and noting anything interesting.
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #9 |
Or much simpler,
fc-match -v sans-serif:
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #10 |
Created attachment 341895
log file
> fc-match -v sans-serif:
rgba: 5(i)(w)
> FC_DEBUG=4 \
> pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft
full log attached
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #11 |
(In reply to comment #10)
> Created an attachment (id=341895) [details]
> log file
>
> > fc-match -v sans-serif:
>
> rgba: 5(i)(w)
Thank you. The problem is the same as reported here:
https:/
"Add Subst match
edit
Edit rgba Assign none;"
A fontconfig setting is unconditionally disabling rgba antialiasing.
i.e. setting subpixel geometry to "none".
Do you have a link or file /etc/fonts/
This is not normally installed in an active directory but usually only exists
in /etc/fonts/
If you don't have that file try
grep -l rgba /etc/fonts/* /etc/fonts/conf.d/* ~/.fonts.conf
to find the file that has this setting.
If the file is in /etc/:
Do you know if this file was installed by default?
What distibution are you using?
What fontconfig version? "pkg-config fontconfig --modversion" if you have
dev packages installed, or better the distribution's fontconfig package
version number.
If it is in ~/.fonts.conf
Have you run a KDE session and set fonts from there?
In Mozilla Bugzilla #458612, Fta+bugzilla (fta+bugzilla) wrote : | #12 |
This is on Ubuntu Intrepid (the upcoming 8.10), with fontconfig 2.6.0.
No user specified font config, no KDE.
$ grep -l rgba /etc/fonts/* /etc/fonts/conf.d/* ~/.fonts.conf | xargs ls -l
lrwxrwxrwx 1 root root 42 2008-09-20 16:35 /etc/fonts/
-rw-r--r-- 1 root root 257 2006-09-15 19:21 /etc/fonts/
-rw-r--r-- 1 root root 256 2006-09-15 19:21 /etc/fonts/
hm, this is strange.
$ cat /etc/fonts/
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- conf.d/
<fontconfig>
<!-- Enable sub-pixel rendering -->
<match target="font">
<edit name="rgba" mode="assign"
</match>
</fontconfig>
$ cat /etc/fonts/
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- conf.d/
<fontconfig>
<!-- Enable sub-pixel rendering -->
<match target="font">
<edit name="rgba" mode="assign"
</match>
</fontconfig>
$ cat /etc/fonts/
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!-- Enable sub-pixel rendering -->
<match target="font">
<edit name="rgba" mode="assign"
</match>
</fontconfig>
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #13 |
(In reply to comment #12)
> This is on Ubuntu Intrepid (the upcoming 8.10), with fontconfig 2.6.0.
> No user specified font config, no KDE.
>
> $ grep -l rgba /etc/fonts/* /etc/fonts/conf.d/* ~/.fonts.conf | xargs ls -l
> lrwxrwxrwx 1 root root 42 2008-09-20 16:35
> /etc/fonts/
> /etc/fonts/
> -rw-r--r-- 1 root root 257 2006-09-15 19:21 /etc/fonts/
> -rw-r--r-- 1 root root 256 2006-09-15 19:21 /etc/fonts/
>
> hm, this is strange.
Yes, I wonder where no-sub-pixel.conf and sub-pixel.conf come from. "dpkg -S
/etc/fonts/
normally read by fontconfig anyway
"every file within that directory starting with an ASCII digit (U+0030 -
U+0039) and ending with the string ‘‘.conf’’ will be processed in
sorted order"
"man fonts-conf" doesn't explicity say what happens with other files, but I
guess they are not read.
> $ cat /etc/fonts/
> <?xml version="1.0"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
> <!-- Enable sub-pixel rendering -->
> <match target="font">
> <edit name="rgba" mode="assign"
> </match>
> </fontconfig>
It seems that this may have been added in fontconfig (2.6.0-1ubuntu1).
http://
- modified conf.d/Makefile.am and conf.d/Makefile.in so that
10-
10-
settings for all Ubuntu flavors. 10-hinting-
10-
This gives the impression that the maintainers want everything to look the
same unless this file is changed through some configuration mechanism. I'm
not familiar with Debian so I don't know what this configuration mechanism is.
The postinst file from the package includes these lines:
db_get fontconfig/
subpixel_
subpixel=
no_subpixel=
if [ -h $CONFDIR/$subpixel ]; then
rm $CONFDIR/$subpixel
fi
if [ -h $CONFDIR/
rm $CONFDIR/
fi
case "$subpixel_
"Automatic")
;;
"Always")
ln -s $CONFAVAIL/
;;
"Never")
ln -s $CONFAVAIL/
;;
esac
This is strange because it looks like it would remove the links added by the Makefile, and then possibly add them again according to some configuration.
So I assume there is a "fontconfig/
Ubuntu-specific configuration system somewhere that currently has the value
"Never", and I assume changing that to "Automatic" would resolve the rgba problem (possibly after rerunning the postinst script with another install).
In Mozilla Bugzilla #458612, Ilja Sekler (ilja-sekler-) wrote : | #14 |
For the case my observations might be somehow useful: I build Firefox and Thunderbird with --enable-
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit mode="assign" name="rgba">
<const>
</edit>
</match>
<match target="font">
<edit mode="assign" name="hinting">
<bool>
</edit>
</match>
<match target="font">
<edit mode="assign" name="hintstyle">
<const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="antialias">
<bool>
</edit>
</match>
</fontconfig>
At the font size of 13px and above the font rendering is exactly the same as before the regression, all the anomalies begin below 13px:
1) "font-family: sans-serif;" gets drawn with the default font (DejaVu Serif). It happens only if the generic name is used (like at <http://
2) the hinting settings are ignored, but only for monospace (DejaVu Sans Mono).
GNOME font antialiasing settings seem to be ignored as well, I didn't look closer at it because a proper ~/.fonts.conf is required anyway due to gnome-terminal ignoring these settings too and relying only on fontconfig.
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #15 |
(In reply to comment #14)
> For the case my observations might be somehow useful: I build Firefox and
> Thunderbird with --enable-
> 1.6.0-0ubuntu2; fontconfig: 2.5.0-2ubuntu3). My ~/.fonts.conf:
> At the font size of 13px and above the font rendering is exactly the same as
> before the regression, all the anomalies begin below 13px:
>
> 1) "font-family: sans-serif;" gets drawn with the default font (DejaVu Serif).
> It happens only if the generic name is used (like at
> <http://
Are you saying that at 13px and above the expected font (DejaVu Sans?) is used?
In about:config, if you search for font.name.
Unfortunately, Edit->Preferenc
But then I didn't expect bug 385263 to change the selected font. I'd be interested to hear exactly how things changed here. What font did you expect and what font did you get before the change?
> 2) the hinting settings are ignored, but only for monospace (DejaVu Sans Mono).
That sounds the same as the effect of /etc/fonts/
<!-- Use legacy LCD filter on smaller Monospace fonts -->
<match target="font">
<test name="family">
<
<
</test>
<test name="pixelsize" compare="less_eq">
<
</test>
<edit name="lcd_filter" mode="assign">
<
</edit>
<edit name="hintstyle" mode="assign">
<
</edit>
</match>
I don't know why Ubuntu have chosen to put this after 50-user.conf, and override anything that the user has set.
Does the fontconfig-config package for Ubuntu 8.04 have something similar?
In Mozilla Bugzilla #458612, Ilja Sekler (ilja-sekler-) wrote : | #16 |
(In reply to comment #15)
> Are you saying that at 13px and above the expected font (DejaVu Sans?) is used?
Yes, exactly, but now, after suspending the system to RAM and resuming, I am deeply embarrassed not being able to reproduce it either with a new profile or with the old one... Especially I can't explain why I haven't make screenshots :-(
> In about:config, if you search for font.name.
> their defaults?
Now: Yes, due to the fresh profile. In the old one, they were partially set to the expected values (like sans-serif => DejaVu Sans)
> What font did you expect
> and what font did you get before the change?
Expected: DejaVu Sans, because:
fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"
I got DejaVu Serif (my visual impression), but now I can only wait and hope to be able to reproduce the strange glitch sometimes again.
>> 2) the hinting settings are ignored, but only for monospace (DejaVu Sans Mono).
>
> That sounds the same as the effect of
> /etc/fonts/
> fontconfig-
>
> [...]
>
> Does the fontconfig-config package for Ubuntu 8.04 have something similar?
This was a perfect hit, thank you very much. fontconfig-config 2.5.0-2ubuntu3 provides the same file. Deleting the symlink from /etc/fonts/conf.d heals the monospace issue immediately.
In Mozilla Bugzilla #458612, Roc-ocallahan (roc-ocallahan) wrote : | #17 |
Can we close this bug now?
In Mozilla Bugzilla #458612, Ilja Sekler (ilja-sekler-) wrote : | #18 |
(In reply to comment #17)
> Can we close this bug now?
Is it a part of this bug that fontconfig overrules GNOME font settings now, at least on Ubuntu Hardy Heron? If yes, and this change was not intentional, this bug should remain open IMHO.
In Mozilla Bugzilla #458612, Klaus-malorny (klaus-malorny) wrote : | #19 |
While looking up the status of my bug 458032, I discovered this one. Maybe it is the same issue.
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #20 |
*** Bug 458032 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #21 |
(In reply to comment #18)
> Is it a part of this bug that fontconfig overrules GNOME font settings now, at
> least on Ubuntu Hardy Heron?
I think that is what this bug is about. (And I don't think this has anything
to do with whether system or tree cairo is used.)
fontconfig, the Xft X server resource database properties, and gtk-settings
all provide mechanisms for configuring the rendering of fonts. (Last I
checked the GNOME dialog affects X resource and gtk-settings settings, but not
fontconfig settings, and I think that is the right behavior.)
The issue is who gets the last say when conflicting settings are present.
> If yes, and this change was not intentional, this bug should remain open
> IMHO.
This change was intentional. It reverted an unintentional change that
was part of the cause of bug 400265.
The behavior now gives fontconfig the final say. The is the original
intended behavior of Xft and fontconfig, and I believe this is the preferred
behavior.
fontconfig is more flexible than the GNOME font rendering settings in how it
sets properties, and the two can work together well.
fontconfig can consider the preferred default properties for the screen and
the details of the particular font and choose the best properties based on
that information. For example different hintstyles may be better for fonts
with different hinting mechanisms or qualities.
The GNOME font rendering dialog does not provide an option that is equivalent
to "use the system default" or "prefer fontconfig settings", so giving the
GNOME font rendering dialog the last say would be always ignoring fontconfig
settings.
The symptoms reported seem to be from the files 10-antialias.conf,
10-hinting.conf, 10-hinting-
53-monospace-
that can cause similar problems, but AFAIK they are not activated by default
anywhere.) Upstream fontconfig and Debian don't seem to activate any of these
files by default. It seems that Ubuntu maintainers have chosen to add these
files.
Looking at the config and postinst files in
fontconfig-
corresponding debconf settings but some do not (which is probably another
bug).
For example, it seems that the default value of "fontconfig/
is "Never", and so subpixel rendering is "Never" enabled.
IMO, if Ubuntu maintainers wish to keep these files, the best fix for this would be to change "Never" to "DefaultOff" or similar, and change 10-no-sub-
<match target="font">
<edit name="rgba" mode="assign"
</match>
to
<match target="font">
<test name="rgba" qual="all"
<edit name="rgba" mode="assign"
</match>
Similarly, 10-hinting-
<match target="font">
<edit name="hintstyle" mode="assign"
</match>
to something like
<match target="font">
<test name="hintstyle" qual="all"
<edit name="hintstyle" mode="assign"
</match>
...
In Mozilla Bugzilla #458612, kmc (kmcreg) wrote : | #22 |
(In reply to comment #21)
Thanks Karl, I've been searching for decades for a solution to this strange behavior. I'll test the modifications that you suggest and give the feed-back ASAP.
In Mozilla Bugzilla #458612, kmc (kmcreg) wrote : | #23 |
I've tried modifying 10-hinting-
if [ -h $CONFDIR/
to
if [ -h $CONFDIR/
but no improvements is seen. Anything wrong in my manipulations?
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #24 |
(In reply to comment #23)
> I've tried modifying 10-hinting-
Changes to files in /etc/fonts/conf.d should be enough to see changes, if it is Ubuntu's system settings causing the undesired effect.
Your own ~/.fonts.conf may also be involved.
> and in my /var/lib/
>
> if [ -h $CONFDIR/
> then
> subpixel_
> to
>
> if [ -h $CONFDIR/
> then
> subpixel_
There is currently no DefaultOff setting. I'm proposing that as an alternative to "Never", but that will require more changes than this.
If you remove (or move to another directory) 10-antialias.conf, 10-hinting-
pango-view -t "Mozilla Foundation" --font="sans-serif 13px" \
--backend=xft
If not, then best file another bug.
Can you indicate, please, what behavior you are seeing and what behavior you would like to see, probably best with a screen shot?
Does the following command display in the way that you like?:
pango-view -t "Mozilla Foundation" --font="sans-serif 13px" \
--backend=cairo
What screen settings do you have? i.e. what is the output from this?:
xrdb -query | grep Xft
In Mozilla Bugzilla #458612, kmc (kmcreg) wrote : | #25 |
Created attachment 351405
Text rendering by xft and cairo
It's indeed hard to find difference between these two test cases using "pango-view".
In Mozilla Bugzilla #458612, kmc (kmcreg) wrote : | #26 |
Created attachment 351406
Problem and desired results
Above, the actual nightly rendering, we see even the 'mozilla.org' is badly rendered.
Below, the version build for ubuntu with enable-
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #27 |
Comment on attachment 351405
Text rendering by xft and cairo
(In reply to comment #25)
> It's indeed hard to find difference between these two test cases using
> "pango-view".
Thanks, this indicates that the issue is not this bug.
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #28 |
Comment on attachment 351406
Problem and desired results
(In reply to comment #26)
> Created an attachment (id=351406) [details]
> Problem and desired results
I think this is probably bug 462798.
William Grant (wgrant) wrote : | #29 |
Binary package hint: firefox-3.1
Firefox 3.1b2 has no subpixel smoothing on Jaunty.
In Mozilla Bugzilla #458612, Roc-ocallahan (roc-ocallahan) wrote : | #30 |
Karl has explained that giving fontconfig final say is intentional and the preferred behaviour. So there's no reason to reevaluate blocking status, and in fact it sounds like we should close this as INVALID.
In Mozilla Bugzilla #458612, Klaus-malorny (klaus-malorny) wrote : | #31 |
Hmm, to me as an ignorant of the whole font rendering and without any understanding what is being written above: This means that this is a bug of Gnome/Ubuntu rather than of Mozilla? Is the problem known to these people?
In Mozilla Bugzilla #458612, Karlt (karlt) wrote : | #32 |
(In reply to comment #30)
> This means that this is a bug of Gnome/Ubuntu rather than of Mozilla?
I believe the bug is in Ubuntu fontconfig-config package (or arguably in upstream fontconfig).
> Is the problem known to these people?
The problem was diagnosed 2008-04-02:
"my gutsy boxes dont' have the "10-*" symlinks in /etc/fonts/conf.d/ .
Removing these symlinks seems to make gnome-terminal respect the settings
in the appearance -> font application, which I would assume is the desired
behavior? Does anyone know why fontconfig now installs these symlinks?"
https:/
Marking INVALID.
Please do not reopen without considering the following:
1) Please first check that the bug that you are seeing is not bug 462798
or bug 404637.
If Mozilla is rendering the same as
pango-view -t "Mozilla Foundation" --font="sans-serif 13px" \
--backend=xft
but differently from
pango-view -t "Mozilla Foundation" --font="sans-serif 13px" \
-
then the symptoms you are seeing are most likely this bug.
2) Please provide a reason why the system fontconfig settings (10-* symlinks)
should be present, and override settings already in the FcPattern, but be
ignored by applications.
https:/
https:/
3) It seems that nobody really understands why cairo's behavior is different
from Xft's, but cairo's behavior is convoluted enough that people are
scared of changing it:
https:/
Any reasons for cairo's current behavior may be helpful in making a
different decision here.
Changed in firefox: | |
status: | Unknown → Invalid |
Fabien Tassin (fta) wrote : | #33 |
As mentioned in Bugzilla, this is not a problem in firefox. It is caused by an Ubuntu specific rule in system fontconfig. Marking invalid for firefox-3.1 and confirmed in fontconfig.
Changed in firefox-3.1: | |
status: | New → Invalid |
Changed in fontconfig: | |
importance: | Undecided → Medium |
milestone: | none → jaunty-alpha-3 |
status: | New → Confirmed |
Alexander Sack (asac) wrote : | #34 |
I think scott did the last tweakage on sub pixel rendering during gutsy or hardy cycle ... assigning to him to clarify on how to move forward.
Mozilla bug contains some evaluations:
https:/
https:/
Changed in fontconfig: | |
assignee: | nobody → scott |
milestone: | jaunty-alpha-3 → ubuntu-9.04-beta |
status: | Confirmed → Triaged |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #35 |
Insufficient information here for me to help. What is it that you want to know?
Changed in fontconfig: | |
assignee: | scott → nobody |
blackdog (ritchie) wrote : | #36 |
i can confirm this, there's no subpixel smoothing on jaunty firefox as of 12/02/09.
Alexander Sack (asac) wrote : | #37 |
Scott, from the upsream comment i referenced in my call for help:
"""
The behavior now gives fontconfig the final say. The is the original
intended behavior of Xft and fontconfig, and I believe this is the preferred
behavior.
fontconfig is more flexible than the GNOME font rendering settings in how it
sets properties, and the two can work together well.
fontconfig can consider the preferred default properties for the screen and
the details of the particular font and choose the best properties based on
that information. For example different hintstyles may be better for fonts
with different hinting mechanisms or qualities.
The GNOME font rendering dialog does not provide an option that is equivalent
to "use the system default" or "prefer fontconfig settings", so giving the
GNOME font rendering dialog the last say would be always ignoring fontconfig
settings.
The symptoms reported seem to be from the files 10-antialias.conf,
10-hinting.conf, 10-hinting-
53-monospace-
that can cause similar problems, but AFAIK they are not activated by default
anywhere.) Upstream fontconfig and Debian don't seem to activate any of these
files by default. It seems that Ubuntu maintainers have chosen to add these
files.
Looking at the config and postinst files in
fontconfig-
corresponding debconf settings but some do not (which is probably another
bug).
For example, it seems that the default value of "fontconfig/
is "Never", and so subpixel rendering is "Never" enabled.
IMO, if Ubuntu maintainers wish to keep these files, the best fix for this
would be to change "Never" to "DefaultOff" or similar, and change
10-no-sub-
<match target="font">
<edit name="rgba" mode="assign"
</match>
to
<match target="font">
<test name="rgba" qual="all"
<edit name="rgba" mode="assign"
</match>
Similarly, 10-hinting-
<match target="font">
<edit name="hintstyle" mode="assign"
</match>
to something like
<match target="font">
<test name="hintstyle" qual="all"
<edit name="hintstyle" mode="assign"
</match>
These settings would of course never have any effect on applications running on
a GNOME desktop though, as the GNOME font rendering settings don't have an
"unset" or "unknown" value, but always set the properties to some value.
"""
Alexander Sack (asac) wrote : | #38 |
Scott, please read https:/
Alexander Sack (asac) wrote : | #39 |
and what would be required to go back to upstream defaults.
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 305394] Re: No subpixel smoothing | #40 |
On Fri, 2009-02-13 at 20:00 +0000, Alexander Sack wrote:
> Scott, please read
> https:/
> ... the main question I have is why we did the changes to fontconfig
> that upstream wonders about in the comment i posted here for your
> convenience.
>
I don't know much about those settings, I've always thought fontconfig
was wrong in this regard and should just honour the GNOME settings.
Scott
--
Scott James Remnant
<email address hidden>
Alexander Sack (asac) wrote : | #41 |
I have made a rather aggressive package and uploaded that to ~mozillateam PPA. Please test and report back (especially where you see regressions)
Eric Appleman (erappleman) wrote : | #42 |
As we discussed on IRC, the patched fontconfig creates far more problems than it solves.
Yes, fonts in Firefox 3.1 and Firefox 3.2 do look marginally better and have antialiasing, but it comes at the expense of the system's overall subpixel rendering appearance.
Martin Pitt (pitti) wrote : | #43 |
Tentatively assigning to Alexander, you seem to work on this. If not, please unassign, then we need to find some other assignee. Milestone blockers need to have an assignee.
Changed in fontconfig: | |
assignee: | nobody → asac |
Launchpad Janitor (janitor) wrote : | #44 |
This bug was fixed in the package fontconfig - 2.6.0-1ubuntu8
---------------
fontconfig (2.6.0-1ubuntu8) jaunty; urgency=low
* debian/
we remove autohint.
unhinted.
we are polite and use rm_conffile for files that exist but are not symbolic
links; see LP: #332992 and LP: #305394
* remove debian/
files shipped by language-selector package.
-- Alexander Sack <email address hidden> Mon, 16 Mar 2009 21:05:38 +0100
Changed in fontconfig: | |
status: | Triaged → Fix Released |
Götz Christ (g-christ) wrote : | #45 |
- fontconfig_firefox.png Edit (49.2 KiB, image/png)
I have still this bug in Kubuntu Jaunty with fontconfig 2.6.0-1ubuntu9. Downgrading to fontconfig and fontconfig-config 2.6.0-1ubuntu5 fixes this bug. I could not download 2.6.0-1ubuntu6, but in 2.6.0-1ubuntu7 this bug appears again.
A will attach a screenshot showing the difference between the two version using Firefox 3.
Timo Aaltonen (tjaalton) wrote : | #46 |
Reopening, because the changes enabled bitmap fonts which broke some pages for 3.0 and possibly other apps too.
Changed in fontconfig (Ubuntu Jaunty): | |
status: | Fix Released → Triaged |
Michael Marley (mamarley) wrote : | #47 |
Yes, it did. On my system, it seemed to break a few fonts in both Firefox 3.1 and Konqueror.
Bogdan Gribincea (bogdan-gribincea) wrote : | #48 |
On my system one of the broken fonts seems to be Helvetica in Firefox 3.1. Arial and most other sans-serif fonts seem to work fine..
Michael Marley (mamarley) wrote : | #49 |
This sounds about right for me. I looked at the web pages which cause the problem, and they are using Helvetica.
Alexander Sack (asac) wrote : | #50 |
I removed a lot of cruft in the upload series i made. no-bitmaps seems an invalid victim of this effort.
so to workaround:
a) use good fonts ... you can achieve that by disallowing firefox to use the websites fonts (e.g. in preferences dialog)
or
b) sudo ln -s /etc/conf.
we will reestablish b) in the next upload.
not really sure if it was right to reopen this bug. but well, lets track this regression here now.
Alexander Sack (asac) wrote : | #51 |
b) was a typo. what we lack is:
12:48 < tjaalton> asac: just adding the link to 70-no-bitmaps.conf seems to be enough
next upload will fix that
Changed in fontconfig (Ubuntu Jaunty): | |
status: | Triaged → Fix Committed |
Launchpad Janitor (janitor) wrote : | #52 |
This bug was fixed in the package fontconfig - 2.6.0-1ubuntu10
---------------
fontconfig (2.6.0-1ubuntu10) jaunty; urgency=low
* debian/
default; we add it to the CONF_LINKS in conf.d/
fix regressions reported (LP: #305394, #344629)
* debian/
"drop debconf transition" to ensure that it doesn't get removed
automatically (LP: #305394, #344629)
* debian/
introduced FC_ANY_METRICS - this change never made it upstream and
firefox doesnt use it anymore.
-- Alexander Sack <email address hidden> Wed, 18 Mar 2009 18:37:18 +0100
Changed in fontconfig: | |
status: | Fix Committed → Fix Released |
NikhilNK (nikhil-katkoria) wrote : | #53 |
This problem still exists on Jaunty. Here are the details. However if I start FF3.5 or TB3 with gksudo (as root) subpixel smoothing works like a charm.
Display settings:
using "Subpixel smoothing (LCDs)"
Hinting : slight
Subpixel order : RGB
Linux hostname 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
nikhilnk@
fontconfig:
Installed: 2.6.0-1ubuntu12
Candidate: 2.6.0-1ubuntu12
Version table:
*** 2.6.0-1ubuntu12 0
500 http://
100 /var/lib/
nikhilnk@
firefox-3.5:
Installed: 3.5~b4~
Candidate: 3.5~b4~
Version table:
*** 3.5~b4~
500 http://
100 /var/lib/
thanks
Nikhil
NikhilNK (nikhil-katkoria) wrote : | #54 |
Got it fixed after removing below folders:
.fontconfig
.fonts
and file
.fonts.conf
for some reason, my font cache was cribbing about obsolete cache so tried this. Now it's working.
As of now I don't those folders again created, so some locally installed fonts are missing. But that's fine.
thanks
Nikhil
Alexander Sack (asac) wrote : | #55 |
> However if I start FF3.5 or TB3 with gksudo
oh. please dont do that. besides from general security hazards, doing this calls for troubles and usually does not help (except for cases where you already ran them as root before!!); running this as root creates files/caches as root in some system directories and that might also cause issues lateron, when the user cannot recreate/invalidate those.
> .fontconfig
usually font config caches work quite well, i would think that you had a manually setup (and most likely broken):
> .fonts.conf
affects: | firefox-3.1 (Ubuntu Jaunty) → firefox-3.5 (Ubuntu Jaunty) |
In Mozilla Bugzilla #458612, Sylvain Pasche (sylvain-pasche) wrote : | #56 |
*** Bug 490811 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #458612, Sylvain Pasche (sylvain-pasche) wrote : | #57 |
*** Bug 491128 has been marked as a duplicate of this bug. ***
Botond Szász (boteeka) wrote : | #58 |
This bug still isn't fixed (or was reintroduced) in Jaunty as of May 12, 2009 with Firefox from the original Ubuntu repositories. My install is up to date.
Changed in fontconfig (Ubuntu Jaunty): | |
status: | Fix Released → Confirmed |
In Mozilla Bugzilla #458612, Sylvain Pasche (sylvain-pasche) wrote : | #59 |
*** Bug 491626 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #458612, Sylvain Pasche (sylvain-pasche) wrote : | #60 |
*** Bug 497159 has been marked as a duplicate of this bug. ***
Tina Russell (tinarussell) wrote : | #61 |
I’m getting this problem with Firefox 3.5 on Karmic, fully updated.
kvsn (koen-asemic) wrote : | #62 |
I confirm this bug for Firefox 3.5.3 on Karmic.
foobear (foobear) wrote : | #63 |
We encoutered this bug just a few moments ago (Firefox 3.5.9 on karmic).
Before, we had played around with Gnome font settings and "systemsettings" (a KDE system settings application; we wanted to give KDE applications the GTK+ style).
Some time later we realized that Firefox and Thunderbird (3.0.4) did not use sub-pixel rendering, it seemed more like the normal font smoothing. Other GTK applications (like Nautilus) behaved like set in the font settings.
Changing the settings and back to sub-pixel did not help, neither did restarting X.
We removed ~/.fonts.conf and ~/.fontconfig and after logging out and back in everything was back to normal.
Hope this helps.
(You may not want remove ~/.fonts as you could have some custom fonts in there).
Changed in firefox: | |
importance: | Unknown → Medium |
Changed in fontconfig (Ubuntu): | |
milestone: | ubuntu-9.04-beta → none |
Changed in fontconfig (Ubuntu Jaunty): | |
milestone: | ubuntu-9.04-beta → none |
assignee: | Alexander Sack (asac) → nobody |
status: | Confirmed → Won't Fix |
In Mozilla Bugzilla #458612, Kbrosnan-mozilla (kbrosnan-mozilla) wrote : | #64 |
*** Bug 643884 has been marked as a duplicate of this bug. ***
Created attachment 341831
screenshot