Bug 88259

Created attachment 90995 [details]
Screenshot of xmag'd problem

As far as i understand anti aliasing there shouldn't be any on a straight line
but this seems to be what i'm getting here.

Created attachment 90996 [details]
The fonts.conf file

This is the fonts.conf file showing sub pixel rendering.

Created attachment 90997 [details]
The XF86Config file

This is the XF86Config file in case that helps

>It has been suggested that this is sub pixel rendering for a laptop but when i
>looked at the Xftconfig file it seemed to be commented out.

Just FYI - XftConfig is obsolete and has not been used since Red Hat Linux 7.3.

I am not able to observe the problem you describe on any system that I have
Red Hat Linux 9 installed on.  I have no LCD or DVI panel hardware available
either however, so if it is LCD specific and due to subpixel rendering, I
will not be able to reproduce it in any case.

What specific applications does this occur in?  Please provide several
file attached screenshots, so I can see if the problem is visible on
my own CRT monitor using the images displayed on yours.  The xmag image
does show colored edges, but that doesn't illustrate what is visible to
the eye on an actual display.  In particular, subpixel rendering does in
fact have pixels which have color such as this when magnified, however
what is visible to the human eye when proper subpixel rendering is working,
is higher horizontal or vertical resolution with much nicer fonts.

I am CC'ing Owen for his opinion on this issue as he is the local font
rendering expert, and maintains fontconfig, freetype, and pango.

re: Xftconfig, yeah sorry my mistake, i meant the fonts.conf file.

This seems to be happening in all apps which use anti aliased fonts, Openbox
menus show it, gnome-terminal shows it and page display of galeon shows it
although the application's menuing doesn't. Also i am running eclipse on a
different machine with x forwarding and i'm not getting the same effect possible
pointing to the fonts server?

i'll attach screen shots.

Thanks for the help.

Created attachment 90998 [details]
Showing haloing

this shows up a little of the effect but the nature of jpegs has lowered this a
little. If you see the word "looked" you can see the effect on the inside of
the o's. The white haloing can be ignored where its seen as thats just the jpeg
messing things up.

Created attachment 90999 [details]
Two different apps on two different machines

The top app is the local machines gnome-terminal the second one is eclipse
running on a different machine with x forwarding. Again jpeg's at minimal
compression have lowered the clarity of this :(

Created attachment 91000 [details]
Openbox Menu showing haloing

This is where it shows up the clearest presumably due to the grey background.
Ever watch a tv where the colours were off? Thats what its like to look at :)

Created attachment 91001 [details]
PNG version of the diffApps

This shows the top apps on two different X servers.

JPG compression is lossy no matter how high quality you set it, so by using
jpg for screenshots you are introducing pixel colour modification to what is
on your screen no matter how slight it is.

Any time you're trying to illustrate on screen graphical problems like
this, it is critical to make screenshots with non-lossy compression,
preferably PNG images.  Also note that converting a JPG to a PNG after the
fact also results in corrupt images since they were once lossy jpgs and
there is no way to add back what was lost when the jpg was created.

Please attach brand new PNG images showing the problems.

Thanks

Created attachment 91002 [details]
a galeon screenshot 

showing halo on normal antialiased text but not on normal text (applications's
gui).

Ok, I am viewing your PNG images on a CRT monitor, and I can indeed see
red and blue halo effects at my standard resolution of 1600x1200x24
on the fonts as you describe.  I've changed my monitor resolution to
640x480 with the numpad, and the haloing is much more obvious.

If one were to use subpixel rendering while using a CRT display, one might
see weird effects like this as subpixel rendering should only be used on
LCD panels, and the proper orientation should be chosen by the user.

With my default installation, I do not observe these effects in these
applications, so my suspicion is that your font configuration of subpixel
rendering is incorrect.

My recommendation is to disable subpixel rendering in the font configuration
tool.  If that doesn't change things, disable antialiasing.

Owen: any comments?

Another suggestion, is to put on a pair of 3D glasses.  The fonts will
jump right out of the page at you in true 3D font-o-vision.  No charge
for the extra feature.

well unfortunately i can't seem to find my 3d glasses right now but i'll have a
look at home later ;)

As far as i can see sub pixel rendering is disabled in the fonts.conf file i
attached earlier.

redhat-config-xfree86 has no option as far as i can see to confirm this though.

And the subpixel rendering was what was first suggested by keithp but it seems
to be commented out.

redhat-config-xfree86 is for configuring X.  It does not configure fonts,
because fontconfig is not X specific.  There is a font preferences
application in the GNOME and KDE menus.  Use that for configuring this
stuff.

ok i've checked an its on best smoothing not subpixel rendering.

The images clearly show subpixel smoothing turned on; to explain
this would require more information about your machine then
I have available.

To start with:

Is this a fresh install of Red Hat 9?
Are you running GNOME?
Can you provide the attach of xrdb -q?
If you create a new user, does the problem occur for that user?

