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.
Could you provide some before and after screenshots?
Indeed, I hinted (no pun intended) at this problem on the mailing list. Freetype really needs to be fixed to fallback to the autohinter where no hinting bytecode is provided.
Created attachment 378369 [details] Without bytecode
Created attachment 378370 [details] With bytecode
That's with medium hinting enabled, by the way. No sub-pixel rendering.
Can someone please bring this upstream?
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!".
I see. And since this is in rawhide only, lets not revert and fix it properly.
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)
The second part of "1" from comment #10 sounds a bit hard. It's okay to leave it on for rawhide, but we should have a plan to revert if the upstream fixes can't be in place in time.
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.
Created attachment 379733 [details] Fontconfig conf file to set hintstyle based on each font’s format
Created attachment 379737 [details] Fontconfig conf file to set LCD filter based on each font’s format and hintstyle
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.
Ok, given upstream discussion I'm disabling bci for f13.
Leaving open since this still is an issue on rawhide.
freetype-2.3.11-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/freetype-2.3.11-3.fc13
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
freetype-2.3.11-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Reopening for rawhide as per comment #22.
(And thanks for the reversion for F13.)
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Did anyone check the latest fontconfig yet? According to recent news stories, upstream now enables the bytecode interpreter by default... so can we assume the issues mentioned here are fixed?
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.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(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 package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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?
Thanks Kevin. That'd be awesome.
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.
Humm, Kevin, why did you change the bug summary?
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).
Please send this upstream for consideration.
Funky Bugzilla glitch there, I fixed the tags for this bug, they got copied from another bug somehow.
Upstream patch submission: https://savannah.nongnu.org/patch/index.php?7471
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
Yeah, that's probably safest. Especially our default fonts, Deja Vu, are infamous for looking somewhat different with the BCI.
Hi, I've committed the patch to Fedora 15 and rawhide. Marek
freetype-2.4.4-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/freetype-2.4.4-3.fc15
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
freetype-2.4.4-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
There's a followup fix from upstream: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=c9bdfa7e658f42f3faed2b426e3b1251a04938e4 Shouldn't we apply that, too?
(In reply to comment #50) > There's a followup fix from upstream: > http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=c9bdfa7e658f42f3faed2b426e3b1251a04938e4 > > Shouldn't we apply that, too? Yes, we should. I'll apply it today.
freetype-2.4.4-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/freetype-2.4.4-4.fc15
freetype-2.4.4-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Hello! This patches broked my Liberation Serif font. before http://img.flashtux.org/upload/img132dd0d22a00x1787d7d1.png after http://img.flashtux.org/upload/img132dd0d22c5bx7a383f44.png Can reopen bug? Or i should make new?
Fonts may look different with the bytecode interpreter enabled. This is not a bug. See also: https://kevinkofler.wordpress.com/2011/05/19/hint-how-to-force-autohinting-on-fedora-15/
Thanks! It works.
(In reply to comment #55) > Fonts may look different with the bytecode interpreter enabled. This is not a > bug. Different isn't a bug. Horribly ugly when they weren't before _is_.
Well, that is an issue you will have to take up with the font's designers and/or maintainers. You can't really blame Freetype for rendering the font the way the designers programmed it.