In IE8 the crossbar of the cap B doesn't work at this particular size. There are likely other characters in the font that exhibit similar issues. Maybe changing the size a px or two might solve this, or maybe not.

It's important to note that the performance of fonts on Windows has much more to do with the design and hinting of the fonts than it has to do with Typekit. My impression is that Ratio is not hand-hinted the way some fonts on Typekit are.

If you use Typekit, you sign a EULA and agree to an arrangement that prevents you from improving the font. Or making it worse, if that's your druthers.
Plus, you don't get the font to install either in the OS, or on a pre-production server.

How a designer can take responsibility for the typography of a site under those conditions beats me. But if you enjoy swimming with a straightjacket on, good luck. Stick with it.
In its effort to prevent "casual download" by visitors to your site, the "service" has no choice but to prevent you from creative tinkering.
The primary responsibility of the service, first and foremost, is to serve fonts under conditions acceptable to those who contribute them. Your needs are secondary. (And it's a take it or leave it proposition, from all I've seen and heard and experienced.)
That is simply the nature of it.

If you want the freedom to "optimize", why don't you seek other options?

Richard: The primary responsibility of the service, first and foremost, is to serve fonts under conditions acceptable to those who contribute them. Your needs are secondary.

The way I look at it, Typekit and similar services are trying to create a market by making a product available in a way that is acceptable to the makers of that product. When a market is established, then it functions as a market, which means that consumers can make choices based on quality, options, etc.

There are fonts being made available through Typekit and other services that I wouldn't consider to be of high enough technical quality for web use, and I am quite sure that foundries licensing WOFF fonts will also be offering fonts that I don't think are fit to purpose. That's what happens when people rush to market.

>Plus, you don't get the font to install either in the OS, or on a pre-production server.

It's clear, I think, that there's more than "one font" being used here. Compare the consistent rendering of Arial across the browsers (GDI) vs the completely inconsistent rendering of the @font-face fonts. And that's just Windows. So Typekit would need to provide and provide tech support on multiple fonts.

Yes, and the two flavours of font suggests that the original font from the foundry is CFF. I'm interested to know whether the TTF conversion was performed by the foundry or by Typekit. Given that it is a conversion and probably not subject to a lot of manual hinting work, the IE9 rendering is all the more impressive (there are problems with the crossbars greying out, but that could be fixed with better hinting).

Sorry for the confusion. I was most certainly not suggesting I intended to do anything to the font. The only optimization was with respect to the IE browser on the Windows operating system, and how either the sidebar or posts don't even appear in the right place on the page, or things which align properly in all other browsers don't align.

I don't know what you mean about swimming with a straightjacket on. At least by using Typekit, I have the opportunity to use a font that I like- what's my other choice? Specifying "sans" or "helvetica, arial, verdana?" That's better? Really?

@begsini - so basically you are OK with big chunk of your visitors seeing a subpar version of your site? Have another look at sii's screenshots, it's not just the IE that has rendering problems. All Windows browsers do.

Why have you chosen Helvetica for the body text? If it renders correctly, Ratio would be quite suitable for that. If it doesn't then it isn't suitable for headlines either. Besides, these two typefaces are stylistically not a good combination imho.

@richard fink – Plus, you don't get the font to install either in the OS, or on a pre-production server.

This isn't quite true, you can specify multiple domains in each Kit's settings to allow for development. For instance, with the "Love Made Visible" site I've specified:pomegranita.com,wordpress,localhost

Which allows me to test locally either with the 'wordpress' domain that I've entered into /etc/hosts (using Virtualhosts on Apache, so I can create multiple sites on the same machine) or just plain 'localhost' if you have a single local website instance. Equally, I could use beta.example.com or any other domain if it was to be staged wider.

Richard Fink,
I have read many of your posts and I do not understand what your perspective is: Are you a type user? Are you a type maker? Are you a type designer? Web designer? You don't seem to know much about the technical foundations of fonts in general. Are you producing webfonts? Based on which source? For your own use? As a service for someone else to use?

After all these years of suffering through pale and pathetic fonts, when given the Freedom of Typekit people choose pale and pathetic fonts and lead enough to drive another line in between. Again and again, this is what we see. Chickens or sheep?

>...an arrangement that prevents you from improving the font.

I seriously doubt that it's Typekit preventing you from improving the font, Richard.

@begsiniI don't know what you mean about swimming with a straightjacket on. At least by using Typekit, I have the opportunity to use a font that I like- what's my other choice? Specifying "sans" or "helvetica, arial, verdana?" That's better? Really?

