How to use ttfautohint

Jasper de Waard

Hi all,

Dave Crossland asked me to make a short screencast showing how I used ttfautohint for my own Proza Libre. Thought you might be interested. https://vimeo.com/140530738

Richard Fink

I found this very helpful Jasper. Dave sent me the link.  Any tips or more video that you would care to share would be greatly appreciated.  I don't know if there's a link to the current Vimeo tutorial on the Google Fonts Group forum, but I'll make sure it's there.

TTFA keeps on getting better and better.  Thanks for helping to explain it.

Mike Duggan

thanks Jasper, the results are impressive. The control files seem to work, although they are a bit cumbersome to use.

i have found that rather than the settings you propose, using the settings in the enclosed screenshot, are better for DirectWrite, as by not using strong stem width and positioning for DirectWrite, you get a more graded transition between breakpoint sizes, also resulting in a more subtle, and elegant rendering of the font.

this is similar to the hinting approach that can be achieved with the New 'Res Hinting' in VTT 6.01, that was released last month.

Jasper de Waard

You might prefer a more 'subtle' approach indeed, but from my experience the Control Instructions File doesn't do anything in that modus. TTFA does, but the control instructions don't have any effect. I might be proven wrong though.

edit: It might be an issue that occurs only in some operating systems/browsers, though. I can't remember.

Mike Duggan

I was not referring to the control instructions files, only the setting for - strong stem width and positioning - . As I have it set, (see screenshot in my previous post) compared to what you show in the video, allows for a more subtle transition in DirectWrite, rather than hairlines jumping from one full pixel to 2, and 2 to 3 etc. in DirectWrite.

Richard Fink

Thank you, too, Mike.  As somebody who's used TTFA a lot, I've always been confused as to what checkboxes to check and, like Jasper, just checked them all because they weren't mutually exclusive in any way and checking all of them would (logically? supposedly?) optimize the font for all of those conditions rasterizer-wise.  I'm wondering, how did you test? Or was the smoother transition just obvious to you from experience?

Richard Fink

@jasper - Something that has been helpful to me in autohinting TrueType fonts, oddly, is the Adobe Opentype autohinter. Of course, that autohinter is for cubic outlines and creates horizontal and vertical zones. What I've found helpful about it is the output text - which will identify points and segments in certain characters that don't conform to, I guess, the average widths that the autohinter is using to create the blue zones. It points out the outliers, in other words.  And if you read the instructions for TTFA, it uses the same blue zone approach as a first step in deriving the TrueType hints. So I've found that converting to cubic and using the Adobe autohinter first and then nudging those outliers into line - as long as those departures are indeed just small mistakes and not intentionally a part of the design - will help get a more consistent result from the TT autohinter be it TTFA, or the built in autohinters in Fontlab or Fontforge. It also makes for a better hinted OT font which most font producers will need to supply anyway.

Mike Duggan

this is the relevant part of the documentation

http://www.freetype.org/ttfautohint/doc/ttfautohint.html

Strong Stem Width and Positioning
--strong-stem-width=string, -w string
ttfautohint offers two different routines to handle (horizontal) stem widths and stem positions: ‘smooth’ and ‘strong’. The former uses discrete values that slightly increase the stem contrast with almost no distortion of the outlines, while the latter snaps both stem widths and stem positions to integer pixel values as much as possible, yielding a crisper appearance at the cost of much more distortion.

GDI only allows for hairlines or horizontals to break in full pixels, while DirectWrite has additional support for ydirection antialiasing, allowing for a more subtle transition at break points. If -strong stem width and positioning- is set for DirectWrite, it will force full pixel breaks. this causes an abrupt change in weight, when the hairlines break from 1 to 2 and 2 to 3 pixels and so on, either causing the font to look too light or too heavy at breakpoints.

Mike Duggan

compare the DirectWrite rendering here

Left in this example, uses the settings I had suggested

Right uses strong stem width and positioning for DirectWrite

see the breaks in the right hand sample, at 19 to 20 and 32 to 33 on the right. the font looks too light at 32 and too heavy at 33.

