Description of problem: For some reason, kdelibs 4 is defaulting to “Sans Serif” and interpreting that as “Nimbus Sans L”, whereas it would be expected to default to “Sans” which is a FontConfig alias for “DejaVu Sans”. Version-Release number of selected component (if applicable): kdelibs-4.0.3-7.fc9 How reproducible: Always Steps to Reproduce: 1. Boot the F9 final KDE live CD and check what fonts it's using. Actual results: It says “Sans Serif” and uses “Nimbus Sans L”. Expected results: It says “Sans” and uses the FontConfig "Sans" alias, which resolves to “DejaVu Sans”. Additional info: Workaround: In System Settings, pick Appearance, Fonts, Adjust all fonts..., check Font and set it to DejaVu Sans, check Font style and set it to Regular.
Kevin, it looks like a fontconfig setting and should be fixed in fontconfig. Gnome/KDE should use the font alias instead hardcoding
It actually looks like Qt is not following the fontconfig settings. Sans Serif and Sans should be equivalent and both aliases for DejaVu Sans, that's how fontconfig is configured.
(And "Sans Serif" appears to actually be the right thing to use, the bug is that it's resolving to the wrong actual font.)
/etc/fonts/fonts.conf contains aliases for "sans" and "sans serif", and calls "sans" deprecated. fwiw, gnome's control center displays the default font: Sans both qtconfig and systemsettings display only "Sans Serif", no "Sans".
Qt 4 hardcodes a substitution which replaces "sans serif" with "helvetica", I'm currently building a package which disables this nonsense.
Using a local quick-n-dirty no-nonsense build of qt, I can confirm it fixes this issue.
Gnome uses Sans for Sans Serif, Qt uses Sans serif. I did the patch for Qt in the past to behave like in gnome. IMO it's wrong what was doing in Gnome, so i removed the patch.
Should be fixed in qt(4)-4.3.4-14 and qt-4.4.0-4.fc10, F8 and F9 builds completed, F7 and F10 still running, I'll submit updates once everything is built.
qt-4.3.4-14.fc9 has been submitted as an update for Fedora 9
qt4-4.3.4-14.fc8 has been submitted as an update for Fedora 8
qt4-4.3.4-14.fc7 has been submitted as an update for Fedora 7
*** Bug 444170 has been marked as a duplicate of this bug. ***
qt-4.3.4-14.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update qt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4163
qt4-4.3.4-14.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
qt4-4.3.4-14.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.3.4-14.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Hmm, Serif looks OK now, but Sans Serif still picks Nimbus Sans L instead of DejaVu LGC sans. Do I need to delete some config files for the change to take effect?
OK, nevermind, there were some substitutions still lurking around in my ~/.config/Trolltech.conf.
Woo, looks like 0263-fix-fontconfig-handling.diff in latest qt-copy patches may finally address this upstream, so can try/test removing our local qt-x11-opensource-src-4.3.4-no-hardcoded-font-aliases.patch I'll test it out.
Are we making progress on bug 355271, or http://bugs.kde.org/show_bug.cgi?id=57485 ? That'd be cool and highly anticipated!
That's a completely separate issue, please comment in bug 355271, not here. (And no, AFAIK it's not being worked on.)
qt-copy patch tests out good here, local hack/patch removed in qt-4.4.3-10
Re: Comment #22 I am sorry I pointed out that this bug that you reported was likely related to the bug I reported a year earlier. Just like in my bug 355271, you first didn't realize that the problem is because Qt essentially ignores fontconfig. And this is exactly the same conclusion I reached in te earlier bug. So I beg to differ. The root cause of the problems is the same!