Understanding TT hinting

Frode Bo Helland's picture

Suffice to say, the documentation of TT hinting is either too shallow (not explaining enough, as in the case of the Fontlab manual) or highly advanced (The Raster Tragedy). I have some questions that I'll just get right to:

1: What is the difference between single and double links?
2: The Raster Tragedy seems to say that with the correct hinting, very few deltas are needed, but doesn't describe a method (or I just couldn't decode the advanced language) to do so. Take for example an "o": with simple links, the stems are easily controllable, but the northeast/northwest/southwest/southeast areas will still have stray pixels or odd widths. How do you deal with those without deltas?
3: How far can the interpolation links move a point?
4: How do you approach diagonals?
5: How do you approach intersections, like in an "x"?
6: Is there a way to move an alignment zone one pixel for the whole font at a given ppm, or do I have to do this manually for each glyph?
7: How do you hint an "s"?
8: How do you hint diagonal terminals?

I realize this is a lot, but I've read all documentation I've been able to find in and out +10 times now and this baby ain't giving up her tricks.

dezcom's picture

finally, an old-fashioned Typophile thread!

Thank you all!

JM Solé's picture

John, that's weird, maybe it's a browser thing. I always try the links in preview mode before posting.

Beat, I asked because I've seen spacing problems like those on some fonts for the web (as well as some of my projects) and I always assumed they were produced by rounding errors in "natural" widths. At least now I know not to assume and also how to check them out in my own proyects. Thanks ;)

(Edit: also, I need to re-read the Raster Tragedy and the TT specs a few more times and start trying and messing more things up. There are to many thing I don't understand.)

Frode Bo Helland's picture

José Miguel: The example I posted makes little or no use of x direction hints. This is, btw, not done in VTT. I haven't touched the widths/sidebearings at all, but I plan to even out problems like this with a combination of x direction links, x direction deltas (not used by Cleartype) and manipulating the character widths (prior to hinting). I've snapped all stems to the pixel grid on the left edge, but allow them to flow free on the right edge.

Beat Stamm's picture

@José Miguel

Safest for me, though most arduous, is to obtain a pixel-by-pixel match between what I see (e.g. in the browsers) and what I can setup in VTT (“compatible”, “natural”, or “fractional” widths, y-anti-aliasing, and gamma correction). Like that I can see that Chrome 10, FireFox 3.6, Internet Explorer 7, and IE 8 use “compatible” widths without y-anti-aliasing, while Safari 5 (on Windows) uses unhinted fonts with y-anti-aliasing, but no fractional advance widths.

To see fractional pixel positioning with y-anti-aliasing (aka DirectWrite) in action, I installed FireFox 5.0 on Windows 7, turned on Options => Advanced => Use hardware acceleration when available, but apparently on my test machine (laptop/tablet convertible) this is not available, hence I’ll do the respective illustrations in the comparison below in VTT.

The following illustrations show the RTM version of Calibri at 11 pt and 96 dpi, no gamma correction (to match rendering [font-smoothing medium] in Quartz/Safari 5.0 for Windows, which either doesn’t offer gamma correction, or if it does, I haven’t discovered it)

“Compatible” widths, rendered in Chrome 10 (same results for IE 8, and for FF 5.0 without HW acceleration)

Integer widths, rendered in Safari 5 on Windows.

“Natural” widths, rendered in VTT (same as Office 2007 “Web Layout” mode, which is a “reflow” layout, but kind of looks like a bad “wysiwyg” layout)

Fractional advance widths, rendered in VTT (this is the spacing I would expect from DirectWrite—if this were available on my test machine).

For demonstration purposes I re-hinted the key characters of Calibri, minimizing any issues with “natural” widths in TT code. The following illustrations show this (non-RTM) version of Calibri.

Actual natural widths, rendered in VTT, true to 11 pt and 96 dpi (non-RTM version of Calibri, using fractional ppem sizes)

Actual fractional advance widths, rendered in VTT, true to 11 pt and 96 dpi (non-RTM version of Calibri, using fractional ppem sizes)

Compare line lengths of the preceding illustrations—the last one is closest to Luc[as] de Groot’s design.

On a slight tangent, following is a juxtaposition of the above sample rendered in Safari 5 on Windows with the same sample rendered in VTT with actual natural widths and y-anti-aliasing.

Substantially the same spacing, but the proportions of the lc ‘e’ appear different—the bottom one is closer to Luc[as] de Groot’s design.

And here are the same illustrations at their original sizes (be sure to reset your zoom to 100%)

Different degrees of “bold,” different “sharpness” of strokes, different levels of color “fringing,” but neither one of them as scalable as actual fractional advance widths using fractional ppem sizes.

JM Solé's picture

Frode, I'm sorry for using your images as examples. I understand they are tests. I just wanted to use the opportunity to ask. Concerning your plans about snapping the left edge, I have some questions. In a serif font, would you snap the first point to the right, meaning it could be a serif or a stem, or would you snap only the stems and let the serifs free? And also, what kind of anchors would you use? I've been testing some stuff concerning this and perhaps I will post something later.

JM Solé's picture

Beat, it's amazing the difference Fractional advance widths make. Now, if Chrome uses "compatible" widths then the spacing problems I see on some web fonts (and my fonts, sadly) are within this kind of advance width, as this is my usual browser. I have IE9 and FF5 (with DirectWrite rendering activated) and I think fonts look amazing there, but prefer, at least for now, to use Chrome (and GDI) because it's what other people use and see (and Chrome just works better;).

I'll have to start testing solutions having in mind both horizontally snapping stems and just adjusting the character widths. I think, at least for now, those are my only options at trying to solve this.

Frode Bo Helland's picture

I snap the stems, and let the serifs run free.


Y-direction


X-direction

And yes, these are just tests. I'm certainly not insulted: These are my results just a few weeks into the hinting game. I'm still figuring out the tools (FL for now, VTT at a later stage), and experimenting with strategies.

There are a number of things to consider here, and perhaps most important is this: How much time is it viable to spend on hinting?

Frode Bo Helland's picture

Actually, looking at my samples I realized I forgot to do my little interpolation fix to align the right edges of the first stem in this particular glyph.

There's a HUGE gap between basic x direction hinting in Fontlab and the kind of stuff Beat is talking about. The former tend to cause more trouble rather than order, at least for (smoothed) Standard GDI and Cleartype.

Another thing to take into consideration is the difference in appearance between platforms. Snapping to the pixel is not neccesarily the best option.

JM Solé's picture

Until now I've only been doing Y-direction hints. That can be done fast if your font is fairly regular in stem widths. The problems I've been struggling with concern spacing and are probably caused by not paying much attention to character widths, and thus, not fixing them. I also assumed they were rounding problems and that they were too difficult to solve (I imagined mountains of TT coding and stuff like that). At least now I understand a bit better what my final environment is and now I have other possibilities to test. I'll try some stuff on my font and then post images.

Syndicate content Syndicate content