It's cool that the patent expiration lets us enable the bytecode interpreter.
However, there's a severe flaw -- if there's no bytecode, apparently freetype doesn't hint at all.
I use Inconsolata as my terminal font, and it normally looks great. After the update, it got all fuzzy and basically unusable. This is sadly true for a great many very nice fonts.

Upstreaming and getting the issue fixed is a great long-term approach. However, I also think we should revert this change until that is in place, as it significantly degrades the user experience. (Hence the original summary of this issue and its focus on that, rather than on the underlying problem.)
I took a quick look at the source, and src/base/ftobjs.c has a section with a big comment starting "Determine whether we need to auto-hint or not" -- it seems like it's _probably_ no big deal to add the appropriate logic there.
There's also some code in src/truetype/ttobjs.c which decides if a crippled (patent-safe) version of the bytecode interpreter needs to be used for a specific font (apparently some need it to even load properly). This sets a flag which the ftobjs.c code later uses....

So, in that comment and code, I found that if the hinting mode is set to "LIGHT" instead of medium, the auto-hinter _is_ used. And experimentation bears this out.
That explains why not everyone is immediately fussing about this, and I suppose takes some of the urgency out of the equation.
Still, there's a definite regression: medium and heavy hinting modes should not mean "no hinting!".

There are also the problems of:
1. the many partially hinted fonts that exist : the bytecode interpreter should be used for hinted glyphs, and the autohinter for others, preferably at a setting consistent with whet the bytecode interpreter does
2. the way bytecode interracts with fontconfig/gnome smoothing preferences: with bytecode on, you need to change the gnome prefs to get the closest approximation of the previous settings. It does not autoset the closest one itself (this is going to annoy a lot of users)

Suitable fontconfig scripts can help here.
I use these two scripts to force the autofitter for non-glyf fonts (there is an open rfe for freetype to replace the type1/cff hinting module with one which uses the autofit module, but taking advantage of the type1/cff hints; this would be an excellent project for anyone who wants to delve into font rasterization techniques) and to set the filtering to match the chosen hinting option.
Combined with fc code akin to:
<!-- cut here -->
<match target="font">
<test name="family">
<string>VL Gothic</string>
</test>
<edit name="autohint" mode="assign">
<bool>true</bool>
</edit>
</match>
<!-- and here -->
one can force the autofitter for some glyf fonts and use the bci for others.

Forgot to say:
I’d be optimistic that a patch for freetype, which enabled the autofit module for glyphs of an SFNT/glyf font which lack instructions, would get accepted, provided it matched ft’s coding style.

Ok, reported upstream (always surprises me how people are willing to leave multiple comments on the downstream bug but not bother reporting upstream).
If we don't get a fix, I'll just revert. I don't have the time to fix it myself.

> Ok, reported upstream (always surprises me how people are willing to leave
> multiple comments on the downstream bug but not bother reporting upstream).
That's one of the functions of a packager. We assume you have a working relationship with the developers of the package you're taking care of, and a perhaps a basic knowledge of the code -- which is often vital in such interactions.

Usually the person experiencing the bug is the most appropriate person to report this bug upstream, the packager as a middleman is not an effective solution for communication. So as a general rule, we expect users to file upstream bugs themselves.

On the contrary -- often the person experiencing the bug has no experience with dealing with the particular upstream project, and is actually quite poorly situated to communicate with that project. The reporter may just want their system to work, and not care to learn the intricacies of font rendering mathematics. I think the *general* rule is that package maintainers work with upstream to improve the software in various ways.
Particularly, I was struck by this as it relates to a comment in a recent
LWN.net article on FOSDEM, which quotes someone speaking about another
popular Linux distro thusly:
[Popular Distro] users that want to file a bug, have the choice between
three options. They can file a bug upstream, where they might get flamed;
they can file a bug in [Popular Disto's Parent Distro], where they are
very likely to get flamed; or they can file a bug in [Popular Distro]'s
[Bug Tracker], where there are very likely to get ignored.
But in this specific bug, the upstream issue is basically separate. The issue *here* is that a specfile change caused a regression. Getting the option that was turned on working properly may be interesting for upstream (or not), and presumably i*s* interesting to the packager who changed the specfile to enable it in the first place (or else, why do it?). On the other hand, for the reporter, and for Fedora in general, what's immediately interesting is fixing the regression (so that Fedora 13 doesn't have ugly fonts).

Sorry for the late-night ran. Not meaning to be anti-constructive or to imply that this bug had been ignored. Just wanted to respond to Behdad comment about surprise, which was probably best done out-of-band if at all. So, again, apologies. Let's just get fonts looking nice again.

freetype-2.3.11-3.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update freetype'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-3607

I'm guessing we can assume that Free/OSS fonts are going to look awful for everyone now, not just Rawhide users. That's probably a good thing in the long term, since there will be more incentive to fix it.

(In reply to comment #16)
> Ok, reported upstream (always surprises me how people are willing to leave
> multiple comments on the downstream bug but not bother reporting upstream).
>
> If we don't get a fix, I'll just revert. I don't have the time to fix it
> myself.
Could you provide the upstream bug ID please?

This huge patchset: http://www.infinality.net/blog/ (which mostly enables patent-encumbered stuff and causes bugs such as bug 674311, so it shouldn't be merged as a whole) has an "auto-autohint" feature which does what's being asked for here. (But AFAICT it's disabled by default and enabled by a special settings package they have.)
I can try to cherry-pick the relevant changes.

Created attachment 479352[details]
Patch for this issue from infinality.net
OK, so I checked, the auto-autohint feature is an almost trivial patch. I'm attaching the patch. (And it's actually always enabled, that option they're setting must be a dummy that's not actually implemented as an option.)
Can we:
1. apply this,
2. enable the (no longer patented) BCI in our packages and
3. finally close this bug
now?

Actually, the package I looked at was an old package. The current version does have the option, and it has it all inside a huge patch. But I think the simple patch from the old version (preferably fixed to be indented properly and to remove the commented-out portion) is what we really want.

Created attachment 479362[details]
Cleaned up version of infinality.net auto-autohint patch
This version of the patch is cleaned up to:
1. drop the commented-out junk,
2. respect the indentation and whitespace style of the surrounding code,
3. rename face2 to ttface and
4. check FT_IS_SFNT before trying to use ttface members (probably not strictly needed because only TrueType has a native hinter at all and there's a check for FT_DRIVER_HAS_HINTER at the higher-level if clause, but I think it's better to write safe code).

Hi Kevin,
thank you for the preparation of the patch and its submission. I'll follow up the upstream bug and push it to Fedora then.
Since this is quite big change in almost every application having GUI, I would push it to Fedora 15 and rawhide only. Do you agree?
Marek

freetype-2.4.4-3.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update freetype'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/freetype-2.4.4-3.fc15