Description of problem: After updating to the latest FreeType build for which the bytecode interpreter has been enabled, fonts are rendered with uneven quality. The system font used e.g. for button labels is very thin now and certain popular web fonts (e.g. Verdana) are rendered surprisingly poorly. Look at the four attached screenshots which demonstrate the various combinations for which the bytecode interpreter is enabled (disabled) and webcore fonts are installed (removed). Version-Release number of selected component (if applicable): freetype-2.4.4-3.fc15 How reproducible: Always. Steps to Reproduce: 1. Launch firefox. 2. Open http://www.bbc.co.uk . Actual results: Partially poor rendering depending on whether the bytecode interpreter is enabled or not. Expected results: Acceptable rendering quality throughout all font families. Additional info: Reverting to freetype-2.4.4-2.fc15 restores globally good font rendering.
Created attachment 479866 [details] Screenshot of http://www.bbc.co.uk with system fonts and bytecode interpreter
Created attachment 479869 [details] Screenshot of http://www.bbc.co.uk with web core fonts and bytecode interpreter
Created attachment 479870 [details] creenshot of http://www.bbc.co.uk with system fonts and -no- bytecode interpreter
Created attachment 479871 [details] Screenshot of http://www.bbc.co.uk with web core fonts and -no- bytecode interpreter
Hmmm, are you sure you aren't mixing up the system fonts vs. web core fonts screenshots? So we have 2 separate issues there: * re DejaVu, I know that the font looks very different with and without the hinting bytecode. As a long-time maintainer of freetype-freeworld, I'm well aware of this problem. The thing is, some people, and that includes the upstream developers of DejaVu, actually LIKE the rendering with the bytecode, and in fact DejaVu upstream recommends enabling the BCI for their fonts. I used to disable the BCI for the DejaVu family in my freetype-freeworld packaging because of complaints such as yours, but then I got complaints about it being disabled (see e.g. https://bugzilla.rpmfusion.org/show_bug.cgi?id=198). Then I reenabled it and got at least one complaint about it being enabled. You just cannot please everyone… It is possible for you as a user to disable the BCI for DejaVu using a config file like this: http://cvs.rpmfusion.org/viewvc/rpms/freetype-freeworld/F-12/99-DejaVu-autohinter-only.conf?revision=1.1&root=free&view=markup There have been complaints to DejaVu upstream about the discrepancy, but they say this is all by design. * re Verdana, I think we need to figure out whether the rendering is as intended by the font designers (as in Deja Vu's case) or whether there's a bug. (It might be that "freetype uses hinting bytecode even at sizes so small that the font wants to be rendered without antialiasing" issue which is already reported somewhere.) It can be worked around with a per-font policy using a config file similar to the above, but really, we want the BCI fixed instead.
I guess that, if the Verdana issue is really a size issue (unfortunately, I can't find the report for that issue anymore), a possible solution would be to check the font's tables for the minimum supported antialiasing size (which is normally the minimum size the hinting bytecode was tested with), and if the requested size is smaller than that, force autohinting (similar to how the auto-autohint patch handles fonts with no bytecode at all). On the other hand, that may be overly conservative.
(In reply to comment #5) No, the screenshots are labeled correctly. In attachment 479866 [details] and in attachment 479870 [details], the text body is rendered using a rather ugly font, some DejaVu variant, I guess. Note the (Fedora) font used in the address bar which is very slim when the bytecode interpreter is enabled. Unfortunately, the new user interface does not allow in a straightforward manner to change hinting between "slight" and "medium" which could be used to improve the rendering. Freetype rendering of web core and Luxi fonts is sort of an eternal story as underlined by bug 198082 which I reported back in 2006.
I don't think that first screenshot really shows the body text with the bytecode interpreter enabled. It's rendered exactly the same as the third screenshot. Anyway, there are many different ways to handle hinting, and if people claim about bad rendering of Verdana with BCI enabled, it's because Verdana was hinted without anti-aliasing in mind. With anti-aliasing some artifacts are shown, especially in the diagonals which can sometimes even become almost invisible. In DejaVu we have hinting designed for anti-aliasing (DejaVu will in its turn be rendered worse if you disable anti-aliasing). Next, there's also a minimum font size (defined in the tables in the font itself) that says below which no more hinting should be applied at all (this is usually a number like 8 or 9 ppem). The reason why we from DejaVu recommend the bytecode interpreter is because we can actually control that. We get a large amount of bugs reported which are caused by the autohinter, and each time we have to say "sorry, there's nothing we can do to fix this" (it's actually the first thing I look at if bad rendering is reported: does this user use the autohinter?). And an autohinter will always be worse than BCI hinting because the autohinter is unable to keep everything consistent, and I'd say consistency is a feature you really want to have in a font...
(In reply to comment #8) > I don't think that first screenshot really shows the body text with the > bytecode interpreter enabled. It's rendered exactly the same as the third > screenshot. Maybe you have a second look and convince yourself first that there exist 2 x 2 = 4 combinations (with and w/o BCI; with and w/o web core fonts) which correspond to the 4 (different (!)) attached screenshots. If you wonder that the text body of screenshots 1 and 3 look the same then you should also look at the URL bar which undeniably shows a clear difference in the way the default sans serif text is rendered. I can hardly imagine that while BCI is used for rendering GTK widgets it is not by Xulrunner. As a matter of fact, button labels in case 3 without active bytecode interpreter looks clearly better (in my opinion). Case 1 reminds me of older Ubuntu releases which always suffered from too skinny characters.
(In reply to comment #9) > Maybe you have a second look and convince yourself first that there exist 2 x 2 > = 4 combinations (with and w/o BCI; with and w/o web core fonts) which > correspond to the 4 (different (!)) attached screenshots. I didn't argue that. I just said that the body text in #1 clearly does not show a font which is using the BCI, for whatever reason that may be. I'm just clearing this out since it's 90% of the screenshot. > If you wonder that > the text body of screenshots 1 and 3 look the same then you should also look at > the URL bar which undeniably shows a clear difference in the way the default > sans serif text is rendered. I also did not argue that. > I can hardly imagine that while BCI is used for > rendering GTK widgets it is not by Xulrunner. It's much harder to imagine that the autohinter would come up with exactly the same rendering for a font as when it's using the BCI. My guess is that with all the fallback rules the font chosen to render the body is FreeSans, which has no hinting instructions at all, so freetype falls back to autohinting in screenshot 1. > As a matter of fact, button > labels in case 3 without active bytecode interpreter looks clearly better (in > my opinion). Case 1 reminds me of older Ubuntu releases which always suffered > from too skinny characters. Well, the keyword in that is "in my opinion". Let me tell you that the GUI font in #1 (DejaVu) is how font developers designed it to look like. None of the screenshots is showing how Verdana was designed to look like. How you want your fonts to look on your screen is totally up to you to decide (I cannot stand bitmapped fonts so I chose to have Verdana anti-aliased myself). I'm only giving the facts here about what the rendering should look like if you want it like the font designers designed it.
Created attachment 480400 [details] Screenshot of http://www.bbc.co.uk rendered by IE8 (Windows XP) (In reply to comment #10) > None of the screenshots is showing how Verdana was designed to look like.
Created attachment 480684 [details] Screenshot of liberation font with bytecode interpreter Part of a web page rendered by firefox. No fonts other than the system default fonts have been installed. Note that the character "u" differs significantly from the other ones. The font seems to belong to the "Liberation" font family.
This one looks like a font bug, it should probably be filed against liberation-fonts.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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