No subpixel smoothing

Bug #305394 reported by William Grant on 2008-12-05
72
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox-3.5 (Ubuntu)
Undecided
Unassigned
Jaunty
Undecided
Unassigned
fontconfig (Ubuntu)
Medium
Alexander Sack
Jaunty
Medium
Unassigned

Bug Description

Binary package hint: firefox-3.1

Firefox 3.1b2 has no subpixel smoothing on Jaunty.

Related branches

Created attachment 341831
screenshot

Thank you for the screenshot. Was this taken at a smaller Zoom size? Are the
differences as obvious on https://launchpad.net/ when Zoom is Reset?

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:bold:pixelsize=13.3

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

Download full text (7.1 KiB)

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:bold:pixelsize=13.3
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-Vera-Sans"(w)
        slant: 0(i)(s)
        weight: 200(i)(s)
        width: 100(i)(s)
        pixelsize: 13.3(f)(s)
        hintstyle: 3(i)(s)
        hinting: FcTrue(s)
        verticallayout: FcFalse(s)
        autohint: FcFalse(s)
        globaladvance: FcTrue(s)
        lang: "en-US"(s)
        fontversion: 2147483647(i)(s)
        embeddedbitmap: FcTrue(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)
        fullnamelang: "en"(w)
        slant: 0(i)(w)
        weight: 200(i)(w)
        width: 100(i)(w)
        foundry: "unknown"(w)
        file: "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf"(w)
        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 ...

Read more...

Created attachment 341855
pango view

(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://bugs.freedesktop.org/show_bug.cgi?id=11838
https://bugs.freedesktop.org/show_bug.cgi?id=10301#c30

Some changes in bug 385263 restored the Xft behavior.

> $ FC_DEBUG=1 fc-match sans-serif:bold:pixelsize=13.3

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.

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

Created attachment 341863
Font rendering options

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

Or much simpler,

  fc-match -v sans-serif:bold:pixelsize=13.3:rgba=1 | grep rgba

Created attachment 341895
log file

> fc-match -v sans-serif:bold:pixelsize=13.3:rgba=1 | grep rgba

rgba: 5(i)(w)

> FC_DEBUG=4 \
> pango-view -t "Blueprints" --font="sans-serif 13.3333px" --backend=xft

full log attached

(In reply to comment #10)
> Created an attachment (id=341895) [details]
> log file
>
> > fc-match -v sans-serif:bold:pixelsize=13.3:rgba=1 | grep rgba
>
> rgba: 5(i)(w)

Thank you. The problem is the same as reported here:

https://bugs.freedesktop.org/show_bug.cgi?id=17722

 "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/conf.d/10-no-sub-pixel.conf ?
This is not normally installed in an active directory but usually only exists
in /etc/fonts/conf.avail, in fontconfig versions that I've seen anyway.

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?

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/conf.d/10-no-sub-pixel.conf -> /etc/fonts/conf.avail/10-no-sub-pixel.conf
-rw-r--r-- 1 root root 257 2006-09-15 19:21 /etc/fonts/conf.d/no-sub-pixel.conf
-rw-r--r-- 1 root root 256 2006-09-15 19:21 /etc/fonts/conf.d/sub-pixel.conf

hm, this is strange.

$ cat /etc/fonts/conf.d/no-sub-pixel.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- conf.d/sub-pixel.conf -->
<fontconfig>
<!-- Enable sub-pixel rendering -->
  <match target="font">
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>
</fontconfig>

$ cat /etc/fonts/conf.d/sub-pixel.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- conf.d/sub-pixel.conf -->
<fontconfig>
<!-- Enable sub-pixel rendering -->
  <match target="font">
    <edit name="rgba" mode="assign"><const>rgb</const></edit>
  </match>
</fontconfig>

$ cat /etc/fonts/conf.d/10-no-sub-pixel.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!-- Enable sub-pixel rendering -->
  <match target="font">
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>
</fontconfig>

(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/conf.d/10-no-sub-pixel.conf ->
> /etc/fonts/conf.avail/10-no-sub-pixel.conf
> -rw-r--r-- 1 root root 257 2006-09-15 19:21 /etc/fonts/conf.d/no-sub-pixel.conf
> -rw-r--r-- 1 root root 256 2006-09-15 19:21 /etc/fonts/conf.d/sub-pixel.conf
>
> hm, this is strange.

Yes, I wonder where no-sub-pixel.conf and sub-pixel.conf come from. "dpkg -S
/etc/fonts/conf.d/sub-pixel.conf" may tell you, but I don't think these are
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/conf.d/10-no-sub-pixel.conf
> <?xml version="1.0"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
> <!-- Enable sub-pixel rendering -->
> <match target="font">
> <edit name="rgba" mode="assign"><const>none</const></edit>
> </match>
> </fontconfig>

It seems that this may have been added in fontconfig (2.6.0-1ubuntu1).
http://changelogs.ubuntu.com/changelogs/pool/main/f/fontconfig/fontconfig_2.6.0-1ubuntu4/changelog

    - modified conf.d/Makefile.am and conf.d/Makefile.in so that
      10-antialias.conf, 10-hinting.conf, 10-hinting-medium.conf and
      10-no-subpixel.conf get linked by default to have te same default
      settings for all Ubuntu flavors. 10-hinting-full.conf and
      10-hinting-slight.conf will go into conf.avail/ .

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_rendering
  subpixel_rendering="$RET"

  subpixel="10-sub-pixel-rgb.conf"
  no_subpixel="10-no-sub-pixel.conf"

  if [ -h $CONFDIR/$subpixel ]; then
          rm $CONFDIR/$subpixel
  fi

  if [ -h $CONFDIR/$no_subpixel ]; then
          rm $CONFDIR/$no_subpixel
  fi

  case "$subpixel_rendering" in
  "Automatic")
          ;;
  "Always")
          ln -s $CONFAVAIL/$subpixel $CONFDIR/$subpixel
          ;;
  "Never")
          ln -s $CONFAVAIL/$no_subpixel $CONFDIR/$no_subpixel
          ;;
  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/subpixel_rendering" setting in a
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).