If that's the font you absolutely must use, and only Typekit has it, like I said, stick with it. But yet you seem to be having problems.

If you want to shop around you could check out Font Squirrel, Font Spring, Kernest, the League Of Movable Type, SIL, and a multitude of other font providers that will allow you to make changes as needed.

That's all.

@tim ahrens

On this thread, my perspective is that if you're struggling to get something acceptable from one vendor, you shop around.
Simple. I mean, you can stare at screen shots all day long and say, "Why? Why? Why?" but in this case, locked in as Begsini is to what Typekit provides, what are you going to do about it?
Hey, if Begsini wants a "service"? He can try Ascender. Fine by me. It's his web page, not mine.

@pause
Thanks for the information about using Typekit to view the font somewhere besides the approved domain. The instructions don't seem very straightforward, they don't seem very accessible to the non-technical, which has always been Typekit's main selling point (to customers at least), but I'll check it out.
It's been awhile since I tried Typekit.

With regard to rendering quality, Stephen is correct — the performance of typefaces served by Typekit generally reflects the web-readiness of the font files we receive. We're working on some administrative tools right now that will help us spot rendering inconsistencies and aid discussion with foundry partners as we consider including new type (or revised type) in our library.

On the technical side of things: unless we receive TrueType files, we make them. In our experience, CFF fonts don't render as well as the same fonts converted to TTF. And neither Internet Explorer 6 nor 7 will load EOT files made with TTFs. If we do receive TrueType files from our foundry partners, we use those — and they usually look best, manual hinting or not.

John, I agree, IE9 looks wonderfully impressive.

Sii, John, Alex, as for rushing to market and coping with subpar Windows experiences at the present time, you make fair points. Windows rendering isn't great for some web fonts right now (though for others, under the right conditions, it is great). But people choose Typekit for lots of reasons.

Typekit has brought the creative freedom of type choice to a large, eager audience and has catalyzed (or at least encouraged) browser makers, type sellers, type designers, web designers, and businesspeople to take web typography seriously. These benefits alone are worth the sacrifices of getting involved early.

Stephen's suggestion about rendering "Arial for Windows users and Ratio for the rest" is prescient. My colleagues at Typekit HQ have a long list of features in the development queue, one of which is the ability to toggle kits off in certain environments. You can see early stages of this technology present in our experimental iPad support.

Still, features and business aside, the aspect of Typekit's early presence in this market that I most respect and value is the success with which it continues to define the relationship of type within existing, standard web design practices.

Typekit provides a mental model that did not exist previously — for dealing with font files, styles and weights, character subsetting, and more, as well as the relationship between these new-to-web things and things that web designers already understand, like file size, CSS font properties, and markup.

Linking a font to a website can be simple, like adding a CSS background image. But when you want to use different styles of a typeface, use several typefaces, or attempt to keep current with browser support, things can get awfully hairy. Some people would rather these things be dead simple. So they use Typekit.

The excitement and freedom of this mental model, (not to mention of course, the idea of many visitors seeing beautifully drawn type) is what folks weigh against caring that their Windows visitors' text might seem as decrepit as nearly every other aspect of Windows users' personal computing experience.

Even then, as Stephen said, not all fonts render poorly. Only some. Typekit presents this information to users via a Browser Samples tab so they know what to expect. And in cases where type designers improve the Windows rendering of their fonts, we upgrade our library. That means any website using Typekit to serve these fonts will see an immediate and automatic improvement in rendering.

>We're working on some administrative tools right now that will help us spot rendering inconsistencies...

This sounds like an essential feature to have.

More and more often I see sites whose typography looks like a butt, and sure enough every time it happens to be designed by someone with a Mac and @font-face directive. They are just ignorant about rendering issues and don't realize their site looks awful to a half of their visitors. Visitors that they end up loosing for a reason that stays a mystery to them.

Do not get me wrong though - I think Typekit is a great and timely idea which is executed well. I just wish you would be more open about major usability issues that it has at the moment. These issues are not your fault, and they can be fixed by working with foundries, but they must be clearly and visibly disclosed for your users to be consciously aware of them.

The process of detecting inconsistent rendering is easy to automate, and detected fonts should be clearly marked in your font library for all users to see. And even if you don't have this detection automated, it still takes only few seconds to manually check how all font styles look in all browsers, so the tagging for rendering inconsistencies should be a part of your approval process for a specific font.

