Description of Problem: After upgrading to skipjack, Konqueror is choosing shitty fonts (look like scaled bitmap fonts). My fontpath is very normal. It is attached. Version-Release number of selected component (if applicable): kdebase-3.0.0-0.cvs20020314.4 How Reproducible: Always. Steps to Reproduce: 1. browse some website, like slashdot.org. Actual Results: Fonts suck Expected Results: Fonts are smooth and decent sizes. Additional Information: See attachments.
Created attachment 50624 [details] appearance of slashdot.org
Created attachment 50625 [details] output of xlsfonts
Created attachment 50626 [details] xfs config file
Do you still see this in the current version? I can't reproduce it, but I couldn't reproduce it in the first place, either.
Did you actually put my fonts and fontpath in place to try and reproduce it?
Have you even done some _basic_ work to debug this problem? Apparently not. I did it for you. KDE is having massive problems with the ISO-10646 encoded fonts that come with XFree86, specifically, in this case, the ones that live in the 75dpi font directory. If you remove the ISO10646 fonts and let it get at only iso-8859-1 fonts, the problem goes away. This ABSOLUTELY needs resolution before we ship. Out of the box things are broken, broken, broken.
Yes, I did, and this certainly does NOT happen with the ISO10646 fonts. If you can still reproduce this on a current install (without moving a .kde from an earlier version to the current one), tar up and attach the .kde directory of a new user affected by this after first startup.
Created attachment 53844 [details] Screenshot of desktop of a new user with ISO10646 fonts, showing this report is invalid
attaching now.
Created attachment 54227 [details] /usr/share/config and .kde for newly created test-user
I'm still getting the good fonts using the /usr/share/config and .kde from your tarball.
Found the problem. It's a combination of your .kde and your broken /etc/X11/fs/config. For some reason, your /etc/X11/fs/config has /usr/X11R6/lib/X11/fonts/75dpi, without the :unscaled, which is causing this. KDE doesn't add this broken font path anywhere, and it's not there after a normal setup (7.3 almost-final, KDE Workstation), so it's just a local config issue.
We may not be able to fix this for Hampton, but it is an issue. RHL 7.1 and 7.2 both put the 75 and 100dpi fonts in the font path w/o :unscaled, so we have an upgrade issue. Especially because there was no problem w/these paths being present for KDE in 7.1 and 7.2.
We should just remove this broken path from /etc/X11/fs/config in some %post script, preferrably XFree86-75dpi-fonts because that's where it supposedly came from. Bitmap fonts without :unscaled are evil.
I have reworked the XFree86 subpackages to ensure :unscaled entries get placed in the xfs config. Due to constant oddball font issues like this coming up all of the time from different angles, I've attacked the problem from a different angle now - the root cause. Scaled bitmap fonts have no reason to exist at all - ever - period. I've ranted about this continually recurring problem upstream, and have pressured _anyone_ to give me a reason that scaled bitmap fonts should continue to exist. So far, not a single person disagrees, and future XFree86 releases will have the bitmap font scaler engine completely removed. I'm planning on either doing it myself, or backporting this for Milan, and also shoving it into all future erratum releases as well. I'll leave this open for now, until I'm reasonably sure that the issue is fixed in a current erratum (most likely the next release).
This is resolved in Red Hat Linux 8.0 to the best of my knowledge. On a clean install, the fontpaths are clean, and on an upgrade they seem to be ok also. Please reopen if some upgrade path still causes this problem, and I'll look into it. I believe it shouldn't be an issue anymore now though.