Description of problem: Various fonts are rendered poorly compared to "freetype-2.1.10-6". In particular, the default font "Luxi" is more condensed and even changing the hinting from medium to slight leads to an appearance which is quite different from the usual one. Often characters are blurred, e.g. in the case of the "Verdana" character set used in the attached screenshot. Version-Release number of selected component (if applicable): freetype-2.2.1-2 How reproducible: Always. Steps to Reproduce: 1. Update to "freetype-2.2.1-2" Actual results: Font rendering of e.g. "Luxi" and "Verdana" fonts is poor. In the case of the latter, it remains poor rgardless of the font preferences chosen. Expected results: Font rendering should be as good as before. Additional info: By downgrading to "freetype-2.1.10-6", the usual aspect can be stored.
Created attachment 132124 [details] Font rendering comparison between freetype 2.1.10 and 2.2.1
I have seen the same regression for current "Ubuntu 6.10" development tree "Edgy Eft" (2006-08-06).
Issue still present for "freetype-2.1.10-6".
Presumably, Joachim meant to indicate a 2.2 version in the last message. I also see degraded font rendering in "freetype-2.2.1-10.fc6", as compared to 2.1. I only see a difference between the two if I select "best shapes" in the GNOME font preferences. Any other font rendering setting produced results that are identical, as best as I can tell. To reproduce: * Install FC6 * Select "Luxi Mono" as the fixed width font. DejaVu renders differently, too, but Luxi demonstrates the difference more clearly. * copy libfreetype.so* from an FC5 host to the FC6 install in ~/freetype * Launch two new terminals: $ LD_LIBRARY_PATH=/home/gordon/freetype gnome-terminal --disable-factory & $ gnome-terminal --disable-factory If you look at the shape of a lowercase "g" (Luxi Mono) in each terminal, you can see that both loops of the letter are very round as rendered by freetype 2.1, but squished in 2.2. Lowercase "d" also renders much more round in 2.1, and "$" is much more clear.
Created attachment 142224 [details] screenshot of $ vs. S in 3 pt sizes
lost the comments to previous attachment (comment #5) this shows a screenshot of Konsole on FC6 with 9pt, 10pt, 11pt font size for the default font and a magnification of the relevant part with xmag. It demonstrates that the dollar symbol is nearly indistinguishable from the upper case letter S at 10pt font size, while 9pt and 11pt are reasonable. Cheers T.
Created attachment 145893 [details] Screenshot for "freetype-2.1.10" no hinting "Luxi" font shapes are rendered as in "FC5" and earlier but look fuzzier because no hinting is used.
Created attachment 145894 [details] Screenshot for "freetype-2.1.10" w/slight hinting "Luxi" font shapes are rendered as in "FC5" and earlier and are in sharp contrast with the current rendering shown below.
Created attachment 145895 [details] Screenshot for "freetype-2.1.10" w/medium hinting "Luxi" font shapes are rendered as in "FC5" and earlier but look narrower and are thinner as medium hinting is used.
Created attachment 145896 [details] Screenshot for "freetype-2.3.0" w/no hinting "Luxi" font shapes are rendered as in "FC5" and earlier but look fuzzier because no hinting is used. Here, no difference compared to version 2.1.0.
Created attachment 145897 [details] Screenshot for "freetype-2.3.0" w/slight hinting "Luxi" font shapes are rendered very differently compared to "FC5" and earlier. The proportions look a bit weird, and the rendering looks somehow uneven. Characters such as "g" are rendered incorrectly.
Created attachment 145899 [details] Screenshot for "freetype-2.3.0" w/medium hinting "Luxi" font shapes are rendered as in "FC5" and earlier but they look narrower and are thinner as medium hinting is used. The result is apparently identical to "2.1.0" but unlike the "common" aspect I was used to from "FC5" and earlier. Summary: In order to obtain a satisfactory rendering of "Luxi" fonts for "FC" development, it is necessary to downgrade to "freetype-2.1.0" and to set the hinting to "slight". Fortunately, this downgrade is still possible because the library major version has not changed yet. Otherwise, one would have to rebuild packages which depend on the "freetype" package. However, this situation is unlikely to remain so forever, so the issue should be settled for current "freetype-2.3.0". Btw, since adding "/usr/share/X11/fonts/TTF" to the "fontconfig" path in release "2.4.2-2", things have even got more complicated. Now, even when "freetype-2.1.0" is installed, the rendering output is poor unless one -uninstalls- "xorg-x11-fonts-truetype" which means that the "Type1" and the "TrueType" versions of the "Luxi" fonts are rendered differently. Is this supposed to be like this?
I meant to write "freetype-2.1.10" instead of "freetype-2.1.0".
Umm. Not good. I'll look into removing /usr/share/X11/fonts/TTF. How is it with freetype-2.3.0?
To summarize this bug: "slight hinting" mode has regressed. Before: attachment 145894 [details] After: attachment 145897 [details]
The "after" shot is probably with truetype luxi, while before is with type1 luxi, right? In that case, can you attach an after shot with type1 luxi?
All the screenshots have been obtained -after- uninstalling the "xorg-x11-fonts-truetype-7.1-3.fc7" package. I should also note that compared to stock "FC6/FC devel", I have changed the system font defaults back to "Luxi" instead of "DejaVu" which I find much too wide for the default sans serif fonts and not suitable regarding the monospace fonts, e.g. in a "gvim" editor window where now a sans serif font is used by default. I have created to screenshots showing the use of the "ttf" fonts in case of "freetype-2.3.0" [2.1.10 is not different though] in one of them which are attached below.
Created attachment 145973 [details] "Epiphany" screenshot for "freetype-2.3.0" w/"xorg-x11-fonts-truetype" [hinting medium"]
Created attachment 145974 [details] "Epiphany" screenshot for "freetype-2.3.0" w/"xorg-x11-fonts-truetype" [hinting medium"]
Created attachment 145975 [details] "Epiphany" screenshot for "freetype-2.3.0" w/"xorg-x11-fonts-Type1" [hinting medium"]
"Slight" is not an absolute concept, it is relative to something. Yes, freetype has change the meaning of "slight". So what? Glyths do look closer (narrower) to their actual shape, but blurrier. What used to be slight is more like medium now. So what? I say, use medium or full now. This is not a bug in my opinion, freetype developers have every right to change presets. This is a matter of tuning. If we agree that 2.3.0 is an improvement over 2.2.1, push an update ;)
(In reply to comment #21) This bug report is not about an alleged modification of the meaning of hinting mode "slight". My point is that with freetype >= 2.2.1 the rendering of "Luxi" fonts is noticeably deteriorated with respect to version 2.1.10 -regardless- of the hinting mode chosen. The rendering issue for "Verdana" fonts from comment #1 has clearly improved though. Moreover, version 2.3.0 has already been pushed to "rawhide" which makes me wonder even more .. (?)
The bug is in the eye of the beholder. For example, E, F, G, H, and m have improved and look more even in Luxi Mono with 2.3.0. It is tough to make freetype work for _all_ fonts and sizes. It is easy to find one bad particular bad case. It is unrealistic to treat all special cases separately.
(in reply to #15) Honestly, this looks like a bug. The main reason for my assumption is that the glyph of digit `1' doesn't become smaller while the others do, which looks very ugly to me. Maybe David's attempts to fix other fonts have introduced this regression. In case nothing happens in the near future -- David is normally overloaded with family and work -- please remind him from time to time to look at this issue. And please create a FreeType bug report also!
Any news here? Compared to FC6, F7 and rawhide look rather terrible, at least on a LCD. :/
Created attachment 293079 [details] "Epiphany" screenshot for "freetype-2.1.10" w/Luxi Type1 fonts About one week ago, some update in "rawhide" introduced a change such that regardless of the version of freetype installed and the hinting mode, the output is always the same unsatisfactory one as shown in the attached screenshot. The rendering is uneven and condensed, and it has effectively become impossible to obtain the balanced rendering as obtained by RHL 8-9 and FC 1-5 when using Type1 Luxi fonts. Has there been a change in "GNOME" disabling certain aspects of the font preferences settings?
(In reply to comment #26) The problem was elsewhere: gnome-settings-daemon was broken and did not apply the "slight" hinting setting which gives me the Luxi font rendering familiar from FC <= 5 when using freetype-2.1.10-6 which continues to be my case.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is this bug still present in Fedora 9?
Using a combination of Luxi Type1 and MS core fonts, the issue is still the same: when choosing slight hinting, then Verdana characters are fuzzy, in particular visible in web pages; when choosing medium hinting then Luxi characters are condensed and thin but Verdana characters are crisp. This observation applies to current freetype-2.3.5. Only by downgrading to freetype-2.1.10, I do obtain the rendering quality of FC5 and earlier for which Luxi was the default system font family.
If you use Type 1 Luxi (which I don't have) you might try 2.3.6 for comparison purposes -- I've fixed a small scaling problem in the Type 1 hinter. Two issues: . Don't use 2.3.6 for daily use since it contains a nasty CFF bug. Wait for 2.3.7 which should appear next week. . The fix improves some shapes, but at the same time it can degrade some shapes too. I haven't yet found the reason for it.
Actually, I do not see a change between 2.3.5 and 2.3.6. I have built the libraries both from the pristine source and by updating the Fedora RPM including vendor patches. The font settings in the GNOME font panel are: [Fedora default] rendering: best shapes hinting: medium Subpixel smoothing: none [User customized] rendering: best shapes hinting: slight Subpixel smoothing: none Luxi Type 1 rendering is reasonable for medium hinting. Descenders are shortened and characters are slightly wider than for 2.1.20 but Verdana characters are blurred. Thus, Verdana needs slight hinting to be rendered acceptably but then, Luxi Type 1 characters get really ugly.
Issue still present for the latest F10 Alpha and "rawhide" spins. To summarize: the transition from FreeType 2.1.10 to FreeType 2.2.x and later has brought some regression in the rendering of Type1 fonts, namely of the Luxi family in the present case. For slight hinting, the aspect of Luxi Sans is more ore less equivalent but then Verdana fonts are blurred as seen in the attachment to comment #1. For medium hinting, Luxi Sans characters look condensed and thin, and rendering is uneven. Verdana fonts look ok though. I have updated the freetype RPM to version 2.3.7 on my system, and I have also made trials with BCI hinting and subpixel rendering which can be enabled when building the binary RPM - unfortunately without improvement. This old issue (2006-07) is getting somewhat more urgent as of late, as GTK packages in "rawhide" start using receent API calls e.g to FT_FONT_SIZE introduced in releases later than 2.1.x which results in aborting applications like in the case of system-config-printer and corresponding error messages in .xsession-errors. Up to F9, it was possible to dynamically link against local copies of FreeType 2.1.10, the latest version of the 2.1.x series which was included in FC5 [up to this Fedora release, the Luxi font family was the default one for this distribution, and the rendering quality was excellent both for Luxi and MS fonts]. There appear to be related entries in the FreeType bug data base: https://savannah.nongnu.org/bugs/?12829 (!) https://savannah.nongnu.org/bugs/?19044 https://savannah.nongnu.org/bugs/?23669
Created attachment 314311 [details] FT 02.01.10 screenshot with Luxi Sans/Type1 and Verdana fonts [slight hinting]
Created attachment 314312 [details] FT 02.03.06 screenshot with Luxi Sans/Type1 and Verdana fonts [medium hinting]
Created attachment 314313 [details] FT 02.03.06 screenshot with Luxi Sans/Type1 and Verdana fonts [slight hinting]
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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 351609 [details] FT 02.03.09 screenshot with Luxi Sans/Type1 and Verdana fonts [medium hinting] Verdana font is rendered correctly. However, Luxi sans 10 is condensed and render unevenly. Issue persists for Luxi sans 11 which has the same overall size as default sans 10.
Created attachment 351613 [details] FT 02.03.09 screenshot with Luxi Sans/Type1 and Verdana fonts [slight hinting] Verdana font is blurred. However, Luxi sans 10 is rendered more or less correctly. Note the short descenders of characters like "g" or "p" though.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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