Just got the latest rpm updates for fedora core 5 and new dejavu fonts showed up: dejavu-fonts-makedefault-2.9.0-1.fc5 dejavu-fonts-2.9.0-1.fc5 dejavu-fonts-experimental-2.9.0-1.fc5 The lower case t appears to have bad problems with being positioned too far to the left in its bounding box I'll attach a screenshot from text on this bug entry page to demonstrate.
Created attachment 6779 [details] xmag screenshot Every place a 't' shows up in serif, it is jammed against the letter to the left like this.
Could you post a screenshot with subpixel hinting disabled? I wonder if the fact that you have the cleartype patch applied is related to the problem. But maybe this is just yet another autohinter problem.
Created attachment 6782 [details] smoothing and hinting turned off I brought up gnome-font-properties and went to the Details... dialog and turned off both smoothing and hinting, and my screen fonts certainly look different, but the 't' is still crammed way over to the left as you can see in this shot of this busgilla description from the bugzilla web page.
Created attachment 6783 [details] her's a bigger sample with more text Here's a shot of my home page with several bad looking instances of 't' squishing circled.
First, to make sure this isn't a problem of font caching, type "fc-cache" (not as root, as normal user) in a terminal window and logout and login again (to be really sure restart X as well). If the problem didn't go away, read on: The font settings in your new screenshot still look exactly the same as your first one, so adjusting the settings didn't take any effect apparently. I'm not familiar with the dialogs in Gnome so I can't help you with that. Or you forgot to restart the application you took the screenshot in (note that in firefox all separate windows must be closed). The screenshot I'm asking for should still have hinting applied, so you shouldn't turn that of. You can also keep antialiasing on (probably called smoothing there). I only want to have a shot without the subpixel hinting (if you zoom in in your screenshot, and see only gray pixels around the letters and no colours, you found the way to do it well). I hope the Gnome dialogs allow you to set specifically that though (if you have KDE installed, you can set it in KControl). The only other alternative other than that is to edit your fonts.conf file. If you do that you should have these lines in your ~/.fonts.conf: <match target="font" > <edit mode="assign" name="hinting" > <bool>true</bool> </edit> </match> <match target="font" > <edit mode="assign" name="hintstyle" > <const>hintfull</const> </edit> </match> <match target="font" > <edit mode="assign" name="rgba" > <const>none</const> </edit> </match> I really can't get the "t" to look the same on my system either. I tried all combinations of autohinter enabled/disabled and subpixel enabled/disabled, and the "t" always has the horizontal bar extending to the left of the vertical bar (like in the smaller font size in the left column of your thirds screenshot). The fact that this also suddenly appears with the 2.9 is also very strange, because there were no changes made to it at all. Did you update other packages as well, like FreeType ?
Running fc-cache and restarting X makes no difference. I cut & pasted the .font.conf file from the text above, and when I ran fc-cache again after that, it says: Fontconfig error: "~/.fonts.conf", line 6: junk after document element I don't see any junk, so I'm not sure what it is complaining about. Here's my recent updates: Aug 31 07:05:41 (yumex) Updated: slang.i386 2.0.6-1.fc5 Aug 31 07:05:42 (yumex) Updated: slang-devel.i386 2.0.6-1.fc5 Aug 31 07:05:42 (yumex) Updated: anacron.i386 2.3-39.fc5 Aug 31 07:05:45 (yumex) Updated: php-pear.noarch 1:1.4.9-1.2 Everything looked fine yesterday. Sep 01 07:10:04 (yumex) Updated: dejavu-fonts.noarch 2.9.0-1.fc5 Sep 01 07:10:32 (yumex) Updated: parted.i386 1.7.1-15.fc5 Sep 01 07:10:33 (yumex) Updated: qtparted.i386 0.4.5-9.fc5 Sep 01 07:10:36 (yumex) Updated: dejavu-fonts-experimental.noarch 2.9.0-1.fc5 Sep 01 07:10:37 (yumex) Updated: dejavu-fonts-makedefault.noarch 2.9.0-1.fc5 After the above chunk of updates, I noticed the font problems. Sep 01 10:38:39 (yumex) Updated: mkinitrd.i386 5.0.32-2 Sep 01 10:38:43 (yumex) Updated: enscript.i386 1.6.4-3.fc5 I also see someone has just started a thread in the fedora-list mailing list about how the fonts look horrible after he just updated :-). I should mention I am not running KDE or GNOME under normal circumstances. Just an fvwm window manager with a few apps up (like emacs, xterm, and firefox) so whatever voo-doo the different GNOME and KDE font controls do isn't normally active. I'm getting the vanilla default behavior for font rendering (until I start running gnome tools to fiddle with things). I'll go see if I can switch to a KDE session briefly and see what results I get after fiddling the kde control panel.
Created attachment 6784 [details] xmag of fonts under KDE How strange - under KDE, things look much better (hopefully I don't have to point out it is a bad idea to have fonts that only look good under KDE :-).
Actually, it appears as though the .fonts.conf file works even without KDE and even with the error message fc-cache gives. When I went back to my plain fvwm environment, the fonts look much better with the .fonts.conf file, so it is the default font rendering that makes them look horrible. (I swapped out .fonts.conf and the horrible stuff came back, swapped it back in, and it went away).
(In reply to comment #6) > Running fc-cache and restarting X makes no difference. > > I cut & pasted the .font.conf file from the text above, and when > I ran fc-cache again after that, it says: > > Fontconfig error: "~/.fonts.conf", line 6: junk after document element > > I don't see any junk, so I'm not sure what it is complaining about. yeah, my bad, I should have been more specific, you have to make sure that the part I mentioned above is put between the <fontconfig> and </fontconfig> tags. That may solve the fontconfig error.
Created attachment 6786 [details] Same test under Fedora Devel Seems ok in rawhide (dejavu 2.9.0 from FE, fc-cache -r before testing)
The "official" FE i386 dejavu packages are available at http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386 for those wanting to test
>Seems ok in rawhide (dejavu 2.9.0 from FE, fc-cache -r before testing) Ah, but what happens if you create a new user with no ~/.font.conf file and using something like a twm session rather than KDE or GNOME? What kind of default font rendering do you get without the extra stuff KDE and GNOME inject into the equation with all the resources they load into the xserver and daemons they run to tweak thing? That's the kind of environment where I see horrible font rendering.
(In reply to comment #0) > Just got the latest rpm updates for fedora core 5 and new dejavu fonts > showed up [...] > The lower case t appears to have bad problems with being positioned too > far to the left in its bounding box Tom: can you try to replace the rpm-provided TrueType files with the pre-build versions in : http://prdownloads.sourceforge.net/dejavu/dejavu-ttf-2.9.tar.gz?download ? That would help pinpoint if the problem is in the Fedora Extras build stack or somewhere else (Fedora Core rendering stack or DejaVu source files)
Also, could you try out if Bitstream Vera Serif has the problem as well on your system? The screenshots posted here that don't have the problem don't have subpixel hinting, so it's likely a problem related to that. Do you experience this problem in Firefox only, or do other programs have the same problem? Test something like Gedit and Konqueror.
Some interesting results with other apps: In gedit, if I force it to use what its font selector calls DejaVu Serif Book, I see the same problem with the 't' as firefox has. I also see this message on stderr where I started gedit: sys:1: PangoWarning: Error loading GPOS table 4097 Still in gedit, if I tell it to use Bitstream Vera Serif Roman I also see the problem with the 't', but I don't see an error come out. Weirdly, if I try oowriter, the text looks fine, I don't see the error with the 't' (but perhaps oowriter digs up the gnome font settings from wherever they are stashed - I never know how this stuff works). I'll try the fonts from sourceforge as soon as I figure out how to install them from the tar file :-).
(In reply to comment #15) > I'll try the fonts from sourceforge as soon as I figure out how to install > them from the tar file :-). Copy them to your ~/.fonts directory with Nautilus.
Started a KCD session and ran the font installer in admin mode to make sure the new font files were really installed on a system-wide basis, and I still see the problem with the 't' unless I put back the ~/.fonts.conf file (which makes things look fine).
After doing all this, I notice there is a kfontinst process using 100% of the cpu that has accumulated 6 minutes of cpu time so far. I think I'll reboot just to get everything back to a known state :-).
One last piece of info: I tried konqueror on my home page, and explicitly configured it to use dejavu serif as the default font, and it looks fine rendering my homepage. Right next to it at the same time, firefox has the problem with the 't', so what I'm concluding is that font rendering is far too mysterious to understand :-).
One more data point - if I run this command to look at my home page: MOZ_DISABLE_PANGO=1 firefox The the problems with the 't' don't show up, so it looks like the default rendering by pango is the problem. The pango rpm's on my system are the latest FC5 updates: pango-1.12.3-1 pango-devel-1.12.3-1
cleaning up
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.