Is this a fresh install of Red Hat 9?
Yes.
Are you running GNOME?
openbox is what I use but gnome libs are available. I can run it without
problems as the other user.
Can you provide the attach of xrdb -q?
As the new user I get :
Xcursor.size:   24
Xcursor.theme:  Bluecurve
Xcursor.theme_core:     true
Xft.antialias:  1
Xft.dpi:        96.000000
Xft.hinting:    1
Xft.hintstyle:  hintmedium
Xft.rgba:       none

I'll post the results of same as other user in a minute when i log back in.

If you create a new user, does the problem occur for that user?
Doesn't seem to. :(

There was a .fonts.conf file in my home dir with what looked like sub pixel
rendering code in it but when renamed and x server started it looked the same.

I'll try again now.

Xft.dpi:        96
Xft.hinting:    true
Xft.hintstyle:  hintmedium
                                                        
is the output as the original user.
                                                                                
Still the same.

Thanks again.

So, you are saying that the problem occurs both in GNOME and
non-GNOME (openbox)?

Are you _sure_ you succesfully moved your ~/.fonts.conf out of
the way and you have no local customizations in /etc/fonts/fonts.conf
or /etc/fonts/local.conf?

The error doesn't occur in gnome as any user as far as i can see. but it does
occur in gnome apps (gnome-terminal being one example) under openbox.

[doc@greyskull doc]$ ls -al | grep fonts
-rw-rw-r--    1 doc      doc         39817 Apr  8 19:08 .fonts.cache-1
-rw-rw-r--    1 doc      doc           191 Apr  5 22:28 .fonts.conf.bak
-rw-r--r--    1 root     root         9832 Apr  9  2003 fonts.conf.bak

Those are the only fonts files i have in my home dir.

