I'm planning to do
some experiments of my own, but what have others found to be the optimal settings for ttfautohint (= the
current version: 0.96) for a) webfonts, b) Windows desktop fonts.
PS. Not interested in
political & religious digressions about hinting philosophy, just facts & experience from those who have used ttfautohint.
Comments
The name of the game with ttfautohint is systematic trial & error. Ttfautohint is very fast. So the best way to figure out what works is to generate test fonts and look at them. I used a Python script to do this. Here’s the basic idea, assuming you pass the list of fonts as input to the script: This will give you a folder full of ttfs hinted in different ways.
Then I opened a browser with Pablo Impallari’s font tester and dragged sets of fonts into it. Pablo’s tester makes it easy to click between fonts and spot differences in rasterization. Also, it’s useful to compare these trial fonts in two directions: a) one font style, hinted different ways and b) different font styles, hinted the same way.
Third — and this is the most important thing I discovered — because ttfautohint is so fast, and every option can be configured on the command line, there is no need to use the same configuration for every style of font. Meaning, rather than try to find a single golden configuration that works for every font, you can find configurations that work for groups of fonts (e.g., sans vs. serif, regular vs. bold, roman vs. italic), or even individual fonts, and apply them as needed. This can be scripted too, e.g. — For those already panicking that this is way too loosey-goosey for TrueType hinting, well, that’s sort of the idea. Ttfautohint assumes that we’re living in a world of antialiased rendering, and thus a softer touch is warranted. To that end, it only applies y-direction hints. So when you’re twiddling the ttfautohint knobs, you’re looking to achieve consistent heights, and then you let the stems take care of themselves.
No, ttfautohint does not achieve — nor can it achieve, nor does it try to achieve — the kind of pixel-level control you get with manual TT hinting. But the results are certainly far better than what one gets from, say, FontLab Studio autohinting. I’d say ttfautohint, properly calibrated, and viewed through the common TT rasterizers, can reach 80% of the quality of manual hinting.
I know that some will not be satisifed without that extra 20%. If that’s your thing, enjoy. But it took me about half a day to find the best settings for 30 fonts. The hinting itself took 15 seconds. How long will the manual hinting take? That extra 20% starts to look very expensive.
(Later I’ll post about specific ttfautohint config options.)
--hinting-range-min=[size] --hinting-range-max=[size]
This option determines the sizes where ttfautohint adds hints. To my mind, less outline distortion (i.e., greater fidelity to the design) is always preferable. Therefore, I stop hinting when there’s enough vertical pixels to make the glyphs look good, usually in the 50-60 px range.
On the low end, ttfautohint does a surprisingly good job below 16 px, which are usually the sizes that give autohinters the most trouble (actually, manual hinters too). But it’s not a problem to start hinting at 8px.
Sometimes, however, you want to set the max size pretty low. For instance, I used these options to hint all my italics:
--hinting-range-min=8 --hinting-range-max=8
“You’re only hinting at 8px? That’s pointless.” Surprisingly not. Because it only cares about y-direction hints, ttfautohint works by calculating vertical blue zones and snapping vertical glyph features to those zones. So fonts that don’t sit squarely in those blue zones, like italic fonts, don’t necessarily do well. However, it’s still worth running these fonts through ttfautohint, because even without instructions, you’ll get the benefit of the scan converter preventing dropouts. (If you want to see what dropouts look like, use the
--dehint
option to see your font with no hints at all.)--increase-x-height=[size]
This tells ttfautohint to round x-heights up where possible. I think this is OK at small sizes (< 15 px) where every pixel counts. But after that, I think it distorts the outline too much.
--x-height-snapping-exceptions=[size ranges]
This tells ttfautohint not to snap to x-height at particular sizes. As with the italic above, this is useful for situations where the lowercase characters don’t sit on the x-height in the usual way. For instance, I have fonts with sans serif small caps in the lowercase positions. The pointed ones (AVW) were getting mangled because x-height snapping was pushing the points inward (and thus thinning the strokes). But when I stopped snapping to x-height, they looked good again.
--strong-stem-width=""
The documentation goes into the voodoo behind what ttfautohint calls “strong” horizontal stems (which are rounded to the grid) and the other option, “smooth” (which are not). In keeping with my principle of greater fidelity to the outlines, I had the best luck always using smooth horizontal stems.
--no-info
Without this option, ttfautohint will add its configuration to the version string of your font. So for production fonts, you always want to add this option to your config string.
The ability to tune the configuration to the type of font is a big benefit. For instance, in Fontlab, you can set the autohinting preferences at the application level, or you can do manual hinting, but nothing in between. Whereas in ttfautohint, this is easy.
If you think that this would lead to wild inconsistencies within a font family, it doesn’t. Traditional TT hinting is sort of like plastic surgery: the more you use, the more you need. Whereas ttfautohint encourages a lighter touch — more velvet glove than iron fist. This approach is well suited to the trend toward higher-resolution screens, better glyph smoothing, etc.
(This is also the answer to Paul van der Laan’s worthwhile question about how an autohinter can be faithful to a design.)
In sum:
If you already rely on some form of TT autohinting, ttfautohint is a no-brainer upgrade.
If you’re considering manual hinting, you should try ttfautohint, as it may be sufficient for your needs.
If you’re an adherent of manual hinting, I doubt ttfautohint will change your mind.
The key shortcoming with ttfautohint right now is that one can’t specify custom blue zones. Therefore, if you have a font with atypical glyph heights — for instance, 3/4 height figures — they can be hard for ttfautohint to handle properly.
Whereas with your method, it sounds like you’re getting the benefit of custom blue zones. (Though that benefit comes at the cost of an extra roundtrip through Fontlab, right?)
Again, I wouldn’t expect ttfautohint to be all things to all people (or all fonts). But given the speed and ease of experimentation, it’s cheap to find out.
My approach works with either the FL PS autohinter or with the Adobe one -- or, indeed, with manual PS hints --, but yes I usually use the Adobe one. I apply this directly within FL, using the Adobe macro -- having first manually set blues values and standard stem hints --, then I have an FL Transformation routine saved that a) removes x-direction stem hints, b) converts outlines to quadratics, c) sets TT path direction, and d) converts hints to instructions. It is possible to manually intervene anywhere in this process, which is what I like about it.
As I wrote above, my usual routine -- i.e. the one targeting subpixel rendering -- strips x-direction hints before converting to instructions.
As should also note that very few of our clients opt for the autohint approach: most want Ross' manual VTT work. This is in part a function of the complex scripts with which we work, which tend to benefit from human decision making about vertical relationships.
Pink shows the right stem of the base aligned bowl.
yellow is the left stem of the overhanging kabonk
grey is the overlapping x stems of the two.
If it's the font and not the client defining how to hint, (man or machine), would that bother Ross or your clients?
--hinting-range-min
and--hinting-range-max
, and another parameter called--hinting-limit
that must be used together.--hinting-range-min
and--hinting-range-max
are the limits for which the hinting instruction are generated, but they are not limiting the size to which they are applied.Even if you specify 58 as a max, the instructions generated for the 58ppm size will be applied all the way up to 200 ppm (The default
--hinting-limit
value), and it will not look very good.So, for example, if you want to turn off hinting for values larger than 40, you should specify both parameters
--hinting-range-max=40
and--hinting-limit=40
.Default values (used if you omit the any of the parameters) are
--hinting-range-min=8
,--hinting-range-max=50
and--hinting-limit=200
.-Click on thumbnail images for large versions.
Glyph hints are not usually made per ppm for space reasons. Autohinting that adds pixel specific delta instructions in the glyph instructions is unlikely. But if the "range" were applying to cvt cut in values, and the "limit" were referring to the instruction control in the prep table, setting them both the same sounds like a simplified way to turn off scaling and any special rendering all at once. This is not usually done.
But, back at Matthew's "...it’s hard to predict in advance whether a particular option will be suitable for a particular font." If range does control cvt cut in, at least one parameter at a time, say overshoot/undershoot, could be controlled predictably via range, as long as one knows the units per em, and units of the parameter, and the parameter is being hinted.