458612 - (Ubuntu) system fontconfig settings override GNOME font rendering screen settings

Status: RESOLVED INVALID

(Core :: Graphics, defect, P3)

Description

[Fabien Tassin]

Using system cairo 1.7.6, there's a font regression in trunk.
I've cornered it between r19805 and r19808.

in-source cairo is 1.7.4-136-g5ea2555 (so ~1.7.6pre).

This seems related to bug 385263.
Attached a screenshot showing the regression.

Comment 1

[Fabien Tassin]

Attachment: screenshot

Comment 2

[Karl Tomlinson (:karlt)]

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

Comment 3

[Fabien Tassin]

Attachment: 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 fffffffb ffff7fff ffffffff
        0004: ffffffff ffffffff ffffffff ffffffff ffffff7f ffffffff ffffffff ffffffff
        0005: 3c0fffff fffe000f fe7fffff fffffffe 000006ff ffff0000 ffff00cf 001f07ff
        0006: 88201000 07fffffe 043fffff fe10ffff 012600ff 84208252 00205040 03ff0000
        0007: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff 073ff8ff
        000e: 00000000 80000000 00000000 00000000 fef02596 3bffecae 33ff3f5f 00000000
        0010: 00000000 00000000 00000000 00000000 00000000 ffffffff ffff003f 1fffffff
        0014: effffefe ffbfffff fff7f7ff ffffffff ffffffff 3fffffff ffffffff fffff7ff
        0015: ffff00ff 7fffffff fffdffff fff007ff 007ffc3f 0000ffff 40000000 00000002
        0016: 00000000 00000000 000000c0 007fc000 1fffffff 00000000 00000000 00000000
        001d: ffdfffff ffff7fcf efffffff 098007ff f8000020 ffffffff 000003f0 00000000
        001e: ffffffff ffffffff ffffffff ffffffff 8fffffff ffffffff ffffffff 03ffffff
        001f: 3f3fffff ffffffff aaff3f3f 3fffffff ffffffff ffdfffff efcfffdf 7fdcffff
        0020: ffffffff fffffcff ffffffff fff3fc0f 001f7fff 003fffff 18c30000 00000002
        0021: fffffbff ffffffff fff84bff ffffffff ffff001f ffffffff ffffffff ffffffff
        0022: ffffffff ffffffff ffffffff ffffffff ffffffff fffcffff ffc0ff7f ffffffff
        0023: f303ffff 000019f3 00000000 24380000 f8100080 00007fff 0000c000 00000028
        0024: 00000000 0000000c 00000000 000003ff 00000000 00000000 00000000 00000000
        0025: 00000000 00000000 00000000 00000000 ffffffff ffffffff ffffffff ffffffff
        0026: ffffffff ffffffff ffffffff ffffffff 1fffffff 0007ffff 00000000 00000000
        0027: fffff3de fffffeff 7f47afff fffffffe ff1fffff 7ffeffff 00000000 ffff0fc1
        0028: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
        0029: 00000cc0 00000000 00000003 00000000 00000018 00000000 003fc000 0c000800
        002a: 1ffff007 00008000 00000000 e0000000 ffffffff 07ffc001 00000000 06000000
        002b: 07ffffff 0000000f 00000000 00000000 00000000 00000000 00000000 00000000
        002c: 00000000 00000000 00000000 3afeffff 00000000 00000000 00000000 00000000
        002d: 00000000 ffff0000 ffffffff 0000803f 00000000 00000000 00000000 00000000
        002e: 01000000 00004000 00000000 00000000 00000000 00000000 00000000 00000000
        004d: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff ffffffff
        00a6: 00000000 00000000 003330f0 00000000 00000000 00000000 00000000 00000000
        00a7: 007c0000 ff0f03c0 0000cfc0 00000000 00000003 00000000 00000000 f8000000
        00f6: 00000000 00000000 00000000 00000000 00000000 00000000 00000020 00000000
        00fb: e0f8007f 5f7fffff fffcffdb ffffffff c03ffc03 00000000 06000000 f0000300
        00fe: 00000000 0000000f 00000000 ffdf0000 ffffffff ffffffff ffffffff 9fffffff
        00ff: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 2e000000
        01d3: ffffffff ffffffff 007fffff 00000000 00000000 00000000 00000000 00000000
        01d5: 00000000 7b000000 fffdfc5f 00000fff 00000000 00000000 fff00000 ffffffff
        01d6: 000000ff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        01d7: 00000000 00000000 ffc00000 ffffffff 0000ffff 00000000 00000000 003ff000
(w)
        lang: aa|ab|af|ar|ast|ava|ay|az|az-ir|ba|bam|be|bg|bi|bin|br|bs|bua|ca|ce|ch|chm|co|cs|cu|cv|cy|da|de|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|ful|fur|fy|ga|gd|gl|gn|gv|ha|haw|he|ho|hr|hu|hy|ia|ibo|id|ie|ik|io|is|it|iu|ka|kaa|ki|kk|kl|ku|ku-ir|kum|kv|kw|ky|la|lb|lez|ln|lo|lt|lv|mg|mh|mi|mk|mo|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|sah|sco|se|sel|sh|shs|sk|sl|sm|sma|smj|smn|sms|so|sq|sr|ss|st|sv|sw|tg|tk|tn|to|tr|ts|tt|tw|tyv|ug|uk|uz|ven|vi|vo|vot|wa|wen|wo|xh|yap|yi|yo|zu(w)
        fontversion: 147456(i)(w)
        capability: "otlayout:DFLT otlayout:arab otlayout:armn otlayout:cyrl otlayout:grek otlayout:hebr otlayout:lao  otlayout:latn otlayout:nko "(w)
        fontformat: "TrueType"(w)
        decorative: FcFalse(w)

DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"

Comment 4

[Fabien Tassin]

Attachment: pango view

Comment 5

[Karl Tomlinson (:karlt)]

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

Comment 6

[Fabien Tassin]

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

Comment 7

[Fabien Tassin]

Attachment: Font rendering options

Comment 8

[Karl Tomlinson (:karlt)]

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

Comment 9

[Karl Tomlinson (:karlt)]

Or much simpler,

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

Comment 10

[Fabien Tassin]

Attachment: 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

Comment 11

[Karl Tomlinson (:karlt)]

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

Comment 12

[Fabien Tassin]

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>

Comment 13

[Karl Tomlinson (:karlt)]

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

Comment 14

[Ilja Sekler]

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.

Comment 15

[Karl Tomlinson (:karlt)]

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

Comment 16

[Ilja Sekler]

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

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we close this bug now?

Comment 18

[Ilja Sekler]

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

Comment 19

[Klaus Malorny]

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

Comment 21

[Karl Tomlinson (:karlt)]

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

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.

Comment 22

[Kemcy BEST]

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

Comment 23

[Kemcy BEST]

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?

Comment 24

[Karl Tomlinson (:karlt)]

(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

Comment 25

[Kemcy BEST]

Attachment: Text rendering by xft and cairo

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

Comment 26

[Kemcy BEST]

Attachment: 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 27

[Karl Tomlinson (:karlt)]

Comment on attachment 351405 [details]
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 28

[Karl Tomlinson (:karlt)]

Comment on attachment 351406 [details]
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.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 30

[Klaus Malorny]

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?

Comment 31

[Karl Tomlinson (:karlt)]

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