The one on the left basically shows a lot of "wobble" between the characters, and the one on the right shows virtually no difference as all spikes are near zero. Telling these two cases apart can be automated with ease, do you not agree?

>> ...it still takes only few seconds to manually check how all font styles look in all browsers[...]
> ...800,000 per family of four.

For all practical intents and purposes it should be sufficient to check how "Quick Brown Fox ..." renders at, say, 15px size, not all glyphs at all sizes. Just do a quick visual check to spot problems like those with the Ratio. This will be a major step forward compared to not doing anything at all.

pankrat wrote: For all practical intents and purposes it should be sufficient to check how "Quick Brown Fox ..." renders at, say, 15px size, not all glyphs at all sizes.

I disagree rather strongly on that. I have seen many many cases where a given ppem size is just fine, yet going up or down one pixel is a problem. If you're really concerned about rendering quality, you need to check a range of sizes. Also include numbers in your test.

> I disagree rather strongly on that. I have seen many many cases where a given ppem size is just fine, yet going up or down one pixel is a problem.

Sure, OK. No need to disagree strongly :) What I meant to say was that even a cursory visual examination of a small representative sample (instead of complete 800k of glyph variations) would go a long way.

>For all practical intents and purposes it should be sufficient to check how "Quick Brown Fox ..."

I see! Okay, so that's brilliant.

I think the issue we face in lower resolutions and smaller point sizes is that a quantitative comparison as you show is not fine enough for the kinds of decisions that have to be made on those smaller sizes. I.E. not every pixel is of the same importance 'down there' in the small sizes, as Thomas implies.

So, your Ratio example can (should) be solved as you say with a cursory visual examination, that ideally results in a recommendation to the user.

>Perhaps having a way for the community of subscribers to rate fonts,

Agreed. And the EPAR is the chalice intended to hold this precious information, regardless of whether the font is foundry-rated as all commercial font properties should be, or community-rated as most free or share-me fonts would like.

David: I think the issue we face in lower resolutions and smaller point sizes is that a quantitative comparison as you show is not fine enough for the kinds of decisions that have to be made on those smaller sizes.

What Alex's quantative comparison shows is, as he said, inconsistent rendering, i.e. it indicates that two renderings are different and how different they are. It doesn't indicate which is better, let alone which pixels within either rendering are important for legibility.

Well, it depends how you are defining rendering. Do you mean all the process from outline to bitmap, or just from the transformed outline to the bitmap?

I said; "...the issue we face in lower resolutions and smaller point sizes is that a quantitative comparison as you show is not fine enough for the kinds of decisions that have to be made on those smaller sizes"

You said; "It doesn't indicate which is better, let alone which pixels within either rendering are important for legibility."

@tim ahrensI have read many of your posts and I do not understand what your perspective is
Flattering. Truly, with no disprespect meant, that means I'm probably on the right track.

@tim brown
Hi. Hope all is going well.

@apankrat
I like your approach. Not sure where it can take us, but real interesting.

@johnhudsonThere are fonts being made available through Typekit and other services that I wouldn't consider to be of high enough technical quality for web use, and I am quite sure that foundries licensing WOFF fonts will also be offering fonts that I don't think are fit to purpose. That's what happens when people rush to market.
To my eyes, I see a lot of crap, too. But...
1) As long as the presentation includes in-browser specimens, everything is up-front and if somebody chooses a font that, to me, stinks, that's their choice. It's when someone's being asked to choose a screen font from some enhanced Flash representation or generated image that's unacceptable.
2) As for rushing to market: except in rather unusual cases where getting it right the first time is crucial to success, all of the advantages lie with those who get into the market as early and as visibly as possible. These new services that are springing up like daisies now are also-rans. As soon as I met them in Atlanta, I immediately knew that the guys from Typekit "got it" as far as the marketing piece.
Rushing to market is almost always the name of the game.

BTW - there's some very interesting work being done with file conversion and autohinting. To the point where, it seems to me, there won't be much of a problem soon.
At least by most web author's standards. Even for body text.

Rich: …all of the advantages lie with those who get into the market as early and as visibly as possible…

Some of us want the advantage to lie with the reader.

To me, the rush to the web fonts market looks pretty much identical to the rush to the desktop publishing market, so I'm expecting a lot of bad typography and difficult to read text, and the better part of twenty years to clean up the mess. It isn't good enough to say that ‘if somebody chooses a font that … stinks, that's their choice’, because typography serves first reader, then the text, and only then the author/publisher.