font in terminal does not resemble font in preview

[Jeffrey Baker]

Binary package hint: gnome-terminal

When choosing a font for your Terminal profile, the preview in the font selector does not resemble the result in the Terminal window at all. Please reference the attached screenshot.

The expected behavior is that the Terminal and the font selector preview look identical. Otherwise the selector is rather useless.

[Pedro Villavicencio (pedro)]

Thanks for your report, Which version of Ubuntu and GNOME Terminal are you running? Does it happens with another application installed on your system?

[Jeffrey Baker (jwbaker)]

This is Hardy with gnome-terminal version 2.21.90-0ubuntu1. I am using a new profile and with almost entirely default settings. Gnome terminal is the only application with this problem. All other apps, Nautilus, etc display the fonts as they appear in the font preview.

[Adam Caldwell (adam-caldwell-deactivatedaccount)]

Works as expected for me in gnome-terminal 2.21.91.1-0ubuntu1. Can original reporter confirm if this bug still occurs for them with all updates applied?

[Jeffrey Baker (jwbaker)]

I think this bug might only manifest itself on a fresh profile. On my machine upgraded from Gutsy (and Feisty and Edgy before) I don't see this problem. But on a completely fresh install with no existing profiles, I still see the bug.

[Adam Caldwell (adam-caldwell-deactivatedaccount)]

Interesting, I'm running a fresh install from hardy alpha 4. What arch are you on, amd64? i386?

[Vytas (vytas)]

After latest fontconfig hardy updates (Feb 28) gnome-terminal fonts seem to be badly blurred despite settings, dunno if it is the same bug

[rubinstein (rubinstein)]

I can confirm the blurry fonts in gnome-terminal. The preview of the fonts is hinted, the actual font in the terminal is very blurry.

[Vytas (vytas)]

I have attached the screenshot of the problem.
It somehow affects QT4 in the same way (at least on Gnome desktop).

Also, changing hinting in Appearance-> Fonts doesn't change the appearance of gnome-terminal fonts, you may set even Monochrome, font still remains the same blurry

[Conn O Griofa (psyke83)]

Confirmed, also running latest Hardy. I've noticed this problem for a while now, and it is especially noticeable when Gnome Appearance Preferences/Font is set to Subpixel/Slight.

The offending font configuration file is /etc/fonts/conf.avail/53-monospace-lcd-filter.conf - if you delete or move this file, the problem will go away.

I suggest that this file is removed entirely; I'm not sure of its rationale. Those with CRT should be careful when assessing this bug, because on an LCD screen, fonts look terrible and inconsistent in Gnome Terminal.

[Jeffrey Baker (jwbaker)]

Thanks for finding this workaround.

[Elio Bezerra da Silva (elio7769-deactivatedaccount-deactivatedaccount)]

Não me mandem mais email, tão enchendo o saco! Vou classificar tudo como
spam!

[Keenan Pepper (keenanpepper)]

I deleted /etc/fonts/conf.avail/53-monospace-lcd-filter.conf and rebooted, and my gnome-terminal still has a blurry font.

[John B. (jbuncher)]

I would like to report that the workaround (moving/renaming /etc/fonts/conf.avail/53-monospace-lcd-filter.conf) does not work for me. It does not matter if I use the nvidia or nv driver on my system, and sub-pixel hinting does nothing for the font in GNOME terminal, no matter what setting is being used (even off).

[pvdeynse (vandeynse)]

I also confirm that moving or deleting file "/etc/fonts/conf.avail/53-monospace-lcd-filter.conf" does not solve the blurry problem with Gnome-terminal.

[John B. (jbuncher)]

I would like to add that this also seems to affect QT apps running in gnome, such as Kile. I haven't tried the QT apps from in KDE yet.

[Michael Kuhn (suraia)]

The following fixes it:

$ cd /etc/fonts/conf.d
$ sudo rm 10-hinting-medium.conf
$ sudo ln -s ../conf.avail/10-hinting-full.conf

So it seems that the configuration in /etc/fonts/conf.d overwrites the GNOME font preferences -- at least for GNOME Terminal.

[John B. (jbuncher)]

@Michael Kuhn:

The provided workaround did not work for me, it had no effect.

