The visitor’s OS’s rendering engine (and any related settings, if different than general OS antialiasing settings)

The visitor’s browser antialiasing settings

The visitor’s browser’s rendering engine (and any related settings, if different than general browser antialiasing settings)

Hinting instructions provided by the suggested typeface?
(If so, at what level are these hinting instructions applied? OS? Browser?)

Thomas Phinney answered right away:

All of those components *can* affect how type is rendered, but only one rendering engine and one anti-aliasing setting will be in play at a time for a given browser. [...] The hinting in the font interacts with the rendering engine and anti-aliasing settings, wherever they may be at the moment."

What I'd like to know more about is how the hinting interacts with the rendering engine and anti-aliasing settings. If a typeface's hints want to rasterize an outline one way, but the rendering engine wants to lay the same bezier in a different way, which wins? What does the math look like? Are values averaged? Overridden?

The rendering engine has the final say on how it interprets the hints. Since there are multiple rendering engines, interpreting both outlines and hints in different ways and for different devices, the 'rendering concoctions' are pretty diverse.

I often wonder how many designers just run the Adobe auto-hinter and forget it because trying produce and test well-hinted cross-platform fonts seems to involve a tremendous amount of trial-and-error. I expect to see users demand great hinting as web fonts get rolling, but how many type designers have the time to hint fonts and test them on IE, Safari, Firefox, and various cellular platforms?

If you're talking about PS fonts, then running the Adobe auto-hinter is going to produce pretty much the same results as manually putting in hints: there may be occasionally different decisions for certain features, but major stems will get the same hints. The ‘big’ differences in PS rendering will be affected by font-level hints: standard stem values, blue zones and blue scale.

However, despite significant improvements in PS rendering (and the smaller size of CFF fonts), screen typography remains dominated by TrueType fonts. And the diversity of TT rendering models is much greater than that of PS: everything from Apple Quartz rendering completely ignoring all hints to b/w bitmap displays that rely on deep hinting down to the individual pixel level.

I often wonder how many designers just run the Adobe auto-hinter and forget it because trying produce and test well-hinted cross-platform fonts seems to involve a tremendous amount of trial-and-error.

Actually, if you prepare your fonts well for hinting such as setting good values in the standard stems, the alignment zones and the blue scale, the Adobe hinter does a fantastic job! It is a professional tool. Afterwards you can test the fonts and if you see some strange things you can manually tweak the hints to make the rendering better.

I know little about hinting, but from what I've heard TrueType hinting is such a complicated art that there are only a couple of people in the world who can hint hangul (Korean alphabet) TrueType fonts well. So if I decide to learn TrueType hinting and it takes me years to master TrueType hinting for hangul, what are the chances that it will all be for nought because those hints will have been rendered obsolete by then?

If the reason hinting might "become obsolete" is that device resolution will increase so much that the human eye won't notice a pixel here, a pixel there, I would argue that there will always be room for low-resolution technology. Will we allow this segment of typographic practice to suffer? Or will the selection of typefaces for this segment always be limited due to the overhead of hinting?

If the process of hinting is unnecessarily complex, we should criticize it. On the other hand, if it is what I think it is – many talented but autonomous professionals, working on their piece of the type rasterization assembly line – we should try to clarify it, or at least talk with these professionals (and listen when they talk with one another).

@Sii
Really? The patents expire this year? You're meaning the patents within TrueType that effect hinting (the ones that forced Freetype to come up with their own method), not the anti-aliasing done by Quartz, correct?

If so, and Freetype gets to implement that, that's a boon to free OSes right? That would be one step in making them not-so-crappy looking.

AFAIK the patented TT instructions are not useful. They have had no effect on the quality of anti-aliased type. OS X might ignore all hints, but in the end it is y hinting, like everything else. Learning to y hint is pretty much like learning to design type with strict alignments.

Like I said, AFAIK the patented TT instructions are not useful. In the context of teaching someone what TT instructions can do for AA type, the patented TT instructions have no effect on the quality of anti-aliased type. FreeType is not waiting to 'flurry' AFAIK.

The patented diagonal instruction should not be interpreted by feeble rendering, which is what sii's displaying, undoubtably on a windows machine. My guess is that the graphics state is not being properly managed in relation to the use of reference point settings during the positioning of certain diagonal stroke boundaries.

Sii, inform us of the age of this illustration, the source of the font and hints, please. :)

>Basically: to what rendering concoctions are our web type specs subject?
Basically, unless you 'demand' the web user alight on a standard CSS size, like 'medium', (so you can take over the sizing from there, if you can), you have no control over size.

