Bug 62028

Summary: konqueror now choosing sucky fonts
Product: [Retired] Red Hat Linux Reporter: Preston Brown <pbrown>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: bero
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-05-21 08:36:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 61590    
Attachments:
Description Flags
appearance of slashdot.org
none
output of xlsfonts
none
xfs config file
none
Screenshot of desktop of a new user with ISO10646 fonts, showing this report is invalid
none
/usr/share/config and .kde for newly created test-user none

Description Preston Brown 2002-03-26 21:01:24 UTC
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.

Comment 1 Preston Brown 2002-03-26 21:01:57 UTC
Created attachment 50624 [details]
appearance of slashdot.org

Comment 2 Preston Brown 2002-03-26 21:02:27 UTC
Created attachment 50625 [details]
output of xlsfonts

Comment 3 Preston Brown 2002-03-26 21:03:13 UTC
Created attachment 50626 [details]
xfs config file

Comment 4 Bernhard Rosenkraenzer 2002-04-03 10:57:15 UTC
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.

Comment 5 Preston Brown 2002-04-03 14:15:21 UTC
 Did you actually put my fonts and fontpath in place to try and reproduce it?

Comment 6 Preston Brown 2002-04-05 20:43:57 UTC
 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.

Comment 7 Bernhard Rosenkraenzer 2002-04-15 10:59:50 UTC
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. 


Comment 8 Bernhard Rosenkraenzer 2002-04-15 11:01:01 UTC
Created attachment 53844 [details]
Screenshot of desktop of a new user with ISO10646 fonts, showing this report is invalid

Comment 9 Preston Brown 2002-04-17 20:04:51 UTC
 attaching now.

Comment 10 Preston Brown 2002-04-17 20:05:52 UTC
Created attachment 54227 [details]
/usr/share/config and .kde for newly created test-user

Comment 11 Bernhard Rosenkraenzer 2002-04-18 12:25:59 UTC
I'm still getting the good fonts using the /usr/share/config and .kde from  
your tarball.  


Comment 12 Bernhard Rosenkraenzer 2002-04-18 12:35:21 UTC
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.

Comment 13 Preston Brown 2002-04-18 14:31:15 UTC
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.

Comment 14 Bernhard Rosenkraenzer 2002-04-18 14:47:13 UTC
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.

Comment 15 Mike A. Harris 2002-05-21 08:35:39 UTC
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).


Comment 16 Mike A. Harris 2002-11-03 09:38:01 UTC
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.