For the case my observations might be somehow useful: I build Firefox and Thunderbird with --enable-system-cairo on Ubuntu 8.04 (libcairo2: 1.6.0-0ubuntu2; fontconfig: 2.5.0-2ubuntu3). My ~/.fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="antialias">
   <bool>true</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://hg.mozilla.org/mozilla-central/summary>).

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 reply to comment #14)
> For the case my observations might be somehow useful: I build Firefox and
> Thunderbird with --enable-system-cairo on Ubuntu 8.04 (libcairo2:
> 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://hg.mozilla.org/mozilla-central/summary>).

Are you saying that at 13px and above the expected font (DejaVu Sans?) is used?

In about:config, if you search for font.name.sans-serif, are all values at their defaults?

Unfortunately, Edit->Preferences->Content->"Default font" hides what is really happening. Use "Advanced" to get a better picture.

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/conf.d/53-monospace-lcd-filter.conf from fontconfig-config_2.6.0-1ubuntu4_all.deb.

<!-- Use legacy LCD filter on smaller Monospace fonts -->
  <match target="font">
    <test name="family">
      <string>DejaVu Sans Mono</string>
      <string>Bitstream Vera Sans Mono</string>
    </test>
    <test name="pixelsize" compare="less_eq">
      <double>12.0</double>
    </test>

    <edit name="lcd_filter" mode="assign">
      <const>lcdlegacy</const>
    </edit>
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </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 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.sans-serif, are all values at
> 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/conf.d/53-monospace-lcd-filter.conf from
> fontconfig-config_2.6.0-1ubuntu4_all.deb.
>
> [...]
>
> 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.

Can we close this bug now?

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

While looking up the status of my bug 458032, I discovered this one. Maybe it is the same issue.

*** Bug 458032 has been marked as a duplicate of this bug. ***

Download full text (3.3 KiB)

(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-medium.conf, 10-no-subpixel.conf, and
53-monospace-lcd-filter.conf in /etc/fonts/conf.d. (There are other files
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-config_2.6.0-1ubuntu4_all.deb, some of these files have
corresponding debconf settings but some do not (which is probably another
bug).

For example, it seems that the default value of "fontconfig/subpixel_rendering"
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-pixel.conf from

  <match target="font">
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>

to

  <match target="font">
     <test name="rgba" qual="all"><const>unknown</const></test>
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>

Similarly, 10-hinting-medium.conf could be changed from

  <match target="font">
    <edit name="hintstyle" mode="assign"><const>hintmedium</const></edit>
  </match>

to something like

  <match target="font">
    <test name="hintstyle" qual="all"><int>-1</int></test>
    <edit name="hintstyle" mode="assign"><const>hintmedium</const></edit>
  </match>
...

Read more...

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

I've tried modifying 10-hinting-medium.conf, 10-no-subpixel.conf as you said, and in my /var/lib/dpkg/info/fontconfig-config.config , I changed :

        if [ -h $CONFDIR/$no_subpixel_2_4 -o -h $CONFDIR/$no_subpixel_2_3 ]; then
        subpixel_rendering="Never"
to

        if [ -h $CONFDIR/$no_subpixel_2_4 -o -h $CONFDIR/$no_subpixel_2_3 ]; then
        subpixel_rendering="DefaultOff"

but no improvements is seen. Anything wrong in my manipulations?

(In reply to comment #23)
> I've tried modifying 10-hinting-medium.conf, 10-no-subpixel.conf as you said,

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/dpkg/info/fontconfig-config.config , I changed :
>
> if [ -h $CONFDIR/$no_subpixel_2_4 -o -h $CONFDIR/$no_subpixel_2_3 ];
> then
> subpixel_rendering="Never"
> to
>
> if [ -h $CONFDIR/$no_subpixel_2_4 -o -h $CONFDIR/$no_subpixel_2_3 ];
> then
> subpixel_rendering="DefaultOff"

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-medium.conf, 10-hinting.conf, 10-no-sub-pixel.conf, 11-lcd-filter-lcddefault.conf, and 53-monospace-lcd-filter.conf from /etc/fonts/conf.d, do you see a change in the text presented with the following command?

  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

Created attachment 351405
Text rendering by xft and cairo

It's indeed hard to find difference between these two test cases using "pango-view".

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

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.

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 :

Binary package hint: firefox-3.1

Firefox 3.1b2 has no subpixel smoothing on Jaunty.

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.

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 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://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/190848/comments/28

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" \
      --backend=cairo

   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://bugs.launchpad.net/fontconfig/+bug/190848
   https://bugs.freedesktop.org/show_bug.cgi?id=17722

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://bugs.freedesktop.org/show_bug.cgi?id=11838

   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 :

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 :

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://bugzilla.mozilla.org/show_bug.cgi?id=458612#c21
 https://bugzilla.mozilla.org/show_bug.cgi?id=458612#c31

Changed in fontconfig:
assignee: nobody → scott
milestone: jaunty-alpha-3 → ubuntu-9.04-beta
status: Confirmed → Triaged

Insufficient information here for me to help. What is it that you want to know?

Changed in fontconfig:
assignee: scott → nobody
blackdog (ritchie) wrote :

i can confirm this, there's no subpixel smoothing on jaunty firefox as of 12/02/09.

Alexander Sack (asac) wrote :

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-medium.conf, 10-no-subpixel.conf, and
53-monospace-lcd-filter.conf in /etc/fonts/conf.d. (There are other files
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-config_2.6.0-1ubuntu4_all.deb, some of these files have
corresponding debconf settings but some do not (which is probably another
bug).

For example, it seems that the default value of "fontconfig/subpixel_rendering"
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-pixel.conf from

  <match target="font">
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>

to

  <match target="font">
     <test name="rgba" qual="all"><const>unknown</const></test>
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>

Similarly, 10-hinting-medium.conf could be changed from

  <match target="font">
    <edit name="hintstyle" mode="assign"><const>hintmedium</const></edit>
  </match>

to something like

  <match target="font">
    <test name="hintstyle" qual="all"><int>-1</int></test>
    <edit name="hintstyle" mode="assign"><const>hintmedium</const></edit>
  </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 :

Scott, please read https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.1/+bug/305394/comments/5 ... 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.

Alexander Sack (asac) wrote :

and what would be required to go back to upstream defaults.

On Fri, 2009-02-13 at 20:00 +0000, Alexander Sack wrote:

> Scott, please read
> https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.1/+bug/305394/comments/5
> ... 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 :

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 :

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 :

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 :

This bug was fixed in the package fontconfig - 2.6.0-1ubuntu8

---------------
fontconfig (2.6.0-1ubuntu8) jaunty; urgency=low

  * debian/fontconfig-config.postinst: cleanup old conf.d links transition;
    we remove autohint.conf,no-bitmaps.conf,no-sub-pixel.conf,sub-pixel.conf,
    unhinted.conf,yes-bitmaps.conf which have been reported as left overs;
    we are polite and use rm_conffile for files that exist but are not symbolic
    links; see LP: #332992 and LP: #305394
  * remove debian/patches/02_ubuntu_fonts_conf.patch which got superseeded by
    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 :

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 :

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 :

Yes, it did. On my system, it seemed to break a few fonts in both Firefox 3.1 and Konqueror.

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 :

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 :

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.avail/70-subpixel* /etc/conf.d/

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 :

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 :

This bug was fixed in the package fontconfig - 2.6.0-1ubuntu10

---------------
fontconfig (2.6.0-1ubuntu10) jaunty; urgency=low

  * debian/patches/07_no_bitmaps.patch: enable 70-no-bitmaps.conf by
    default; we add it to the CONF_LINKS in conf.d/Makefile.am,in to
    fix regressions reported (LP: #305394, #344629)
  * debian/fontconfig-config.postinst: also exclude 70-no-bitmaps.conf from
    "drop debconf transition" to ensure that it doesn't get removed
    automatically (LP: #305394, #344629)
  * debian/patches/20_anymetric.patch: drop rules and code patch that
    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 :

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@hostname:~$ apt-cache policy fontconfig
fontconfig:
  Installed: 2.6.0-1ubuntu12
  Candidate: 2.6.0-1ubuntu12
  Version table:
 *** 2.6.0-1ubuntu12 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status
nikhilnk@hostname:~$ apt-cache policy firefox-3.5
firefox-3.5:
  Installed: 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1
  Candidate: 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1
  Version table:
 *** 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1 0
        500 http://archive.ubuntu.com jaunty/universe Packages
        100 /var/lib/dpkg/status

thanks
Nikhil

NikhilNK (nikhil-katkoria) wrote :

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 :

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

*** Bug 490811 has been marked as a duplicate of this bug. ***

*** Bug 491128 has been marked as a duplicate of this bug. ***

Botond Szász (boteeka) wrote :

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

*** Bug 491626 has been marked as a duplicate of this bug. ***

*** Bug 497159 has been marked as a duplicate of this bug. ***

Tina Russell (tinarussell) wrote :

I’m getting this problem with Firefox 3.5 on Karmic, fully updated.

kvsn (koen-asemic) wrote :

I confirm this bug for Firefox 3.5.3 on Karmic.

foobear (foobear) wrote :

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
Martin Pitt (pitti) on 2011-01-07
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

*** Bug 643884 has been marked as a duplicate of this bug. ***

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.