best ttfautohint settings?

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

  • Matthew Butterick
    Matthew Butterick Posts: 143
    edited September 2013
    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.
  • 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.
  • It fails in the transition sizes on vertical stems not exactly equal, and the only way out is to edit the outlines.
  • 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
    Matthew Butterick Posts: 143
    edited September 2013
    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.
  • One of the things I like about ttfautohint is that its code is really compact, especially compared to FontLab's.
  • 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.
  • 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.
  • Fontlab can do "PS" autohinting with TT outlines.
  • John Hudson
    John Hudson Posts: 3,190
    edited September 2013
    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.
  • 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.
  • 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?
  • I'm not sure to which overlapping x stems you are referring. The left or right example?
  • John Hudson
    John Hudson Posts: 3,190
    edited September 2013
    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
    Deleted Account Posts: 739
    edited September 2013
    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
    PabloImpallari Posts: 806
    edited September 2013
    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
    John Hudson Posts: 3,190
    edited September 2013
    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.
  • 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.
  • ..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.
  • 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.
  • 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.