Thu 13 Sep 2012 12:42:12 PM UTC, comment #8:
Yes, it works now. The re-hinted font has consistent x-heights in all modes of ftview, and switching forced autohinting on and off only makes horizontal changes.
|
Thu 13 Sep 2012 05:47:03 AM UTC, comment #7:
Oops! I renamed a parameter of TTF_autohint and forgot to update the frontends. Fixed in ttfautohint's git repository, please test. Thanks for the report.
|
Wed 12 Sep 2012 05:57:03 PM UTC, comment #6:
I finally got around to testing this. I can confirm that the problem appears to be fixed in FreeType git, in the following sense: when 'ftview' is told to render the font that's attached to this bug, with hints enabled and autohinting forced on, the x-heights of all ASCII letters are drawn consistently. (It is my understanding that in this mode, FreeType will ignore the hint information in the font and generate its own. Consistent with that, if autohinting is not forced on, 'ftview' will show the same x-height errors as it originally did, which makes sense since the in-font hints are still bad.)
However, I can not confirm the fix in ttfautohint. I get an error message when I try to run the program on this font file:
$ ./frontend/ttfautohint --debug --verbose Quattrocento-Regular.ttf Quattrocento-Regular-f.ttf
Error code `0x06' while autohinting font:
invalid argument
|
Wed 04 Jul 2012 08:49:32 PM UTC, comment #5:
I am traveling and will not be able to test until after July 16. If I fail to follow up by the beginning of August, I would appreciate a reminder.
|
Wed 04 Jul 2012 03:21:59 PM UTC, comment #4:
This is now fixed in both FreeType and ttfautohint. Please test.
|
Thu 05 Apr 2012 05:52:44 AM UTC, comment #3:
It is one of the main development goals of ttfautohint to allow manual hinting after automatic hints have been applied. However, this is a future project and not implemented yet.
Fortunately for you, this font doesn't contain composite glyphs, so you can easily rehint the font with ttfautohint; see this page how to obtain the program:
http://www.freetype.org/ttfautohint
For example, with command line option `-l 8 -r 8 -G 8' you might disable hinting for all sizes larger than 8 pixels.
Unfortunately for you, the ttfautohint options you need to really improve hinting are not available yet, so disabling hinting is perhaps the best what you can currently achieve.
BTW, you might also try a different font editor to automatically rehint the font (for example using FontForge); maybe this gives better results.
|
Thu 05 Apr 2012 02:26:17 AM UTC, comment #2:
Thanks for the explanation.
How hard would it be to manually correct the bad hints in the font? I have only a tiny bit of experience with fonts.
|
Wed 04 Apr 2012 11:09:05 PM UTC, comment #1:
This is an interesting bug report since it affects two issues which are completely different and tightly connected at the same time.
The first one is a problem with FreeType's autohinter. It can't handle fonts well which have such extremely large serif heights, exceeding an (internal) threshold. You will probably see similar problems with Palatino, BTW.
The second problem is unrelated to FreeType. It is rather a problem with the TrueType bytecode created by ttfautohint, the tool which has been used to hint this font. It produces bad hints for some glyphs, notably shifting down its shapes. However, since ttfautohint is directly derived from FreeType's autohinter, it exhibits exactly the same problems...
Accidentally, I know the author of ttfautohint very well (it's me also :-), so you don't need to file a different bug report.
I think that I will be able to eventually fix this issue in ttfautohint (but it may take a while). A fix for the autohinter is much harder, unfortunately, due to its non-interactiveness.
|
Wed 04 Apr 2012 04:58:30 PM UTC, original submission:
When any level of hinting is enabled, Freetype renders the attached font (from http://impallari.com/quattrocento ) poorly at larger sizes. Specifically, look at the attached image: at 16pt the x-heights are all visually consistent, but at 17pt "medium" and "full" hinting make the v, w, x glyphs one pixel too short (or possibly one pixel displaced downward -- there seems to be a problem with the baseline as well as the x-height), and at 18pt "slight" hinting is wrong too.
The image was generated from a bunch of screen shots of GNOME Specimen, but you can also see it "live" with ftview like so:
$ ./ftview 16 Quattrocento-Regular.ttf
Press space until it says "rendering glyph waterfall" at the top, then press "h" repeatedly and watch how the word "brown" changes at various sizes. Tested with current git trunk.
|