Bug 547532 - freetype with the bytecode interpreter enabled falls back to no hinting instead of autohinting when no hinting bytecode is available
freetype with the bytecode interpreter enabled falls back to no hinting inste...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: freetype (Show other bugs)
15
All Linux
low Severity low
: ---
: ---
Assigned To: Marek Kašík
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 612395
  Show dependency treegraph
 
Reported: 2009-12-14 16:27 EST by Matthew Miller
Modified: 2015-02-04 17:28 EST (History)
25 users (show)

See Also:
Fixed In Version: freetype-2.4.4-3.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-07 21:27:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Without bytecode (65.44 KB, image/png)
2009-12-14 16:49 EST, Matthew Miller
no flags Details
With bytecode (72.85 KB, image/png)
2009-12-14 16:49 EST, Matthew Miller
no flags Details
Fontconfig conf file to set hintstyle based on each font’s format (1.02 KB, application/xml)
2009-12-21 18:23 EST, James Cloos
no flags Details
Fontconfig conf file to set LCD filter based on each font’s format and hintstyle (1002 bytes, application/xml)
2009-12-21 18:25 EST, James Cloos
no flags Details
Patch for this issue from infinality.net (1.07 KB, patch)
2011-02-17 10:35 EST, Kevin Kofler
no flags Details | Diff
Cleaned up version of infinality.net auto-autohint patch (964 bytes, patch)
2011-02-17 11:16 EST, Kevin Kofler
no flags Details | Diff

  None (edit)
Description Matthew Miller 2009-12-14 16:27:18 EST
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.
Comment 1 Tomasz Torcz 2009-12-14 16:33:46 EST
Could you provide some before and after screenshots?
Comment 2 Kevin Kofler 2009-12-14 16:38:35 EST
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.
Comment 3 Matthew Miller 2009-12-14 16:49:07 EST
Created attachment 378369 [details]
Without bytecode
Comment 4 Matthew Miller 2009-12-14 16:49:30 EST
Created attachment 378370 [details]
With bytecode
Comment 5 Matthew Miller 2009-12-14 16:52:07 EST
That's with medium hinting enabled, by the way. No sub-pixel rendering.
Comment 6 Behdad Esfahbod 2009-12-14 22:44:02 EST
Can someone please bring this upstream?
Comment 7 Matthew Miller 2009-12-14 23:26:14 EST
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....
Comment 8 Matthew Miller 2009-12-14 23:41:39 EST
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!".
Comment 9 Behdad Esfahbod 2009-12-14 23:42:36 EST
I see.  And since this is in rawhide only, lets not revert and fix it properly.
Comment 10 Nicolas Mailhot 2009-12-15 10:44:07 EST
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)
Comment 11 Matthew Miller 2009-12-15 10:49:02 EST
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.
Comment 12 James Cloos 2009-12-21 18:18:10 EST
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.
Comment 13 James Cloos 2009-12-21 18:23:09 EST
Created attachment 379733 [details]
Fontconfig conf file to set hintstyle based on each font’s format
Comment 14 James Cloos 2009-12-21 18:25:27 EST
Created attachment 379737 [details]
Fontconfig conf file to set LCD filter based on each font’s format and hintstyle
Comment 15 James Cloos 2009-12-21 18:28:55 EST
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.
Comment 16 Behdad Esfahbod 2010-02-23 17:11:11 EST
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.
Comment 17 Matthew Miller 2010-02-23 18:49:21 EST
> 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.
Comment 18 Kevin Kofler 2010-02-23 23:08:57 EST
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.
Comment 19 Matthew Miller 2010-02-24 00:06:14 EST
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).
Comment 20 Matthew Miller 2010-02-25 15:50:11 EST
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.
Comment 21 Behdad Esfahbod 2010-03-03 17:23:41 EST
Ok, given upstream discussion I'm disabling bci for f13.
Comment 22 Behdad Esfahbod 2010-03-03 17:28:30 EST
Leaving open since this still is an issue on rawhide.
Comment 23 Fedora Update System 2010-03-03 17:48:44 EST
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
Comment 24 Fedora Update System 2010-03-03 20:33:40 EST
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
Comment 25 Fedora Update System 2010-03-10 01:39:51 EST
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.
Comment 26 Matthew Miller 2010-03-10 08:48:36 EST
Reopening for rawhide as per comment #22.
Comment 27 Matthew Miller 2010-03-10 08:49:08 EST
(And thanks for the reversion for F13.)
Comment 28 Bug Zapper 2010-03-15 09:34:32 EDT
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
Comment 29 Michael Monreal 2010-07-19 13:45:39 EDT
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?
Comment 30 Matthew Miller 2010-07-19 13:57:23 EDT
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.
Comment 31 Bug Zapper 2010-07-30 06:48:45 EDT
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
Comment 32 Carl G. 2010-08-20 17:19:38 EDT
(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?
Comment 33 Fedora Admin XMLRPC Client 2010-09-22 09:54:52 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 34 Fedora Admin XMLRPC Client 2010-09-22 10:00:01 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 35 Kevin Kofler 2011-02-17 10:24:56 EST
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.
Comment 36 Kevin Kofler 2011-02-17 10:35:38 EST
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?
Comment 37 Matthew Miller 2011-02-17 10:38:14 EST
Thanks Kevin. That'd be awesome.
Comment 38 Kevin Kofler 2011-02-17 10:41:30 EST
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.
Comment 39 Behdad Esfahbod 2011-02-17 10:55:36 EST
Humm, Kevin, why did you change the bug summary?
Comment 40 Kevin Kofler 2011-02-17 11:16:15 EST
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).
Comment 41 Behdad Esfahbod 2011-02-17 11:29:18 EST
Please send this upstream for consideration.
Comment 42 Kevin Kofler 2011-02-17 11:33:47 EST
Funky Bugzilla glitch there, I fixed the tags for this bug, they got copied from another bug somehow.
Comment 43 Kevin Kofler 2011-02-17 12:02:26 EST
Upstream patch submission: https://savannah.nongnu.org/patch/index.php?7471
Comment 44 Marek Kašík 2011-02-18 04:52:51 EST
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
Comment 45 Kevin Kofler 2011-02-18 10:05:41 EST
Yeah, that's probably safest. Especially our default fonts, Deja Vu, are infamous for looking somewhat different with the BCI.
Comment 46 Marek Kašík 2011-02-20 07:31:36 EST
Hi,

I've committed the patch to Fedora 15 and rawhide.

Marek
Comment 47 Fedora Update System 2011-02-20 07:39:52 EST
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
Comment 48 Fedora Update System 2011-02-20 22:20:49 EST
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
Comment 49 Fedora Update System 2011-03-07 21:27:29 EST
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.
Comment 50 Kevin Kofler 2011-03-08 04:55:06 EST
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?
Comment 51 Marek Kašík 2011-03-08 06:35:32 EST
(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.
Comment 52 Fedora Update System 2011-03-08 11:41:35 EST
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
Comment 53 Fedora Update System 2011-03-09 22:07:37 EST
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.
Comment 54 Ivan Romanov 2011-06-05 08:37:41 EDT
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?
Comment 55 Kevin Kofler 2011-06-05 10:24:52 EDT
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/
Comment 56 Ivan Romanov 2011-06-05 11:19:39 EDT
Thanks! It works.
Comment 57 Matthew Miller 2011-06-05 16:25:34 EDT
(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_.
Comment 58 Kevin Kofler 2011-06-05 16:34:21 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.