It looks like you're new here. Sign in or register to get started.
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.
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.
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.
this is the relevant part of the documentation
Strong Stem Width and Positioning--strong-stem-width=string, -w stringttfautohint 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.
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.
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!
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.
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?
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?)
@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.