best ttfautohint settings?

Matthew Butterick

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.

Ramiro Espinoza

http://typedrawers.com/discussion/232/ttfautohint-grayscale-gdi-dw#latest

Matthew Butterick

First, thanks to Werner Lemberg for making ttfautohint — it’s come a long way since the last time I tried it and it's become a very useful tool. I donated to the project. If you use ttfautohint, you should do the same.

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:

import sys, os

ttfs = sys.argv[1:]

trials = [
"--config-string-1", # these are obviously
"--config-string-2", # fake configuration strings
"--config-string-3", # for illustration only
]

for ttf in ttfs:
   for index, trial in enumerate(trials):
        new_ttf = "trial-%s-%s" % (index, ttf)
        command_string = "ttfautohint %s '%s' '%s'" % (trial, ttf, new_ttf)
        os.command(command_string)

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 ttf in ttfs:
    if "italic" in ttf:
        config = # choose a certain config string
    elif "bold" in ttf:
        config = # choose a different config string
    else:
        config = # set a default config string
    
    new_ttf = "hinted-%s" % ttf
    command_string = "ttfautohint %s '%s' '%s'" % (config, ttf, new_ttf)    
    os.command(command_string)

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.)

Matthew Butterick

The ttfautohint documentation provides a detailed explanation of its hinting options. But the explanations aren’t a substitute for trying them out. It’s not that the options don’t do what they say. Rather, it’s hard to predict in advance whether a particular option will be suitable for a particular font. Also, the options sometimes interact in unanticipated ways. So — experiment, learn, refine.

--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.

Matthew Butterick

Ttfautohint is not a perfect autohinter. With any combination of settings, you’ll likely find a few glitchy glyphs or awkward sizes. But overall, because of its configurability, you can choose where to make those compromises.

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.

Deleted Account

It fails in the transition sizes on vertical stems not exactly equal, and the only way out is to edit the outlines.

John Hudson

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.

Not so. If I am autohinting for a subpixel rendering environment, for instance, I will generate PS hints using the Adobe autohinter, strip out the x-direction hints, convert hints to TT instructions (using the Transformations dialogue), and then I will have a set ofauto-generated editable y-direction TT hints.

Matthew Butterick

Fair enough. I’ve not used the hint-conversion functions in Fontlab. I assume that you’re sending an OT/CFF font through the Adobe autohinter? And if so, at what point do you convert your outlines to quadratic?

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.

Thomas Phinney

One of the things I like about ttfautohint is that its code is really compact, especially compared to FontLab's.

John Hudson

Matthew,

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.

John Hudson

BTW, if you happen to be working with native TT outlines before you get to this stage and want to avoid conversion to and from cubic outlines, it is useful to have a script that will copy PS stem hints from one source to another, so you can do your PS autohinting in a dummy font and then copy the hints into your TT source before converting to instructions. Another way to do this is to assign your TT outlines as the mask layer in an autohinted PS source and then do a swap outline with master routine. This will result in the TT outlines with the PS hints in place.

Georg Seifert

Fontlab can do "PS" autohinting with TT outlines.

John Hudson

Yes, but the Adobe autohinter macro within FontLab requires PS outlines and path direction. It is typically more accurate than the FL autohinter, and less finicky. If working in a non-1000 UPM space, one has to take care to edit the FL autohinting min and max values carefully, or it will skip stems and/or place giant hints across multiple stems; whereas, the Adobe autohinter seems to hit stems accurately without tweaking.

John Hudson

By way of illustration. The FL autohinting results can be improved by editing the min and max values, but depending on the nature of the typeface design it can be difficult to set values that accurately capture all stems, which is particularly important if then converting PS hints to TT instructions.

Deleted Account

I think the concept of overlapping x stems, as contained in the middle of your example glyph, is unsolvable in adobe hints. I thought it can only be one big zone or it fails. In truetype you have all kinds of fabulous options depending on the importance of the original proportions relative to any other value in the whole font, just to bestem and divide the counter in x. But that's all x hinting only one browser observes, in some special mode, no?

John Hudson

I'm not sure to which overlapping x stems you are referring. The left or right example?

John Hudson

When PS hints are converted to TT instructions in FontLab, there seems to be a tolerance within which points very close to the stem hint will be link aligned with the points through which the hint actually passes.

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.

Deleted Account

Both of your illustrations contained the same glyph.
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?

PabloImpallari

A clarification about --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.-

John Hudson

With regard to my example glyphs, the Adobe autohinter catches only the 'overhanging kabonk' and not the right side of the base aligned ring (that shape isn't recognised as a stem by the Adobe autohinter; the FontLab autohinter doesn't catch either when its default settings are used. The following images show the resulting x (left) and y (right) FL visual hints following conversion from the Adobe-generated PS stem hints. Note that the node defining the right side of the lower ring is interpolated relative to the kabonk x hint. To go back to my original point in response to Matthew, this process results in editable visual hints, so it would be possible to replace that interpolation instruction with a stem hint for the right side of the ring, or to dump x-direction hints altogether, or to delta the heck out of it, as you wish and as your target rendering environment requires. [Note that FontLab by default applies some mid-deltas when converting PS hints to TT instructions; this can be disabled in Options, as can some other TT autohinting behaviour.]

Click on thumbnail images for large versions.

John Hudson

Sure, if manually hinting from scratch, we'd handle various bits of that example glyph differently from how the autohinter does it. Mind you, if manually hinting, we'd probably not be using FontLab.

Deleted Account

..and going back to answer Matthew's link to Paul v.d. Laan's question, which is why to use autohinting at all, if there are so many design decisions. I think the answer is that alignments in LatIn fonts, along with y stems, are all that any hinting can help for most uses. So, the web not requiring the auto hinter to make very many design decisions, has brought some fonts for some uses to autohintability.

Matthew Butterick

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.

This is correct. I forgot to mention it in my original posts. Thanks for the clarification, Pablo.

Deleted Account

Documentation is pretty sketchy.

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.