Jasper de Waard

@Mike Duggan I see your point. Indeed in the earlier stages of Proza Libre I used settings like yours. I started applying 'strong stem width' when I started using the Control Instructions File. Attached is a sample of what happens to the output if I use your settings WITH Control Instructions. The Control Instructions seem to suddenly have a strange effect, see for example the middle bar in 'a' and e at 20 px. I'm not sure if this is a bug or if it makes sense. But anyhow it's certainly unwanted.

Deleted Account

Jasper, at some point as Richard also points out, the autohinter is saying, "it's the outlines." That your design tools don't tell you that before hinting, is between you and your toolmaker.

Georg Seifert

The problem with the a might be solved if you use a smaller value in the control file for the correction you showed in the video.

Werner Lemberg

Folks, the “strange effect” is a bug in the current release of ttfautohint, I think, which has been fixed already in the git repository: Delta instructions applied to a certain PPEM value also incorrectly influenced other PPEM values, because the affected points were “touched” unconditionally for all PPEM values, causing the interpolation instructions to handle such points always as “strong”.

Either compile ttfautohint from the git repository by yourself, or wait a week or so for the next release.

Sorry for the inconvenience.

Jasper de Waard

Thanks for tuning in and creating some clarity @Werner Lemberg !

Mike Duggan

Thank you Werner, good to know.

Mike Duggan

also, thanks Jesper for the original video and demo.

Richard Fink

Add my voice to the "thank you Werner and Jasper" chorus.

Two things in addition:

1) The three checkboxes in the TTFAutohint interface that Mike Duggan referenced have always been somewhat of a mystery to me. Like Jasper, I've always checked all three, and now it looks like that is NOT best practice. I'll come back to that after Werner's bug fixes are compiled into finished tools and I'll test in the real world. (What's always bothered me is what setting or settings take precedence and in what order given a particular matrix of settings and the rendering environment encountered. What's the "cascade" of priorities? It's just never been clear to me. Hence, the 'check'em all!' approach.

Call me Arnold, I'll be back to take up that issue.

2) The second is the feature request built into my tip about the Adobe autohinter and David Berlow's seeming agreement  ( I lived long enough, I guess )

There is such a thing as hinter-friendly outlines. Certainly, getting as much as possible to line up exactly horizontally and vertically makes logical sense. Therefore, it would be nice if TTFA had a "verbose" mode which reported back textually what it was noticing about the curves and points that was guiding it's hinting decisions.  Like the Adobe authohinter does.

In that the documentation for TTFA explains that TTFA does at first analyze the font in much the same way as a font is analyzed for T1 (cubic OT) hints, perhaps such a mode that points out irregularities in the outline - a mode that tells the user what the autohinter "sees", a clue as to how it reconciles conflicts and the like - perhaps that's possible in a future release?

Thank you Werner!

Christian Thalmann

Georg, Mekka, is there any way one should be influencing the autohinter in Glyphs other than through alignment zones, stem widths, and the occasional TTFstem custom parameter?  For instance, should we be worrying about these boxes that can apparently be checked in ttfautohint?

Does Glyphs include the ttfautohint bug fix mentioned above?

Mike Duggan

Richard. I assume you are talking about the -strong stem width and positioning -

If you want your fonts hairlines, or horizontals to break in full pixels then set it

my recommendation is

GDI -strong stem width and positioning- =set

*Greyscale -strong stem width and positioning- = not set

*DW ClearType-strong stem width and positioning- = not set

*This is for the reasons I mentioned before, about how horizontals breaking in full pixels can cause fonts to look either too light or too heavy (Bold fonts can suffer more severe distortions) in DirectWrite or Greyscale where we have additional antialasing to allow for a more subtle transition, closer to how the font weight should render. 

