Bug 37494

Summary: Setting anti-aliased fonts switches all fonts to script
Product: [Retired] Red Hat Linux Reporter: Greg Corson <greg_corson>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: 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-07-14 16:11:19 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:
Attachments:
Description Flags
output of chkfontpath from system where anti-aliasing works ok
none
Output of checkfontpath from system with broken anti-aliasing
none
output from chkfontpath -l on system with working anti-alising
none
Output of chkfontpath -l on system with broken anti-aliasing
none
my workaround for this problem, also in Mandrake 8.0 none

Description Greg Corson 2001-04-25 02:15:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)


When I select anti-aliased fonts in KDE, all fonts change to a script font 
that is unreadable.  Also, the choices of fonts in the font menu is 
reduced drastically.  (no helvetica for example)

Reproducible: Always
Steps to Reproduce:
1.Enter KDE control panel
2.Select anti-aliased fonts
3.restart X server
	

Actual Results:  All fonts are antialiased, but have been changed to 
script.  Many font choices are missing from the font menue.

Expected Results:  Font choices should remain the same as they were before 
antialiasing was turned on (this is what happened in the wolverine beta)

Could it be that only certain types of fonts can be anti-aliased now?

Regardless, the font setup of these distributions needs work...appearance 
of web pages are frequently terrible micro-sized type compared to 
Windows.  Fixing this would make the system more attractive to beginners 
who don't know how to hack the system to improve it.

Comment 1 Bernhard Rosenkraenzer 2001-04-26 16:07:02 UTC
This is not technically a bug. The problem is that the standard fonts 
(Helvetica etc.) are bitmapped fonts, meaning they can't be antialiased.

The Xrender extension therefore takes a different font; since it has no way of 
knowing what the font is supposed to look like, it picks the (alphabetically) 
first font that matches the other parameters (which is really just 
proportional vs. monospaced), which happens to be Arioso (a script font) on 
fairly standard systems.

The obvious fix would be to hardcode a list of standard fonts and a list of 
possible replacements into Xrender; not very nice, but effective (assigning to 
XFree86 for this purpose).

An alternative fix would be to use scalable fonts even in non-anti-aliased 
mode, but this would slow things down.

Workaround: Turn on anti-aliasing and switch to a resolution where the font is 
readable.
Open KControl, go to Look and Feel -> Fonts and pick other fonts.



Comment 2 Greg Corson 2001-04-26 17:02:18 UTC
Just two things that are rather odd....

1. This wasn't a problem with Wolverine Beta, it worked fine.

2. Someone else in the office did a workstation install on a desktop PC (mine 
is a laptop) and it seems to have the full font list available when doing anti-
aliased fonts.  The only differences between their system and mine are a 
slightly higher res monitor and he is using KDE by default while I'm choosing 
it from the gnome "session" menu on the login screen.

Could there be some difference in the way the font server was configured this 
time around?  He did do a workstation while I did a custom install and checked 
ALL the packages.  Both installs were from the same disk set/version (seawolf)

Comment 3 Greg Corson 2001-04-27 18:22:16 UTC
Created attachment 16667 [details]
output of chkfontpath from system where anti-aliasing works ok

Comment 4 Greg Corson 2001-04-27 18:24:22 UTC
Created attachment 16668 [details]
Output of checkfontpath from system with broken anti-aliasing

Comment 5 Greg Corson 2001-04-27 18:26:37 UTC
Created attachment 16669 [details]
output from chkfontpath -l on system with working anti-alising

Comment 6 Greg Corson 2001-04-27 18:27:53 UTC
Created attachment 16670 [details]
Output of chkfontpath -l on system with broken anti-aliasing

Comment 7 Greg Corson 2001-04-27 18:37:20 UTC
See the previous attachments for samples of the font server configuration on a
system where anti-aliasing seems to work, and on one where it doesn't.

I'm wondering if the font server on the broken system might have so many bitmap
versions of each font that it always returns a bitmap version, even if a
scaleable one exists too...tricking KDE into thinking there isn't a scaleable
version to use for anti-aliasing.  For example, there are 477 "helvetica" fonts
listed on the broken system and only 120 on the working one.

The other strange thing is that when anti-aliasing is turned on the "broken"
system shows a number of font names that don't show up at all on the output of
chkfontpath, on the font picker of the working system or on the font picker of
the broken system when anti-aliasing is off.  These font names include "Arioso",
"Chevara" and "Conga"

Any ideas?

Comment 8 Greg Corson 2001-05-04 01:58:20 UTC
Ok, I have spent some time examining the system configuration as created by both
a workstation install and an "everything" install.  I think I have located the
problem, or at least the reason why it is so confusing.

Out of the box it looks like X is configured NOT to use freetype, Type1 or
TrueType fonts even though some are in the xfs font path.  The xft (freetype)
module which has a different font list than xfs, which includes a number of
Truetype fonts.

