Bug 466369
Created attachment 319944 [details]
a sample of damaged window menus
This I think, is definitely not a babl bug. babl libraries are used in gegl operations which are being used in the latest release of gimp (you only got babl because you updated gimp). Have you tried reverting gimp and removing gegl and babl to see if the problem go away. I would think this is a problem with some GNOME or xorg libraries. BTW, I'm running on latest rawhide too (20081008), and I've not noticed this issue. > This I think, is definitely not a babl bug.
In a sense you are right. Only with babl
and gegl (and all that goes with it) removed
the problem appears to be more subtle and
harder to notice.
Attached is a sample of the same text in
the same scale with "Best shapes" (look at
the letter 'p') and "Best contrast".
So if babl and gegl only aggravate the issue
what should be charged with it? Yes, my
system is right now on 20081008 "level"
too but the problem jumped on me after
20081007 changes. The only other two
packages which would seem to be related
to grafics there were:
xorg-x11-server-common-1.5.1-6.fc10.x86_64
xorg-x11-server-Xorg-1.5.1-6.fc10.x86_64
OTOH maybe earlier I just missed the problem
although it seems to be hard to miss.
Created attachment 319958 [details]
fonts damaged with "Best shapes"
Created attachment 319959 [details]
the same text as above damaged with "Best contrast"
"Subpixel smoothing" gives even worse, substantially, results.
The screenshots suggest that the problem is visible in gnome-terminal which (beneath a slew of intermediary libraries) uses pango for font rendering. Therefore I'll reassign the bug to pango so that its maintainers can examine it closely. > The screenshots suggest that the problem is visible in gnome-terminal
Experiments in gnome-terminal were, in a sense, the easiest
but the same type of damage shows up everywhere. In window
titles, gnome-panel, dialog to set font rendering properties,
you name it.
Further checks are showing me that, in regular font sizes
and if "Monochrome" is not used, distortions would be the
least (to the point that you have to carefuly check for
these) if in "Details" smoothing is set to "Greyscale"
and hinting to "Slight" (with other choices, including
"None", definitely worse). Subpixel ordering does not
seem to matter. Changing "Resolution" may also help
although results do not seem to be stable or predictable.
Switching to "Subpixel smoothing" makes the text essentially
unreadable but this is on CRT and not LCD.
Do these observations provide some hints?
Just to be on the sure side: did you restart your desktop after doing the updates? Problems like this occur when the font caches get messed up. > did you restart your desktop after doing the updates? This is a test installation. For various reasons it was rebooted a number of times in the meantime. > Problems like this occur when the font caches get messed up. OK. Any obvious way to clean up those caches? (In reply to comment #9) > OK. Any obvious way to clean up those caches? Yeah, rebooting should fix all caching problems :-) Perhaps the font files themselves got corrupted? Try to reinstall them (dejavu if I look at the screenschots) if you haven't already. Is this only a few fonts that have this problem or all of them? What about non-GTK applications? A font which shows up in example screenshots is identified in gnome-terminal "Preferences" as "Monospace 11". Not entirely clear from that description if it comes from dejavu or something else. :-) I tried other possibilities like "Luxi Mono" (there are not too many of those) and different sizes. Although mis-rendering changes it never totally goes away with an exception of "MiscFixed" but these look like not hinted and/or shaped fonts. Wait a minute! It appears that "LucidaTypewriter Sans" and "LucidaTypewriter Sans Bold" are also coming fine (or at least problems are so subtle that I missed those :-). rpm -V dejavu-fonts rpm -V liberation-fonts do not lodge any complaints. Just in case I reinstalled both, with dejavu-fonts-experimental added to that list too for a good change, rebooted and, as you can see from an attached picture, troubles are still there. A bit different with "Best shapes" instead of "Best contrast" but not gone. I have to admit that a terminal window looks after that definitely better. Not sure why. Created attachment 320034 [details]
this time shot not from a terminal
Look close at letters like A, W, H, p, n and various others.
Also r in a window title. At least mis-renderings seem
to be consistent through a sample.
If it's not the fonts or the font caches then the next thing to look at would be Freetype... Try to reinstall Freetype (again, restart desktop afterwards to be sure programs use it) and if that doesn't work find the previous version of it and install that. btw, did you test the rendering in a Qt/KDE program? Would be good to rule out GTK or Pango here as well. Created attachment 320048 [details] results with freetype reinstalled > Try to reinstall Freetype Well, with freetype-2.3.7-1.fc10.x86_64 reinstalled, together with devel libraries (and after recovering from the latest gnome-session breakage :-) the situation improved, although I cannot imagine why, to that extent that if I would not look closely for misrenderings I would likely missed that. Look at a letter d in an attached sample. Some other stuff can be find out too. Turning on "Subpixel smoothing" makes and obvious mess. OTOH this version of freetype was installed on August 28th so I had an ample time to notice something amiss. > btw, did you test the rendering in a Qt/KDE program? Not earlier. They are scarce on this test system. I do have k3b. It looked mostly clean with this exception that before freetype reinstallation an upper case D had a bar across - both in "Devices" on a menu and in directory listings window. Right now this bar vanished. I will try to see what will happen with an earlier version of freetype a bit later. Created attachment 320077 [details]
freetype-2.3.6-1.fc10 - "Best shapes"
I may be, possibly, a freetype problem although this is hard to be
sure as all this depends on various appearance settings and
magnifications. Still after reinstalling 2.3.6-1.fc10 either
"Full" hinting or none (other seems to be worse) one has to
look carefuly for a font damage and bumping up a zoom a notch
may give a "clean" terminal window.
Saying that this is how "1" looks like with "Best shapes"
and a default zoom.
Created attachment 320078 [details]
freetype-2.3.6-1.fc10 - "Best contrast"
... and this is "D" with "Best contrast" although otherwise it
is hard to find something misrendered.
Maybe use a freetype version that has the bytecode interpreter enabled (just google) and use (full) hinting with that (or whatever setting you need in Gnome to enable it). Anyway, just giving some ideas, as I have no idea what's wrong. I don't remember anyone reporting problems like that. If KDE/Qt programs doesn't have the problem one would look into Pango or GTK. Do the problems change (slightly or completely) with the same settings after you reboot or do they stay the same? BTW sometimes mangled text display is a symptom of broken xorg graphic driver and has no relation whatsoever with fonts or font libraries > ... mangled text display is a symptom of broken xorg graphic driver I was wondering about that and this sounds now like a more feasible explanation. It is hard to pinpoint those troubles on something like freetype and damage seems to be more elusive that one would expect from errors in just a rendering engine. "Now you see, now you don't" happens all the time with seemingly unconsequential changes. OTOH when a damage is observed then it looks consistent through the same glyph anywhere on a screen. Can that be reconciled with a broken graphic driver? Contrary to comment #17 at least k3b (which is KDE/Qt program) did show font problems - in some circumstances. That it was harder to notice that it could be just fonts used there and/or their sizes. As I noted before LucidaTypewriter turned out to be surprisingly robust with all of this. (In reply to comment #18) > BTW sometimes mangled text display is a symptom of broken xorg graphic driver > and has no relation whatsoever with fonts or font libraries or worse: broken hardware. I had funny things going on as well once when my video card wasn't sitting well enough in its socket. But usually you'd notice other glitches as well apart from just funny looking fonts. > But usually you'd notice other glitches ...
With 'flowers_and_leaves.jpg' for a background it does not
seem likely that I would miss those other glitches.
(In reply to comment #21) > > But usually you'd notice other glitches ... > > With 'flowers_and_leaves.jpg' for a background it does not > seem likely that I would miss those other glitches. Background and fonts do not necessarily share the same cache xorg-side > ... or worse: broken hardware.
I booted on the same machine, only different disk partitions,
Fedora 9. Just to be sure I used the same xorg.conf file
and the same terminal font. Try as I might I cannot find
any misrendered glyphs anywhere. I was changing hinting,
smoothing, rendering type. Nada. Even "Subpixel smoothing"
works without any problems. "Best contrast" or "Best shapes"
look better, but that is about it.
Reboot that to rawhide and I have samples of bad letters
all over the place.
Samples of a similar text attached. In both cases
they were done with "Subpixel smoothing" (not optimal
for that hardware). This is still not bad. The other
times I had such samples on rawhide which were just
not readable. :-)
Created attachment 320127 [details]
a sample from Fedora 9 - "subpixel smoothing"
Created attachment 320128 [details]
a similar text as above on the same hardware but rawhide this time
Created attachment 320606 [details]
another sample - this time xorg-x11-drv-ati-6.9.0-27.fc10.x86_64 driver
With an update to xorg-x11-drv-ati-6.9.0-27.fc10.x86_64 a damage
seems to shift a bit but it does not disappear. On the attached
sample look at "2", "L", "Y" and "s". This is with "Best contrast".
Trying this with "Subpixel smoothing" makes it much worse. Hinting
seems to revert to "Full" does not matter how else I attempt to set it.
If it's a radeon HDxxxx card, could you try with the radeonhd driver? Just curious if it makes a difference. The radeon card in question happens to be "ATI Technologies Inc R300 AD [Radeon 9500 Pro]". It does not work with radeonhd. Documentation says so but just in case I tried and documentation is correct. I am afraid that a damage I am observing shifts. Sometimes it is rather subtle, and I have to search for it, other times it will be blunt "up in your face". For example, after the last round up updates to 20081020 set, which brought a new kernel, mesa packages, xorg-x11-drv-ati, xorg-x11-server-common and xorg-x11-server-Xorg, after a reboot I can see an extra pixel left of "l" and something eaten in "@". Also changing font scaling may change what is wrong or even "fix" everything. So, contrary to the original subject of this report, troubles may started earlier than 20081007 and I simply missed it. I cannot be even sure now how much earlier as on a casual glance everything may look normal. The only thing which remains constant is that if I will boot, on the same machine, either Fedora 9 or Fedora 8 or CentOS 5.2 then I cannot find any traces of misrendered fonts and I really tried. Making "Rendering" into "Monochrome" in "Appearance Preferences" does "fix", in a sense, all described troubles. Created attachment 321081 [details]
sample after 20081021 changes
With 20081021 round of updates, which includes pango, mesa, various xorg-x11
drivers, glibc and kernel the damage appears to be lessened. With "Best contrast" I have to look for it although it is not that difficult to find.
Attatched is some sample (lower case "t") but one can find more with different
glyphs. With "Best shapes" this is much easier and with "Subpixel smoothing"
still blatantly obvious.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping http://lkml.org/lkml/2008/12/3/535 , and a surrounding discussion, could be relevant. Seems to occur on Thinkpad T43 with ATI X300, too. Problem seems to be fixed with xorg-x11-drv-ati-6.9.0-54.fc10, exists with xorg-x11-drv-ati-6.9.0-62.fc10 https://bugzilla.redhat.com/show_bug.cgi?id=476070 Reporter, please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance. As a matter of fact with the latest xorg-x11-drv-ati-6.9.0-62.fc10.x86_64, which showed up in rawhide package today, I do not see anymore that damage which haunted me for such long time. With the previous xorg-x11-drv-ati-6.9.0-61.fc10 I still could observe missing pixels on the right hand side of the bottom arch of "d" or "u", at least in some fonts and some magnifications, but after the latest updates so far I did not find anything amiss. I would be inclined to close that bug if not a comment #33 from Matthias Runge. It may happen also that a damage will return. BTW - what is now a simple way to produce a screen dump? "PrtScr" key does not work anymore as it used to. 'xloadimage -dump ...', even if xloadimage package is installed, does not seem to be able to do that. Created attachment 330294 [details]
rendering issues with uptodate fedora system e.g. xorg-x11-drv-ati-6.9.0-63.fc10
the problem still exists for me too. sometimes its better (like shown in the screenshot) sometimes it is worse, but there is no day without this behaviour. graphics card is:
00:0b.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO]
Jan, could you test the latest build in Koji at : http://koji.fedoraproject.org/koji/packageinfo?packageID=95 ( currently xorg-x11-drv-ati-6.10.0-2.fc10 ) and report. If it still persists, please attach dmesg and /var/log/Xorg.0.log as uncompressed attachments. Thanks :) I tried to check if I still can find some font damage but as long as gnome-settings-daemon refuses to start (see bug 471676) there is not much I can do. Any font property changes, and much more, are just ignored. OTOH, as I noted before, I stopped seeing the problem a while ago. At least nothing blatant like it used to show up. Still others apparently stumbled into the same issue after that. Thank you for the bug report. This particular bug was fixed and a update package was published for download. Please feel free to report any further bugs you find. You can obtain the updated package by typing 'yum update <package>' or using the graphical updater, Software Update. Closing as original reporter confirms it is fixed for him. *** Bug 444890 has been marked as a duplicate of this bug. *** Old issue is back with F-11 http://peter.fedorapeople.org/garbled_fonts.f11.png I just tried to rebuild driver from git at fd.o - while isssue with completely unuseable fonts (See screenshot above) was gone, the other issue with slight font corruption is still here: http://peter.fedorapeople.org/garbled_fonts_yellow_stripes.f11.png Note the yellow noise at the right side of some text. BTW I just tried to start glxgears using driver from F-11 - it just locks my machine (Apple Mac Mini G4). And if I start glxgears using driver from git, then I saw the coppupted colors (already seen before - http://peter.fedorapeople.org/glxgears.png from this ticket https://bugzilla.redhat.com/show_bug.cgi?id=473440 ) I also encountered strange behavior with input fields (such as this one, where I'm writing this text) - sometimes they are completely filled by black, and I need to overlap them with some other window (xterm) to make them visible again. On my laptop (http://www.smolts.org/client/show/pub_d3521300-de3d-40ee-be30-5c99bb593c3b) I see similar problems. From time to time some letters get corrupted (especially in Firefox, Emacs does not show this problem). After some time they are gone, and then come back again. This is not on powerpc, but on x86_64. Very annoying, any information I can provide to get this fixed? Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] I was asked with "needinfo?(michal)". See my comment 35 and comment 38 respectively from 2008-12-17 and 2009-02-03. These say that I do not see the issue anymore. OTOH there were later reports of the same, or similar, problems on another hardware and that is why this report remains open. I am afraid that I am unable to comment on that. (In reply to comment #43) > On my laptop > (http://www.smolts.org/client/show/pub_d3521300-de3d-40ee-be30-5c99bb593c3b) I > see similar problems. From time to time some letters get corrupted (especially > in Firefox, Emacs does not show this problem). After some time they are gone, > and then come back again. This is not on powerpc, but on x86_64. Very annoying, > any information I can provide to get this fixed? Version of the xorg-x11-drv-ati package please. (In reply to comment #42) > I just tried to rebuild driver from git at fd.o - while isssue with completely > unuseable fonts (See screenshot above) was gone, the other issue with slight > font corruption is still here: Please, don't do it: a) Xorg drivers are tightly connected to kernel these days, so you should expect quite high level of brokeness with incorrect kernel (for more explanation see http://thread.gmane.org/gmane.linux.redhat.fedora.devel/121773/). b) we have some patches in our drivers, so result of your testing are almost worthless for us, because we don't know if it is broken/working because of our patches existing/missing in your driver. I'm using xorg-x11-drv-ati-6.12.2-14.fc11.x86_64 and haven't seen the font corruptions for a while. Elements like check boxes and radio selectors are still corrupted from time to time though. This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 319943 [details] a sample of mis-rendered fonts in a terminal window Description of problem: After installing a series of updates from 20081007 font rendering become seriously damaged. Depending on a resolution glyph images are missing pixels, or have additional ones. One can also find distorted shapes in some circumstances. The damage will be different depending on a font magnification (ctrl with '+' or '-' in a terminal window) and when zoomed enough to _really_ big sizes it eventually disappears. That damage can be seriously reduced if in "Appearance Preferences" for fonts I will pick up "Best contrast", as opposed to "Best shapes", and really disappears when I will use "Monochrome" but terminal fonts become then very thin and "spidery". Attached are some screenshot fragments to illustrate the issue. Version-Release number of selected component (if applicable): babl-0.0.22-1.fc10.x86_64 How reproducible: Happens all the time Additional info: I cannot be really sure that babl is responsible but the problem was not showing up before 20081007 and after reviewing a list of what was changed in this series with babl beeing "pixel format conversion library" that looked like the most likely candidate.