I was able to somewhat correct the problem by editing ~/.fonts.conf , which was a file that didn't exist in gutsy (I checked one of my installs). I made sure to have the line <const>hintfull</const> rather than <const>hintmedium</const> at the appropriate place in that file.

This makes the font look better, but I think some antialiasing or something still needs to take place, as the font in the terminal does not look as good as in other apps, like gedit.

So, it looks like most gnome apps are using the global settings which are set by the "appearance" applet, but these are not written to the home directory, so other programs like terminal (no idea why this is affected, it's a gnome app) and qt apps look to ~/.fonts.conf for their behavior.

I tried removing ~/.fonts.conf, but that also had no effect, and the font was still ugly.

[John B. (jbuncher)]

I should add in my previous comment that in ~/.fonts.conf , the antialiasing is set to "true", but I'm wondering if there are multiple ones to choose from, much like "hinting" is set to true, and then there is a "hintstyle". Looking through the man page for fonts.conf was not helpful to me, though I may have missed something.

[John B. (jbuncher)]

Fixed!

Sorry for flooding the list, but I think I've got a workaround for the issue. In ~/.fonts.conf , not only should <const>hintfull</const> replace <const>hintmedium</const> in the "hintstyle" area, but <const>rgb</const> should replace <const>none</const> in the "rgba" section. I've attached my .fonts.conf file as an example.

Note that this doesn't solve the underlying issue, that some program isn't modifying this file like it should, but at least this points to what needs to be done. Can others on this list try the workaround to see if it works for them?

[John B. (jbuncher)]

Be sure to right click and "Save Link As" when downloading the example ~/.fonts.conf file, as it is an XML file and if you simply click the link firefox tries to render the xml, and just displays a page with " rgb true hintfull true ", which is definitely not the format of ~/.fonts.conf!

[Jan Frybort (jan.frybort)]

@John Buncher: In mine ~/.fonts.conf were all the sections already configured as you suggested. So no change for me and the terminal font still looks terrible.

[Simon Engelsman (simon-engelsman)]

@John Buncher: thanks! Your workaround works great for me on my hardy workstations.

[pvdeynse (vandeynse)]

@Michael Kuhn:

  The provided workaround did indeed fix my problem, thanks.
  BTW for those whom it may concern, i did not have a file ~/.fonts.conf

[Pascal de Bruijn (pmjdebruijn)]

I can confirm that the latest version of Hardy still has this bug.

However, Michael Kuhn fix solves it.

dpkg -S /etc/fonts/conf.avail/10-hinting-medium.conf
fontconfig-config: /etc/fonts/conf.avail/10-hinting-medium.conf

Shouldn't this bug be moved to fontconfig-config?

Isn't it weird to have hinting by default at medium? insteaf of full?

[Pascal de Bruijn (pmjdebruijn)]

I took the liberty of reporting a bug on fontconfig:

https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/210921

[John B. (jbuncher)]

I'm not sure why Michael Kuhn's workaround did not work for me before, as it does now on my hardy beta clean install (as opposed to my earlier hardy alpha clean install). I also have no ~/.fonts.conf , go figure.

also, I think

$ cd /etc/fonts/conf.d
$ sudo ln -s ../conf.avail/10-subpixel-rgb.conf

should be done as well, so that the subpixel ordering is nice. This makes a noticeable difference on my machine, others may need vrgb or bgr or some such thing

That, or the settings in the fonts application should override what is in this directory.

[John B. (jbuncher)]

I don't know why I didn't notice this before, but it seems as though 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?

Qt apps don't respect the settings in that fonts dialog after removing the /etc/fonts/conf.d/10-* symlinks, but they do look nicer than *with* the links, and they didn't respect the settings in that dialog in gutsy either.

[yaztromo (tromo)]

I was wondering why gnome-terminal had stopped anti-aliasing fonts until I found this bug. Removing /etc/fonts/conf.d/10-* brought anti-aliasing back. Thanks!

[Tobias Wolf (towolf)]

The special rules in /etc/fonts/conf.avail/53-monospace-lcd-filter.conf are there because some developers were vehemently against making the change to the new subpixel rendering.
The file is a compromise they accepted since they work mainly in terminals anyway.

Not really a bug. It's intentional.

[Vytas (vytas)]

WTF, keeping a different (and unconfigurable) font appearance is intentional???
Tobias please don't make such bad tasted jokes, it's a bug report after all

[Slight Slightly (slight--deactivatedaccount)]

Whether it's a bug or intentional upstream Ubuntu ships with sub-pixel rendering so the Ubuntu version should ship with a version of gnome-terminal with it enabled. This bug keeps coming back too, it was in Dapper and Edgy if I remember correctly.

I have it with a Gutsy box upgraded to Hardy by the way, so it's not specific to new installs.

[Sur Demir (surdemir)]

I had this issue on a fresh Hardy Heron RC installation, on both gnome-terminal and xfce's Terminal.
This system in question is a notebook.
I removed the symlink to 10-no-sub-pixel.conf, and added a symlink to 10-sub-pixel-rgb.conf
Now terminal fonts look better.
I hope we get a better fix for this issue than hacking base fontconfig layout.

[Detlef Lechner (detlef-lechner)]

I notice the same error on a Fujitsu-Siemens Amilo7600 notebook computer (alternatively called Amilo-A CY26), Ubuntu 8.04 (an upgrade from 7.10) with all current updates installed. VGA compatible controller: ATI Technologies Inc Radeon Mobility U1. Video driver = vesa. Resolution: 1024x768.
System > Settings > Appearance > (Appearanc Preferences) > Fonts > Rendering=Monochrome.
Details > 'Font Rendering Details': Smoothing=None, Hinting=Full. Subpixel Order=RGB.
The GNOME terminal displays all 8-point fonts blurred in its main pane but all menu items crisp:
http://ubuntu-pics.de/bild/712/blurredZT8S1.png
GNOME diplays also its associated dialog windows 'Appearances Preferences' and 'Font Rendering Details' with crisp letters. There is one exception: The GNOME terminal displays the 'AR PL UMing CN' font crisp in its main pane if the font size is >= 10 points.

[Conn O Griofa (psyke83)]

Detlef,

Try my workaround in comment #10. Just remember that this change will not take effect until all terminals are closed, or perhaps it requires you to log out and back in.

[Detlef Lechner (detlef-lechner)]

Conn:
I tried your workaround in comment #10. I rebooted. There is no change. Sorry.

[Gonzhauser (gonzhauser)]

You shouldn't have to reboot, closing all terminals and open a new one works for me.

Now I have three configurations in Hardy for fonts:
1. /etc/fonts/conf.d
2. /usr/bin/gnome-appearance-properties
3. ~/.fonts.conf

All gnome fonts except the terminal are controlled by 2., gnome-terminal fonts are only controlled by 3.!
I think there are two things that should be done:

a) Cleanup /etc/fonts/conf.d:
Why is it set to antialias, hinting medium, no-sub-pixel?

