Bug 56646

Truetype fonts work fine for me in both GNOME and KDE normally, and
with Anti Aliasing in KDE as well.  I have Microsoft's webfonts
installed also.  Bad looking fonts are usually a case of bad
configuration of xfs, the X server's font path (which is not used
by default in Red Hat Linux), and/or XftConfig

Do you have any more information you can provide to show this as a bug?
Perhaps a few screenshots, copies of your X config, XftConfig, xfs config
all as file attachments using the link below.

I recommend joining xpert, and trying to get help
there for getting AA fonts looking nice, and then attaching whatever
useful info you receive to the bug report.  If there are changes
I can make to the default setup, that solve problems that a few
people have, without causing new problems for others, I am very
much open to make changes.  Unfortunately, if I can't see a problem
someone is having personally, then I can't easily fix it.

I think I was explicit that the details are at the URL I supplied.
http://www.cs.wm.edu/~zvezdan/programs/bugs/antialias/
and I invested enough effort to make that web page and document the problem.

I used the default RedHat supplied font path with the exception that I added
Webfonts to the path and took out AbiWord fonts.

I'm attaching xfs config, XF86Config-4, and XftConfig now.

Created attachment 38403 [details]
/etc/X11/XF86Config-4

Created attachment 38404 [details]
/etc/X11/XftConfig

I removed the Trident part from the summary as it likely is not
relevant...

I just noticed the URL you posted, and read your
http://www.cs.wm.edu/~zvezdan/programs/bugs/antialias/
web page, and can see some of what you are describing now.

I do see something that I need to comment on however:

>Please, also notice that this is not the problem in XFree86-4.1.0
>either. FreeBSD uses that same version of X on the same machine
>and looks OK. Something that Red Hat people did in adjusting X to
>their release has spoiled the look of anti-aliased fonts.

That is jumping to conclusions, and is not necessary.  I personally
maintain XFree86, and freetype, and have not done a single thing to
"adjust X" in a way that displays crappy fonts.  You are the
first person to point out any problems, and I myself have not seen
any problems, so it is hard to solve a problem you are not aware
of.

> But, really, do we have to go to so much effort to make work
> something that was perfect in the previous release without any
> special involvement of sysadmin.

Yes, you do, if you are the only person who has seen the problem,
and nobody else has reported it before the release has finalized.
Bugs in software get fixed only when someone is aware of them.  If
I was aware of such a problem prior to the release, and given steps
to reproduce it, I would gladly have spent as much time as necessary
to determine the source of the problem, and try to find a solution.

XFree86 4.1.0 had many unexpected upstream font related changes. The
addition of unicode font masters, the change of ordering of fonts when
a wildcard encoding is specified, different layout of font directories
causing numerous packaging changes, changes as to how fonts.dir and
friends are generated, and numerous other issues.

I had to do a lot of work to resolve many issues that came
up, and spent many long nights of my own PERSONAL time doing
so, so that our customers would have nice looking and functional
font setup.  Reading your webpage, I feel personally offended,
like you think I somehow purposefully broke things to piss people
off and without regard.  It makes me wonder if I perhaps should
have went to the beach instead.

Now that you have made me aware, I will certainly do my best to look
into it and try to resolve it, even though I haven't yet been able
to reproduce.  I ask you however, to extend me some courtesy.

I'll need you to attach a copy of your various config files I
referenced above, from the broken setup, so I can run with them,
and try to reproduce.

One thing I notice, is that the fonts you're seeing, appear to
be non-hinted.  The freetype libraries include a build time option
to enable the TrueType font hinting byte code interpreter.  By
default, this is disabled in freetype because Apple holds patents
on font hinting:  http://www.freetype.org/patents.html

I do not know if other Linux distributions or the BSD's do it, but
Red Hat does not enable this font hinting code.  If Apple is going
to sue someone over patent violation, it is going to be some
corporation worthwhile suing, not a random build of freetype from
off the internet, or from some open source operating system without
a company behind it.  Yes, this sucks.

I will contact our internal legal department to have them look into
the Apple patent claims, and see if they think they hold any water.

If our legal team thinks it is safe to enable the byte code
interpreter in freetype, I will do so in future builds.  If not,
and it is the cause of what you're seeing, then all I can suggest is
that you recompile freetype with an enabled byte code interpreter.

If it isn't that that is the problem, then hopefully we can work
together to resolve it.

Created attachment 38405 [details]
/etc/X11/fs/config

Adding some of the points from the URL you gave, that I will investigate.

-------------------------------------------------------------------------

* In XftConfig, the line that aliases times with Helmet should alias times with
Timmons instead. Check with ftstrpnm. Helmet is a sans-serif font and hence the
alias for helvetica. Since times is a serif font it needs to be aliased to
Timmons which is a serif font too.

* Aliasing of Verdana to Helmet in that same file causes trouble to people who
actually have real Verdana. Why is Red Hat aliasing a font that it doesn't
actually supply in a bitmapped version? Aliasing helvetica makes sense since you
supply it in a bitmapped version only.

* AbiWord fonts are causing trouble for people with real Arial font. Since their
foundry name is abiword, it's the first font in the list when browser looks for
the generic arial font, instead of the real monotype-arial. It's rather bad
because AbiWord fonts look very bad on screen. I simply took them off font path.
The result is that AbiWord will not start, which I personally do not care since
I do not use it anyway. However, in general one can't do that. Is there a way to
change their foundry name to ZZZZabiword. :=)

