Understanding TT hinting

Primary tabs

60 posts / 0 new
Last post
Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

finally, an old-fashioned Typophile thread!

Thank you all!

José Miguel Solé B.'s picture
Joined: 16 Mar 2011 - 4:48pm
0

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
Joined: 26 Feb 2007 - 1:03pm
0

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
Offline
Joined: 23 Jan 2006 - 10:43pm
0

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

José Miguel Solé B.'s picture
Joined: 16 Mar 2011 - 4:48pm
0

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.

José Miguel Solé B.'s picture
Joined: 16 Mar 2011 - 4:48pm
0

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
Joined: 26 Feb 2007 - 1:03pm
0

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
Joined: 26 Feb 2007 - 1:03pm
0

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.

José Miguel Solé B.'s picture
Joined: 16 Mar 2011 - 4:48pm
0

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.