>The (rendering) image is taken from the Freetype patents page referenced...
MS got screwed on Arial twice? ...the FreeTypers say these instructions are not an issue, and for this user's question, or any hinters issues, same goes.

I've always thought the Adobe Type 1 Font Format spec did a good job of explaining at least some of what's going on with Type 1 hinting.

I am biased, but I've always liked the Type 1 approach to hints. The key is in the word "hints"... they offer some advice about the dimensions of the font and its glyphs, which the renderer can use to make better decisions. TrueType instructions are cool (and there was a brief time many years ago when I did it "professionally"), but as many have observed, it's starting to look like a lot of hard labor for diminishing returns.

Even if one imagines displays becoming more common in higher resolutions, Type 1 (PostScript, CFF, whatever) hints still look useful. Remember, Adobe's initial concern was making type look good on early 300 dpi printers, not screens. Of course, those printers didn't have the benefit of grayscale antialiasing as screens usually do, but still...

The data you seek has never been sought. There was never any reason to do so until web fonts. It is a riddle, wrapped in a mystery, inside an enigma. (10 bonus points for naming the source of that last sentence.)

Have you noticed that Times New Roman looks crappy in IE9? (It's true, it does.)
(Unless it's got something to do with running WIN 7 in a VM on the Mac but I don't think so.)

I have been working heavily with Font Squirrel's TT autohinting - in collaboration with Ethan the past week - some useful approaches exist.
You can contact me through the usual channels but, as always, the Secretary will disavow any knowledge of our existence.

"My guess is that the graphics state is not being properly managed in relation to the use of reference point settings during the positioning of certain diagonal stroke boundaries."

Dunwich wrote:I often wonder how many designers just run the Adobe auto-hinter and forget it because trying produce and test well-hinted cross-platform fonts seems to involve a tremendous amount of trial-and-error. I expect to see users demand great hinting as web fonts get rolling, but how many type designers have the time to hint fonts and test them on IE, Safari, Firefox, and various cellular platforms?

That's exactly what you must do - test them in IE, Safari, Firefox, and Opera. The major mobile platforms, too, and find a middle ground.
And so far, the tools to easily do that with each little change, don't exist so it's like pulling teeth. (Unless such tools exist. Anybody?)

Times New Roman was never a good choice as a screen font. It ended up being a core font on computers because it was a core font on laser printers. The Windows version was brilliantly hinted for black and white full pixel rendering, but in antialiased and particularly subpixel environments you get greater fidelity to the outline forms, which in this case means greater fidelity to something that isn't well suited to being a screen type.

R.Fink> That's exactly what you must do - test them ... and find a middle ground.

Middle ground huh?

You have to write complete y hints for many glyphs in all fonts that are going to appear well on Windows up to 67 pixels per em until the screen resolution horizon is 300 as far as you can see ahead and 120 as far as you can see behind. You can only do a good job, no better or worse. If you do a good job, nobody notices or cares. And if you don't do a good job you get racked in the court of quality. Nobody wants to hear puny excuses about time and money, ya slackers. You can't steal hints and you can't autohint everything, so you've got to know something about hinting or cry. Oh yeah! and most fonts designed for print text don't work for web body text or smaller, so before you even start hinting, if you're planning on body type, start drawing like they were hinted already you lilly-livered sap-suckers. Go eat yer worms and like 'em, or go stand on the ruined wall and cry for mercy at the Gates who set loose the hounds of ClearType Hell.

With variations between platforms AND between user agents, too, testing, testing, testing, and looking for patterns - corridors of safe passage - seems the only thing to do.
From that, hopefully, will come best practices.

No. And, stupid me, of course they would. Although Berlow says "some".
I don't really know what I expected to see.
It just surprised me for some reason that a badly hinted TTF still looks like exactly that.

Now I'm wondering what it looks like with the hints stripped, delivered as a PS font.

Also, it seems IE9 beta is making multiple http calls - one for each font in the font stack. It isn't stopping at the first one it supports - like woff. A syntax thing? Not sure yet.

DB>..and that means with each font you use, you get 4 times as many apparent type styles!

A great feature!

BTW - I've been testing IE9 and can't make heads or tails out of what's going on.
IE9 pulls ALL the fonts in the font stack for every @font-face font-family. EOT, WOFF, TTF, every one listed. I could test for which one it's rendering, but this behavior is so whacked I'm wondering if I should just wait for the next release. I'm going to email the usual suspects and see if I can get answers.

Are they trying to collect telemetry on what @font-face fonts are out there while IE9 is still in beta and the gettin's good?

Also, I have come to a conclusion about IE's blocking anything less than "installable" in a TTF or OTF.