>P.S. Not optimized yet for Internet Explorer.

IE8, Win 7...

IE9 preview, Win 7

How do you plan to optimize it?

Sii,

Thanks for the screenshots. I was thinking more of the dreaded monster that is IE6. IE7 does not work either.

There appear to be some fairly subtle alignment issues in 8 that I would prefer to "optimize."

Jarrod

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 interesting how poorly IE renders the Typekit font. You can zoom in and out quite a way in Firefox (OS X), for example, and it looks really good.

On Windows, Firefox is planning to adopt the same method as IE (9). Let's hope all of your site vistiors are using Mac OS and Firefox.

>Maybe changing the size a px or two might solve this, or maybe not.

You've used the web, or not? This is not something one can tell users with any sort of ease.

> You can zoom in and out quite a way in Firefox (OS X), for example, and it looks really good.

I see the same in Safari, it's not FF, it's the Mac.

Cheers!

Sii,

Are you really giving me a hard time because the cross-bar of the capital B isn't rendered well on Windows?

> P.S. Not optimized yet for Internet Explorer

It doesn't look that good in the Firefox on Windows either:

>Are you really giving me a hard time because the cross-bar of the capital B isn't rendered well on Windows?

No just making the point that Mac FF is likely less than 1% of Web users.

Anyway on my machine...

Chrome...

FF...

Safari...

Based on these I think IE9 looks best, IE8 second best.

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.

@begsini

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.

It looks like maybe this font is CFF? That would explain the lousy rendering in Win Firefox.

If there were a single CFF font it wouldn't make it into IE via @font-face? There's more than one font for sure, probably CFF for FF, Chrome and Safari and TTF (via EOT) for IE.

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

@Richard

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?

@Sii

I used Firefox as an example. The pages render beautifully in FF, Chrome, Safari, and Opera on OS X. It seems to me that IE on Windows is the only combination really suffering from inadequacy here.

Fair enough. So what's the plan? Assuming 50% to 60% of visitors to your blog are getting an inadequate experience, are you okay continuing to pay for Typekit's service long-term?

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

[begsini, you probably want to put something in your CSS to control the background colour of your site. I'm seeing it with the off-white background I use as a default for my home page.]

And while you're at it you can put something in your CSS to render Arial for Windows users and Ratio for the rest.

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.

Cheers!

@begsini
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?

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.

Hi everybody,

I'm Type Manager for Typekit. This is a great conversation!

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.

There's a lot to be excited about.

Jarrod, your blog looks great. I just added a screenshot to Typekit's Flickr pool.

Tim - great to see the Flickr group. Tag up those images with the fonts being used!

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

I second that, Alex.

>The process of detecting inconsistent rendering is easy to automate,

We're all ears, please explain.

>...it still takes only few seconds to manually check how all font styles look in all browsers[...]

...for all characters and sizes, and all user preferences. I get (for 256 chars x 30 sizes x just 9 browsers x 3 user preferences =) over 200,000 glyphs to check per style, 800,000 per family of four.

Now I ain't sayin' we ain't doin' that, but the question is, are you talking about earth seconds?

Cheers!

>> The process of detecting inconsistent rendering is easy to automate,
> We're all ears, please explain.

Only since you (plural) asked nicely :)

Ratio (from sii's shots):

1. In Safari

2. In Firefox

3. Arithmetical per-pixel difference between #1 and #2

4. Same as #3 but desaturated and pure black removed

5. Histogram of #4

.

Museo Sans (from Typekit's type tester):

1. In Safari

2. In Firefox

3. Arithmetical per-pixel difference between #1 and #2

4. Same as #3 but desaturated and pure black removed

5. Histogram of #4

.

And once again, just the histograms, side by side:

.

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.

Cheers,

T

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

Perhaps having a way for the community of subscribers to rate fonts, and identify specific rendering issues might be one way to reduce the testing overhead.

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

Cheers!

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.

> Tim's

Alex's... not that it matters

Oops. Sorry. Fixed. Thereby rendering both this post and the preceding one obsolete. :)

For reference, an old (and long) thread: What is Typekit?

>What Alex's quantative comparison shows is, as he said, inconsistent rendering,

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

And?

Cheers!

And I guess we're agreeing again.

Time for a new topic then.

.

@tim ahrens
I 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.

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

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

...These are the voyages of the Starship Enterprise...

Sorry, couldn't resist. ;-)

>At least by most web author's standards. Even for body text.

with this disclaimer the autohinting holy grail is slightly more plausible.

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.

At least by most web author's [sic] standards.

Until I see some indication that the typographic standards of web authors are significantly higher than those of scrapbookers, I will remain unimpressed by this criterion of success.

"Until I see some indication that the typographic standards of web authors are significantly higher than those of scrapbookers, I will remain unimpressed by this criterion of success."

Brilliant! Please Tweet that!