there is really no cascade, if an application is using GDI, and in TTFAutohint -strong stem width and positioning- =set, the font will render with horizontals breaking in full pixels. This is generally speaking desirable in GDI ClearType, as when gridfitting is applied, full pixel breaking is desiable to maintain a consistent look. If   -strong stem width and positioning- = not set for GDI ClearType, there is no guarantee that horzontals will break consistently. the effect of not setting -strong stem width and positioning-, in GDI, is like using a halfgrid rounding, and generally does not produce consistent results in GDI, when output from TTFautohint.

In VTT, this breaking behaviour is usually contolled, in by cvt's (control value table), and by using inheritence

there are some other issues that can effect the visual output, such as, relating to how the GASP table is set. I will try and get around to writing some of this up with some visual examples to show the results, so folks can compare and contrast.

Jeff Kellem

Christian Thalmann said:

Georg, Mekka, is there any way one should be influencing the autohinter in Glyphs other than through alignment zones, stem widths, and the occasional TTFstem custom parameter?  For instance, should we be worrying about these boxes that can apparently be checked in ttfautohint?

For Glyphs: You can access some of those checkboxes by setting the “TTFAutohint options” Custom Parameter of an Instance. Clicking on the value field will display a pop-up to show those options.

Richard Fink

@Mike Duggan  Thank you for clearing away the fog surrounding those settings.

Yes, it's the checkboxes shown above I was referring to.

So - to reiterate - correct me if I'm wrong:

Checking only the GDI Clear Type box and none of the other two will cause the glyphs to sharply snap by a full pixel in a GDI rendering environment at certain breakpoints such as those in your screen shots. Whereas, in a Direct Write (DW) rendering environment, the font will change size more gradually, more smoothly, using Direct Write's sub-pixel smoothing across both axes.

Do I have this right?

And in contrast:

If BOTH the GDI Cleartype AND the DW ClearType Boxes are checked, then in a Direct Write rendering environment, the behavior will mimic the behavior you would find in a GDI ClearType environment, with the glyphs snapping sharply by a full pixel at certain breakpoints.

Do I have this right, too?

(At this point I'm left wondering where the grayscale setting might apply. What exactly does IT do and is it still at all relevant in today's world of color screens?)

Thanks again. 

Mike Duggan

All correct Richard. Greyscale or Font Smoothing, as it was known in Windows is less relevant today, but might apply in some older environments

Werner Lemberg

Thanks to Greg Hitchcock, FreeType now comes with a much better documentation of the various ClearType hinting modes and the related marketing terminology.  You might have a look at

  http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/ftttdrv.h

to get more information (after the next FreeType release this will be in the HTML docs also).

Contrary to the GUI, the command-line version of ttfautohint has a flag `--debug`, which gives you all details on the exact hinting process!  Since the amount of information (sent to stderr) is really huge, I recommend that you use this flag with a single PPEM size only, redirecting the console output to a file.  A possible call for font `foo.ttf` might be

    ttfautohint --debug -l 20 -r 20 foo.ttf /dev/null > foo.log 2>&1

On Windows, the null device `/dev/null` is called `nul`.

Note also that the log files are not influenced by the `-w` settings!  The auto-hinter rules built into ttfautohint are agnostic of the output device (except its resolution); smooth and strong stem width handling is completely implemented in the created TrueType bytecode.

Richard Fink

@werner I'm a fair hand with the Windows command line. There should be no problem directing the output to a text file.  Thanks for the tip. I'll take a look.

Werner Lemberg

BTW, ttfautohint 1.4 is out!  Please retry auto-hinting with the new version.

Christoph Koeberlin

@Werner Lemberg Where is the Strong Stem Width and Positioning information stored? Couldn’t find substantial differencies in the TTFs I created with different adjustments.

Werner Lemberg

[Sorry for the late reply!  I'm not regularly reading this forum.]
[ttfautohint version 1.4.1 is out.]

The strong option for the three hinting modes is directly injected into the prep table while ttfautohint is creating the output font.  The difference is that three certain bytes in the bytecode are respectively set to 100 for 'on' and to zero for 'off'.

Dave Crossland

Jasper's files are available for reference at https://github.com/jasperdewaard/Proza-Libre