b) Unify configs:
Why does above directory exist if appearance is controlled by gnome-appearance-properties?

c) Why doesn't gnome-terminal respect none of settings 1. and 2.?

I _am_ a developer (vi on a notebook) and my preference for gnome-terminal fonts is
antialias, hinting full, sub-pixel, rgba=rgb
.

I think the 53-... symlink should be remove because developers are man enough to write their own .fonts.conf!

[Gonzhauser (gonzhauser)]

By the way, with subpixel antialiasing "ls --color" looks much worse than "ls" alone.
Is this a principal problem with colored fonts and subpixel antialiasing on LCD screens or just a bug?

[Gonzhauser (gonzhauser)]

Ok, I had LS_COLORS set to bold for links, that explains it.

[Qishuai Liu (lqs)]

vte uses xft for font backend, while others uses pango.
This may be a bug of xft, which doesn't follow xsetting.

[Simon Eisenmann (longsleep)]

This is still an issue with hardy. I have vte version 0.16.13 and had to create ~/.fonts.conf to get font rendering all right in gnome-terminal.

[leeyee (leeyee-seu)]

I had this problem too, I upgraded from 7.10 with alternate CD. The gnome-terminal and fluxbox menu font both had the problem.

In my laptop, i fixed it as following:

1, cd /etc/fonts/conf.d
2, sudo rm 10-hinting-medium.conf
3, sudo ln -s ../conf.avail/10-hinting-full.conf

then restart gnome-terminal, it works!

[Bryce Harrington (bryce)]

