No subpixel smoothing

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

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) "ＭＳ ゴシック"(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 ...

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

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

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

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.

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

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

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

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

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