Might as well put some other font guru's in the Cc list.  ;o)

Bero, Owen, comments/flames/suggestions?

I see your point and hence the offending paragraphs are dropped from the site.
I'm certainly not a person who would go around and post unsubstantiated claims.
I usually try to find the source of the problem and fix it myself. If it's
worth for the general public I submit the patch back (e.g. Bug 42352 [a good
example where Red Hat patch was a source of problem more than the original
software]). If it's specific for my environment I keep it and merge source rpms
into new releases. This one was different however:

1. Freetype recompilation is a piece of cake, but even without hinting it looked
  good to me as shown on the first two images on my site.

2. I even tried the same config files as on RH7.1 with X-4.0.3 and yet the
results are quite different.

3. X-4.1.0 from FreeBSD works fine on the same machine. It's config files (no
xfs used) didn't help either.

Hence my conclusion from the dropped paragraphs.
In the meantime I noticed the change to ISO-8859-15 being the default for US in
KDE. Is that right? Can that be source of some font troubles?

What's the status of rawhide package XFree86-4.1.0-6? Do I need to go back to
XFree86-4.1.0-3?

I was having the same problem; antialiased text looked way too bold and the
characters would run together.  I'm running 7.2 plus updates plus the KDE 2.2.2
RPMS minus the qt-2.3.2 update, which is busted.

On a whim, I did:

rpm -Uvh /usr/local/redhat-7.1/RPMS/freetype-2.0.1-4.i386.rpm --nodeps --force 

to install the freetype libraries from 7.1.  At least some of the problem is
gone; an xterm -fa 'andale mono' doesn't look bold any longer and Georgia
certainly looks different.  Obviously this has side effects, but it certainly
does narrow down the problem.  (Either freetype-2.0.3-7 is busted, something is
feeding it bad data in a way that 2.0.1 ignores, or 2.0.1 was busted and it's
supposed to look like it does now.)

Next up is freetype-2.0.5 from Rawhide.  And the  verdict is...the problem is
back.  So something changed after freetype-2.0.1 which causes this behavior.

I hope this helps.  This is one in a stack of things preventing me from
deploying 7.2 generally around here.

After some research I realized that the freetype libraries distributed with 7.1
actually had the bytecode interpreter turned on.  I thought it was turned off
(by the freetype developers) before the 2.0 release but that wasn't done until
2.0.2, and I figured that Red Hat had done the CYA thing and made certain that
it was off.  I built some RPMS of 2.0.5-3 from Rawhide with the interpreter
turned on and everything is fine now.  Grumble grumble @$%&#^%(* patents grumble.

I've just found an interesting thing that might help.
I logged in to my old home machine from my Red Hat 7.2 VAIO.
So X server is running on VAIO.
Then I raised Konqueror from OpenBSD machine through ssh and fonts look 
fine on VAIO. Local Konqueror is as bad as it was. The same with xterm.
Look at the page at the URL I gave. I added the screenshot and 
explanation at the bottom.
Does this mean that X is fine, and something before X is distorting
fonts for local applications?

With anti-aliased fonts through the Xft library, rendering is done by the client
instead of by the server as with he X core font protocol.  Thus your VAIO is
only displaying the already-rendered glyphs that the client is sending.  Glyphs
rendered by freetype compiled with the bytecode interpreter look good, others
look poor.  Just changing out freetype completely cleared up the problem for me.

Yes, I realised that as soon as I read your second message. I was playing
with that screenshot and didn't notice it until I already posted.
I've just downloaded SRPM for freetype and will recompile now. Thanks.

All right. The problem is fixed.

I've rebuilt the source RPM with a patch to switch the bytecode interpreter
ON and made binary rpms from it. After applying rpms the anti-aliased fonts
are rendered correctly. I understand that Red Hat can't do this because of
licensing issues.

With this problem resolved this bug can be closed except the three other
things I mentioned:

o Times should be aliased to Timmons (serif) rather than Helmet (sans-serif)
  in XftConfig.
o Do not alias verdana in XftConfig. The people who have real Verdana can't
  get it unless they comment these lines.
o AbiWord arial is used rather than real Arial. It's extremely low quality
  font and it always comes first because of the foundry name.

We are investigating the possibilities of being able to use
the byte code interpreter legally.  no guarantees however.

Keep fingers crossed.

*** Bug 56802 has been marked as a duplicate of this bug. ***

The problem here is not anti-aliasing, but Freetype. Most Red Hat 7.2 users 
will not see bad fonts in the default setup. The reason zvezdan is seeing 
this problem is that in the process of turning on anti-aliasing he bypassed 
xfs. When using the RENDER extension, clients render text, typically by 
calling Freetype. Freetype, as observed already, is built with TT bytecode
interpretation turned off, resulting in the bad font quality. But xfs DOES 
interpret TrueType hints. Try this experiment: use RENDER by setting 
QT_XFT=1, but disable anti-aliasing in XftConfig. TT fonts will not be 
anti-aliased, yet with hints ignored they will look quite inferior to xfs'. 


Red Hat's problem is not legal. XFree86-xfs, as shipped RIGHT NOW, 
is built with TrueType bytecode interpretation ENABLED. It does not 
make sense to enable it in xfs and disable it in Freetype.

Replacing freetype 2.0.3 with 2.0.9 completely removes the boldness 
problem for me.
I took 2.0.9 from rh73 and rebuild with ttmkfdir included!
Bitcode interpreter, maybe, is indeed responsible.