Not sure why xft was subbed to this; there is no explanation in comments for changed needed to xft, so am unsubscribing it.

[Mikael Ståldal (mikaelstaldal)]

This is probably not a problem with gnome-terminal itself. The same problem occurs in xterm as well.

[Marius Gedminas (mgedmin)]

Mikael: xterm is not a GNOME program, therefore I'm not surprised it doesn't follow the GNOME font rendering settings. Gnome-terminal, on the other hand, is and should.

[Ralph Corderoy (ralph-inputplus)]

Just a point on the .fonts.conf provided above. `rgba' is being set to `rgb'. This will make coloured pixels be used around the edges of black text on a white background; it won't stick to just gray pixels. That may be OK for an LCD but if you want grayscale, set rgba to `none' instead. Many thanks for the .fonts.conf being provided by John Buncher in the first place.

[Roberto Scelzo (robertoscelzo)]

Thank you leeyee!
Your suggestion worked for me!
Robert

[Sebastien Bacher (seb128)]

that's not a gnome-settings-daemon issue

[Dan Lea (danlea)]

I'm another person who didn't have a .fonts.conf file in his home directory. Putting the example file included here did fix the problem for me. Naturally I needed to put the file in /root to get programs running as root to behave as well.

[Dan Lea (danlea)]

Would just like to mention Opera as the program for which this issue was most problematic for me, and I expect many other people - it just makes it easier for them to find this bug report.

[m.dundee (cryforabadman)]

Just a confirmation that this bug makes Opera almost unusable. Also, it's not specific to clean Hardy installs, upgrades from Gutsy have this problem with Opera too.

[sky (skyams)]

Here is how i solved the font problem in ubuntu:

1) recompile Freetype2 enabling bytecode interpreter (http://www.linuxquestions.org/questions/linuxquestions.org-member-success-stories-23/making-non-antialiased-fonts-looks-nice.-257705/ take a look here for more infos)

2) install windows fonts (msttcorefonts package, or take them directly from a windows install, i use verdana 10pt as standard font and Curier New 10pt for monospace)

3) Set antialiasing to NONE

Strange enough, this alone wont solve the problem with gnome terminal (at last for me), which will still have blurry fonts. I solved the problem like this (but i dont have the slightest idea why it works)

4) Install KControl

5) run it and in Appearance & Themes->Fonts set Use Antialiasing to Disabled

i hope it will help

[Alessandro Loffredo (cyberalexgm)]

Hi, i used the workaround described in post n°17 and the look of gome-terminal fonts gets better. I think that character are anyway antialiansinged (see attachment). The problem is that i don't use antialiasing (i hate it on my laptop lcd).. In Gutsy i didn't have problems..
Alex

[Freedesktop (freedesktop)]

Currently default config files have things like:

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

This is wrong as it overwrites the rgba element unconditionally. Even if the user had it set to other values. Conf should only set these if not currently set.

[ChrisDesjardins (cddesjardins)]

I also want to add that I am having this issue with a fresh install of 8.10 and that using John B.'s font.conf work around sharpened up my fonts for me.

[mbana (m.bana)]

Yes, this became noticeable to me starting from Hardy, I REALLY hate the way it's being done now i.e., setting the rendering settings in gnome appearance doesn't change everything, see https://bugs.launchpad.net/ubuntu/+source/vte/+bug/204854.

Here's a workaround for Intrepid 8.10, that seems to work for me;

        <!-- hintnone, hintslight, hintmedium, hintfull -->
        <!-- Keep autohint off -->
        <!-- Blurry fonts: Try rgb, bgr, vrgb, vbgr for "rgba" -->
        <!-- Blurry: http://forums.gentoo.org/viewtopic-p-5060979.html#5060979 -->
        <match target="font">
                <edit name="rgba" mode="assign"><const>rgb</const></edit>
                <edit name="autohint" mode="assign"><bool>false</bool></edit>
                <edit name="antialias" mode="assign"><bool>true</bool></edit>
                <edit name="hinting" mode="assign"><bool>true</bool></edit>
                <edit name="hintstyle" mode="assign"><const>hintfull</const></edit>
        </match>

Having to hunt for a solution like this really time consuming.

[MichaelM (michael-the-drummer)]

The workaround for me (I want full subpixel hinting for terminal) is to do this:

cd /etc/fonts/conf.d
sudo unlink 10-hinting-medium.conf
sudo ln -s ../10-hinting-full.conf .

That fixes it for me. However, it should really be following the font settings in the Gnome Appearance Preferences dialog.

[Arne Goetje (arnegoetje)]

MichaelM wrote:
> The workaround for me (I want full subpixel hinting for terminal) is to
> do this:
>
> cd /etc/fonts/conf.d
> sudo unlink 10-hinting-medium.conf
> sudo ln -s ../10-hinting-full.conf .

This is the setting *you* prefer. Other users may prefer something else.

>
> That fixes it for me. However, it should really be following the font
> settings in the Gnome Appearance Preferences dialog.

libvte is the culprit here. It doesn't honor the Gnome font settings or
we wouldn't have this bug report.

[Styg (stygar-laszlo)]

I did a brand new install of Intrepid Ibex and I found the Gnome Terminal's font rendering unfortunately is far from the perfect - just as described above.

I've installed the package msttcorefonts and I'd like to user the font 'Courier New' in the Gnome Terminal. This is the fixed font in my Gnome appearance, but Gnome Terminal render this font very ugly.

After use John B.'s .font.config file (and set the 'antialias' false) I see brilliant font rendering, just as I wish in my dreams (see attachment).

Thank you all your help.

[Valentin Neacsu (valentin.neacsu)]

Just as above, brand new install of Intrepid x86. Bug is still there. Removing the 10-* links in /etc/fonts/conf.d/ fixes the problem.

[Karl Tomlinson (bugs+launchpad)]

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/190848/comments/40

> vte uses xft for font backend, while others uses pango.

Yes, and Pango uses cairo.

The problem does not appear with cairo, because fontconfig settings sometimes
do not get respected in cairo due to

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

which causes other problems, reported in bug 200707, bug 209256, and bug
293643.

> This may be a bug of xft, which doesn't follow xsetting.

libXft was the original library that effectively defines the interaction of
fontconfig and Xft X resource settings. IMO it is a bug that cairo does not
emulate this behavior consistently.

[Karl Tomlinson (bugs+launchpad)]

In reply to comment 45:

> Mikael: xterm is not a GNOME program,

True, but ...

> therefore I'm not surprised it doesn't follow the GNOME font rendering
> settings.

... last I checked, GNOME settings cause Xft X server resource database
properties to be set, and so should have an effect on xterm behavior unless
overridden by fontconfig settings.

The bug here is that system fontconfig settings are always overriding settings
from Xft X resources.

The upstream bug is https://bugs.freedesktop.org/show_bug.cgi?id=17722, but
upstream fontconfig does not install these problem files by default.

The problem only appears when the distribution installs the 10-* links in
/etc/fonts/conf.d/.

[Karl Tomlinson (bugs+launchpad)]

I suggest that the best fix is to modify the system fontconfig settings, so
that they become defaults rather than always overriding settings already
present in the pattern.

This would include changing 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>

and changing 10-hinting-medium.conf 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>

There are other files that should also be changed similarly.

Further discussion at
https://bugzilla.mozilla.org/show_bug.cgi?id=458612#c21

[Kokoa (ko2008)]

I'm using Intrepid and removing the 10-* links in /etc/fonts/conf.d/ does NOT fix the problem.
I removed the links by entering the following command:
sudo mv /etc/fonts/conf.d/10-* /some-directory/
Problem remained even after reboot.

[Karl Tomlinson (bugs+launchpad)]

Kokoa, do you have a ~/.fonts.conf? Does moving that help?

[Karl Tomlinson (bugs+launchpad)]

and don't forget to remove /etc/fonts/conf.d/53-monospace-lcd-filter.conf

[mbana (m.bana)]

I can't believe this hasn't been fixed yet, clearly it's bothering a lot
of people.

Karl Tomlinson wrote:
> and don't forget to remove /etc/fonts/conf.d/53-monospace-lcd-
> filter.conf
>
>

[Kokoa (ko2008)]

Karl, I don't have ~/.fonts.conf and I removed 53-monospace-...conf and all 10-* links. Still same problem. This also affect emacs-snapshot-gtk (version 23) with "Emacs.font: Monospace-10" set in .Xresources. The Monospace-10 font in Emacs-snapshot and in Gnome-terminal looks like those in the 'fonts.png' screenshot.

$ ls ~/.fonts.conf
ls: cannot access /home/fj/.fonts.conf: No such file or directory
$ echo ~/.font*
/home/fj/.fontconfig /home/fj/.fonts

Only difference I made to my fresh Ubuntu 8.10 system regarding fonts is that I added some Korean fonts to ~/.fonts , and installed xfonts-terminus and texlive-fonts-extra package, and removed 10-* links and 53-monospace-lcd-filter.conf.

Maybe there are other files that need to be removed?

$ ls -F /etc/fonts/conf.d/
11-lcd-filter-lcddefault.conf@ 52-languageselector.conf@
20-fix-globaladvance.conf@ 60-latin.conf@
20-unhint-small-vera.conf@ 64-ttf-arphic-uming.conf@
25-ttf-arphic-uming-render.conf@ 65-fonts-persian.conf@
30-cjk-aliases.conf@ 65-nonlatin.conf@
30-defoma.conf@ 65-ttf-thai-tlwg.conf@
30-metric-aliases.conf@ 69-unifont.conf@
30-urw-aliases.conf@ 70-no-bitmaps.conf@
35-ttf-arphic-uming-aliases.conf@ 80-delicious.conf@
40-nonlatin.conf@ 90-synthetic.conf@
41-ttf-arphic-uming.conf@ 90-ttf-arphic-uming-embolden.conf@
44-wqy-zenhei.conf@ 90-ttf-thai-tlwg-synthetic.conf@
45-latin.conf@ README
49-sansserif.conf@ ttf-bengali-fonts.conf
50-enable-terminus.conf ttf-kannada-fonts.conf
50-user.conf@ ttf-oriya-fonts.conf
51-local.conf@ ttf-telugu-fonts.conf

[Valentin Neacsu (valentin.neacsu)]

Still a problem in Intrepid. Removed 10* and 53* links and still the problem is there. Most annoying is for 8pt Mono fonts in gnome-terminal, which does in no way resemble what the preview and gedit show. Somehow the font spacing is different in gnome-terminal than what it should be.

Check attached images for more details.

PS: is it me or is the lcddefault LCD filter much much worse than the "default" LCD filter, whichever that may be. Removing the 11-lcd-filter-lcddefault.conf symlink was a revelation for me, giving me Windows-like crisp fonts.

[Valentin Neacsu (valentin.neacsu)]

The zoomed picture. Notice the different spacing between the letters, amongs several other differences.

[Pedro Villavicencio (pedro)]

this isn't a blocker for jaunty.

[Andre Chudio (andre208)]

On a fresh installation, I have just removed the /etc/fonts/conf.d/10-antialias.conf file
and the font appearance in gnome-terminal behaves correctly (hinting and antialiasing )

[Valentin Neacsu (valentin.neacsu)]

Have you tried all possible font settings combinations? The example I gave above is for full hinting and subpixel.

[Andre Chudio (andre208)]

On a fresh installation, I have just removed the /etc/fonts/conf.d/10-antialias.conf file
and the font appearance in gnome-terminal behaves correctly (hinting and antialiasing )
In fact, the smoothing on small fonts is the main reason that hurts my eyes.
After deeper testing, I notice that the hinting setting in "System -> Appearance Preferences -> Details"
does not affect the gnome-terminal.
So I suggest as other persons to remove all 10-* in /etc/fonts/conf.d

$ cd /etc/fonts/conf.d
$ sudo rm 10-*

I made my testing using the msttfonts (Verdana and Courrier New) and liberation fonts (Sans and Mono) size 10

System -> Appearance Preferences -> Rendering = Monochrome

System -> Appearance Preferences -> Details -> Resolution = 96dpi
System -> Appearance Preferences -> Details -> Smoothing = None
System -> Appearance Preferences -> Details -> Hinting = Full
System -> Appearance Preferences -> Details -> SubPixelOrder = RGB ( not use because Smoothing is None )

See the result in attachment.

[Valentin Neacsu (valentin.neacsu)]

I should have been more specific. Try Subpixel smoothing, full hinting and a font of size 8 or smaller, then compare the results in the terminal window with those in the Fonts tab of the Appearance Preferences window. With or without the 10-* symlinks removed, the result is that which I have attached earlier.

[Robert Ancell (robert-ancell)]

I have tried subpixel smoothing, full hinting and a font size of 8 in 9.04 (Jaunty) and the font is the same in both the preview and the terminal window. Is this problem occurring for anyone in Jaunty?

[dhenry (tfc-duke)]

It seems to be fixed in jaunty.

[yaztromo (tromo)]

Fixed for me with xfce4-terminal in Jaunty

[Valentin Neacsu (valentin.neacsu)]

It's fixed for me aswell. Thanks!

[Robert Ancell (robert-ancell)]

Closing as fixed in Jaunty. Thanks for the feedback.

[Akiro (akiro)]

Is it maybe a good idea to have is_set and not_set for compare attribute?

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

Even though it may be hard to determine which one (no-sub-pixel, sub-pixel-{bgr,rgb,vbgr,vrgb}) is better for. I guess this kind of config is never enabled by default and should simply leave it to the desktop preferences.

[Bugs-freedesktop (bugs-freedesktop)]

qual="all" can actually already be used to test that a value is not set because it always returns true when there are no values to test. i.e. All zero values match.

For the rgba case, overriding a value of "unknown" seems quite reasonable.

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

The match will apply when rgba is set to "unknown" or when rgba is not set.

For some other properties there is no unknown value, and so using qual="all" gets more obscure because we have to compare with a value that will never match an appropriately set value. e.g.

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

I found that making these "set when not already set" rules work appropriately with Qt3 required an additional hack. Qt3 was calling FcFontMatch (and thus FcFontRenderPrepare) before XftFontMatch (which calls FcFontMatch again after
XftDefaultSubstitute). Xft screen options had not been applied in the
first FcFontRenderPrepare (before XftFontMatch), and so the rules were matching and setting values that would take precedence over Xft screen options. This situation was detectable through missing pixelsize as FcDefaultSubstitute had not been called before the first FcFontRenderPrepare. I haven't looked at Qt4.

This test matches only when pixelsize is set (-1.0 is considered an inappropriate value).

  <test name="pixelsize" target="pattern" compare="not_eq">
    <double>-1.0</double>
  </test>

[Bugs-freedesktop (bugs-freedesktop)]

(In reply to comment #1)
> I guess this kind of config is
> never enabled by default and should simply leave it to the desktop preferences.

You would hope so, but some distribution(s) where enabling these by default.
Hopefully they have stopped doing that now.

[Akiro (akiro)]

(In reply to comment #2)
> qual="all" can actually already be used to test that a value is not set because
> it always returns true when there are no values to test. i.e. All zero values
> match.

Hmm, that sounds like a bug though. IMHO we should drop such config entirely instead of ignoring the invalid element only or warn it at least, because there may be a typo and it's hard to track down when something behaves unexpectedly.

[Bugs-freedesktop (bugs-freedesktop)]

(In reply to comment #4)
> (In reply to comment #2)
> > qual="all" can actually already be used to test that a value is not set because
> > it always returns true when there are no values to test. i.e. All zero values
> > match.
>
> Hmm, that sounds like a bug though.

Adding "set" and "not_set" comparisons sounds sensible to make things clearer,
but I don't think the "all" behavior is a bug.

Please don't change the behavior of all.
It is this behavior that makes all,not_eq the complement of any,eq.

[Akiro (akiro)]

(In reply to comment #5)
> Adding "set" and "not_set" comparisons sounds sensible to make things clearer,
> but I don't think the "all" behavior is a bug.

the behavior of qual="all" itself isn't a problem. I just think either of cases should be checked with qual="all" compare="not_eq" even if the testcase contains any invalid thing, as you indicated in the last example. that really makes sense for what you want to. but relying on "All zero values match" isn't a good idea, because it's the side-effect because of no-error-handling.

> Please don't change the behavior of all.
> It is this behavior that makes all,not_eq the complement of any,eq.

If there are too much cases relying on this behavior, we should show a warning at least if something failed to parse, because it's difficult to see whether something might looks like a typo is desired or not. let's see how much things using this trick and we can avoid an regression as much as possible.

[Freedesktop (freedesktop)]

An alternative may be to simply make these configs append values instead of assign. Most clients I guess care about the first value only.