I'm no expert, but from experimenting with how things work, it appears that when
in KDE anti-aliased mode, you get only the truetype fonts from paths in the xft
config file.  Since X has not been configured to support Type1, TrueType or
Freetype, when you turn anti-aliasing OFF, none of the TrueType fonts are
available.  This seems to account for why aliased and anti-aliased modes create
totally different font lists with no fonts in common.

It would greatly reduce confusion if, at minimum, the installer configured X to
use TrueType AND configured both xft and xfs to have the same set of TrueType
fonts in their paths.  At least this way, when someone switches on anti-aliasing
they would only see their list of available fonts shrink, rather than see it
completely change.

The other problem that is probably fixable is getting all script fonts when you
switch to anti-aliasing the first time.  If, like you said, the font engine is
hunting for something similar to helvetica and can't find it, so it picks
Arioso, wouldn't it be possible to specify the default font types a bit more
completely so it will find a more readable font?  For example, can you specify a
non-serif'ed font?

A related problem seems to be that there is no TrueType font in the current
distribution that matches what KDE wants as a "fixed" font (the second choice
down in the KDE "Fonts" panel) so even if you manually set it to a readable
font, it keeps jumping back to Arioso on it's own.

The easiest fix, I suppose, would be to supply a "helvetica" and a "fixed"
TrueType font.  Failing that, there seems to be a lot of substitution/aliasing
stuff in the font servers, couldn't some kind of alias be installed so the
system would pick a more readable font than Arioso when it failed to find a
match for the helvetica it wants?

If possible, please confirm if it sounds like I'm write about how X and your xfs
& xft servers are configured.  After I've reved the config files to produce a
better presentation, I'd be happy to send you the changes



Comment 9 Greg Corson 2001-05-07 21:21:58 UTC
Did some more work, installed some of the Windows TrueType fonts and finally 
discovered what the problem was with the fonts in 
/usr/share/fonts/default/TrueType (Arioso, Chevera...etc.) It appears these 
fonts did not have a correctly built fonts.dir file (it was empty) after 
rebuilding this, they show up properly in both aliased and anti-aliased modes.

So ACTUAL BUGS
1. /usr/share/fonts/default/TrueType (part of an "everything" custom install) 
needs to have the fonts.dir and fonts.scale rebuilt.  As shipped, they only 
work with the xft font rendering stuff in anti-aliased mode and won't appear 
under xfs.
2. The "fixed width" font in the KDE font picker module is unable to find any 
font it likes when in anti-aliased mode.  The list of available fonts contains 
only "fixed" which looks ok but if you choose it, it will revert to the first 
truetype font on the list every time you logon.

ISSUES
1. You should have a mini faq/HOWTO that describes how your font server (xfs 
and xft) are setup, it took me some time to figure out that one was serving 
aliased truetype and the other anti-aliased truetype.  None of the on-line 
howto's gave a good description of how this was setup.
2. You should attempt to supply fonts or font aliases so that when someone 
switches into anti-aliased kde the first time, they get a readable 
configuration.

If you can confirm that what I've found is correct before closing this bug, 
I'd appreciate it.


Comment 10 Bernhard Rosenkraenzer 2001-05-09 08:39:37 UTC
*** Bug 39628 has been marked as a duplicate of this bug. ***

Comment 11 Greg Corson 2001-05-11 22:48:06 UTC
I've tried the fix in bug 39628 which seems to work in anti-aliased mode.  
However when I switch back to normal mode, now pressing the "choose" 
button for the "fixed" font results in xfs crashing.  This is on a freshly 
installed machine.  Prior to using anti-aliased mode and switching back to 
normal mode the font picker used to return a whole list of fonts for this 
choice.

I've done nothing to the xfs config file that would result in fewer fonts being 
available.

Comment 12 Bernhard Rosenkraenzer 2001-05-14 10:55:07 UTC
*** Bug 40329 has been marked as a duplicate of this bug. ***

Comment 13 Need Real Name 2001-05-15 13:14:21 UTC
Created attachment 18391 [details]
my workaround for this problem, also in Mandrake 8.0

Comment 14 Greg Corson 2001-05-21 18:51:16 UTC
Any chance of a binary version of this patch?  I'd prefer not to have to go 
through the exercise of building kdelibs from source if possible.


Comment 15 Rex Dieter 2001-06-19 15:28:33 UTC
I've built a new kdelibs incorporating the patch provided here.  It's 
available from my website: 
http://www.math.unl.edu/~rdieter/Software/Linux/kde/
Enjoy.


Comment 16 Mike A. Harris 2002-07-14 16:11:15 UTC
Bero, is this problem still present in rawhide with Xft2/fontconfig?  If
so, we should try to resolve it.  I haven't had any reports of it happening
now for ages, so I assume it is no longer a problem in RHL 7.3 and later.

Comment 17 Mike A. Harris 2002-09-05 19:51:24 UTC
This problem hasn't occured for a while now.  It definitely isn't
present in rawhide currently, and our final release of our new OS
once released shouldn't show this problem either.

Closing as RAWHIDE