/etc/fonts/local.conf doesn't exist and i haven't changed /etc/fonts/fonts.conf.
(what i attached earlier is what i'm using)

Thanks
Dave

Well, one possibility is that openbox is simply turning on sub-pixel
antialiasing. GTK+ uses the "XSETTINGS" protocol for getting settings
from the environment in GNOME and other window managers or desktop
environments can also provide settings via XSETTINGS (I know that
Rox does, for example.)

The way to check this is to try logging in under KDE or in the
failsafe session, and see if the problem occurs there; if
the problem only occurs under OpenBox, then it's an openbox
issue and you should take it up with the authors there.

Tried failsafe and the problem was there too.

I'll have a look at openbox and get in contact with the openbox developers and
see if there's anything that can be done. Will post back here for anyone else
who's having the same problem.

Thanks Again
Dave

If the problem occurs in failsafe without openbox running, then it
isn't an openbox issue.

I'm pretty much clueless as to what it _could_ be though. I certainly
haven't heard of any reports like this from anyone else.

If there is a bug on our plate here, I have no idea what it would be either.
I haven't heard any reports like this from any other users yet however, and
it is something annoying enough that if many users experienced it we would
almost certainly have numerous bug reports, or have at least heard of it
before so I remain unconvinced that this is not just a local problem on one
machine, either due to user customization, or some other issue that is
user imposed.

Since it is unclear what the problem is, I will leave this bug report open
for now and wait to see what else turns up.

Moving back to XFree86, since 4suite was clearly accidental.
I suspect that if it is related to anything that Red Hat ships,
it's not actually something in the XFree86 package, but rather
GTK+, fontconfig, or maybe xinitrc, but since the problem shows
up as Xft rendering wrong, I'll leave it on XFree86 for now.

Created attachment 91045 [details]
Gnome terminal

Halos visible around text in terminal.

Created attachment 91046 [details]
Screenshot of Mozilla

Halos are clearly visible around the text in web page.	I have not been able to
eliminate these, even if I change the subpixel order.

There is no context for the last two screenshots, but you do understand,
right, that if you go into the GNOME font properties dialog and
set the smoothing type to "subpixel smoothing (LCDs)", then you will
get such "halos"? - that's just how subpixel smoothing works.

(Changing the subpixel order is not something you usually want to
do ... the default is right for 99.9% of LCD panels.)

I can confirm halo's on text in KDE (all applications) but not GNOME.
Fresh install of RHL 9. I'm using flat panel (DVI) monitor.
/etc/fonts/fonts.conf shows subpixel commented out, .fonts.conf is empty, and
fontconfig in KDE shows that subpixel is off. I tried turning subpixel smoothing
on, then off - but get no difference.

Sorry about not describing further...my bad.

I have configured my fonts the same way I had them configured in Red Hat 8.0, so
I thought I would end up with the same, clean font rendering.  However, I have
been experiencing the same problems described above: Halos around text.  I am
sure that I have not done anything different (even my XFree86 config file has
the same options for my nVidia 2 Go card as it did in RH 8.0).

Case in point: the log in screen looks something awful when I type in my
username.  The text has a very visible blue/green halo; it does not appear black
at all.

There is nothing wrong with my LCD display (Toshiab Satellite 3000).  My font
config is okay too.  Something is wrong with the way RH 9 is rendering the fonts
on the display.


Here's the output of xrdb -q:

Xcursor.size:   24
Xcursor.theme:  Bluecurve
Xcursor.theme_core:     true
Xft.antialias:  1
Xft.dpi:        91.000000
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.rgba:       vrgb

I reinstalled RH9 today because of problems I was experiencing with Mozilla and
OpenOffice.org (looks okay so far).

I noticed immediately after the install that there were no halos around the
text.  The login screen looked okay too, which before the reinstall looked
horrible because of the halos.

I then installed the nVidia drivers for my nVidia 2 Go, and the halos were back.
 I'm starting to think that the halos are a nVidia problem, and NOT a Red Hat
Linux problem.

What graphics cards/chipsets are you guys using or testing with?

nvidia GeForce 2 Go was not supported in Red Hat Linux 8.0.  Red Hat also
does not support proprietary 3rd party modules, so any problem you
encounter while using 3rd party modules which is not reproduceable on
a stock red hat Linux system using our supported drivers, is not something
supported by us, and you should contact your driver supplier for technical
support and troubleshooting assistance.

What this problem really boils down to is that if we can not reproduce the
problem on a local system, then it is not going to be considered a bug, or
at least not one that we can do anything about.  Someone who can reproduce
the problem, is going to have to debug the problem right down to it's core
cause and then provide explicit details as to what is going wrong and where.

I'm pretty sure it is not going to end up being an XFree86 problem, and
so I'm not inclined to look into the problem until someone can convince
me otherwise.  I remain convinced this is either a problem with software
installed on the system which we do not provide nor support, or it is an
end user configuration problem.

It's quite interesting that installating and removing the nVidia
drivers changes the behavior here .... I don't see why this would
be the case, since the subpixel behavior is completely done in
the libraries on the client side rather than in the server.

I wonder if the nVidia driver package replaces or overrides any
of the X libraries.

(With three separate reports, I'd like to keep this open until
we have an exact diagnosis of under what circumstances this occurs.
It's not obviously something that would occur as the result of
a driver bug.)

Well, uinstalling the nvidia binary drivers definitely disappear when I revert
back to the "nv" driver in my XF86Config file.  I uninstalled them over the
weekend, and the halos just weren't there anymore.  Reinstalling them, and
changing the XF86Config file to load the "nvidia" driver instead causes the
halos to come back.

I've tested the nvidia binary driver with different options, and even with no
options enabled in the config file, but the result is the same: Halos are
clearly visible (e.g. on the login screen).

Web pages terminal windows don't look so bad anymore, but I toss that up to a
combination of me becoming used to it and changing the font config a little. 
The halos are still there, though.

I somehow missed the fact that you are using Nvidia's binary drivers the
first passes through this bug report.  We do not support Nvidia's binary
drivers, and the problem seems to only occur when people are using Nvidia's
binary drivers, so I conclude there is a bug in their drivers.  You should
report this problem to Nvidia.

Closing as NOTABUG as it is not reproduceable on any system here and hasn't
been reported by anyone using supported software.

OK, I discussed this with Keith Packard - the reason that there
is a dependency on nv/nvidia is that in the absence of other
configuration, the server turns on subpixel smoothing if it detects
it is running on a digital-flat-panel display.

Most likely, the 'nvidia' driver reports a digital flat-panel display
while the 'nv' driver doesn't.

For those people *not* running GNOME and for the GDM greeter, the way 
to disable the RGBA is to add:

 Xft.rgba: none

to /etc/X11/Xresources or ~/.Xresources.

Kanwar - it looks like that earlier in the discussion when
you posted the screenshots of GNOME, you had simply subpixel
smoothing on in your GNOME configuration. Since you had:

 Xft.rgba: vrgb

Is wrong for virtually all displays, if you are still using
that use, you should go into the Details page of gnome-font-properties
and change "Subpixel order" to RGB.

Whether RGB hinting is on at all _within GNOME_ should be controllable
from the main page of gnome-font-properties.

I haven't used the nvidia binary only drivers for a few days now.  I was
expecting to see that the halo problem would disappear, just like I said it did
in my previous messages.  However, I've noticed that halos are still present,
but they are not as prevalent as they were with the nvidia binary drivers.

So, what's the problem now?

See comment 37 for a full explanation of the problem, and how
to change your configuration to force subpixel antialiasing
off.

I don't know what you mean by "not as prevalant" - only in
a few apps? 

Sorry, about the reassignment, hit the wrong button.

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

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

Yep, comment 37 solves the problem nicely. Can it somehow be made the
default setting? I guess more and more people are using LCD over DVI,
so they shouldn't bump into this problem. I guess fixing
/etc/fonts/local.conf would be enough.

RHL 9 is no longer supported.  Setting bug to "WONTFIX"