In this context I don't think "designed for the Web" makes sense - you design and hint for specific rendering environments, but today Web pages are rendered is a bewildering and ever changing set of rendering environments, resolutions, and user preferences.

Paul, for your testing you may want to bookmark http://browsershots.org.

Also put such thing as different monitor gammas on your list of variables. In my experience this can make a dramatic difference in appearance of (even a hinted) font.

@sii

Excuse me but....
>you design and hint for specific rendering environments

Well, what are those? IE/GDI rendering? WPF/Silverlight?
Flash?
Look, I know your job requires that you look at the big picture. And I know how daunting and complex that must be.
But what Paul is talking about is browsers.

How come an OTF that looks perfectly fine in FF - using standard Windows API's - can't even be converted to an EOT?And when you do convert the original OTF to TTF and create the EOT, it looks like crap?
(One of the things I"ll be exploring over the course of the next year is the remedial work needed to mitigate this problem. But really, it should be MSFT offering the solutions. Not type designers or web designers.)
What does MSFT intend to do about in the short term?
Do we need a Google plug-in for this? Or one from Mozilla, akin to the plug-in that enables the Canvas tag?

Oh, and BTW - Happy Holidays, Si.

@paul

IMHO - it's going to have more of an impact right now, to make a list of what you shouldn't do, rather than what you *should* do.

In other words, for the moment, avoid this, avoid that.

And Happy and Healthy to you, too

rich

@Simon I hear you, although some typefaces are "optimized for the web" ... and some type is clearly superior on-screen. I think what we're looking for is a typeface made for use on screens.

@Alex Thanks for the browsershots link. We may use a service like this, but however we snapshot the way type renders we will want to be precise in knowing the "prefs + browser + OS" details of each instance, and be able to rely on the screenshot for accuracy.

To Paul's point, we're looking for a few typefaces — well made CFF OTF and TTF, and then something produced more casually. What we want to end up with is something along the lines of Karsten Luecke's excellent rendering samples.

Karsten used:

1. CFF OTF: Adobe Arno Pro, Adobe Minion Pro
2. TTF: Microsoft Corbel, Microsoft Constantia

We could use these same typefaces ... just wondering about other suggestions.

Sii>but today Web pages are rendered is a bewildering...

I hear you too. But bewildering, or B.hilldering? :)

Come out of the bewilderness. There is no effective rendering heavier than Adobe's, nor lighter than MS' ClearType, there are only five main options for hint interpretation, 2 contour formats and only a 19 pixel per em, or so, spectrum of trouble for subtext, text and subheads. And even if the typesetter doesn't stand still, eyeballs are still the target — how much more variation can there be before the be wilderness begins to look intentional?

Paul>We think we need three typefaces:

Typeface families, I assume you mean.

>1) A CFF OTF font, designed for the web, with hinting.

We will not know what one of these looks like until IE-next is deployed with DirectWhatever.

2) A TTF font, designed as TrueType, designed for the web, with hinting.

I'd use Verdana. Then later you can try an autohinted CFF version with IE next.

3) A more amateur font, maybe something random from Font Squirrel?

Pick 'em.

With all due respect, I don't think you need us.

Rich > ...it’s going to have more of an impact right now, to make a list of what you shouldn’t do, rather than what you *should* do.

Impact on what exactly? Creating a web site including text that's interoperable via @fontface is a list of lists of what one must do.

Cheers!

Cheers!

and more Cheers!

@dberlow

Rich > ...it’s going to have more of an impact right now, to make a list of what you shouldn’t do, rather than what you *should* do.
Impact on what exactly? Creating a web site including text that’s interoperable via @fontface is a list of lists of what one must do.

Can I get a do-over on that comment? Dumb, yes.

That said -

1) A CFF OTF font, designed for the web, with hinting. We will not know what one of these looks like until IE-next is deployed with DirectWhatever.

Misleading. To name one browser - Firefox 3.5 - there is no problem rendering an OTF CFF font (using standard Windows API's as I understand it, but I am not sure.)
The font I'm looking at right now is Galaxie Copernicus Medium from Village and it looks excellent from about 16px size on up. (Below that size, there are some issues. I wouldn't use it for body text. Avoid For Body Text)
It also might look just fine and dandy converted to a TTF, but I don't know if the EULA allows it and the last people in the world I want after me are The Village People.

As far as knowing what an OTF CFF font is going to look like in IE Next, well, I don't think it's a stretch to judge based on the WPF samples that John Hudson and Thomas Phinney are working with/on.
http://www.typophile.com/node/64451

Also, in IE Now (IE 6, 7, 8) it's certainly possible to see how crappy (or not) an OTF CFF looks simply by bypassing @font-face, installing the font in the OS, and viewing it from there - called from a typical CSS font stack.

We need to see the good, the bad, and the ugly.

Have at it, guys.

rich

For the most part, browsers are not really the variable, but OS rendering settings are. (Special cases: IE 7 has its own unique ClearType-on override, and Safari for Windows can invoke Mac OS rendering modes, as it has them built into the browser.)

In order to get the most useful results, you need to further nail down *exactly* what your experimental question is (or questions are). Currently the high-level question is still a bit vague, making it hard to operationalize the experimental question. You want to "understand" the font rendering-in-browsers space, but what's the goal of that understanding? Who might use the results, and how?

I also submit that it is likely that somebody has already done this sort of research. Probably several distinct entities/groups. It's possible that one of them might be amenable to sharing at least some of their results rather than see a bunch more people spending time on it, if you get to the point of really running tests.

Regards,

T

David: There is no effective rendering heavier than Adobe’s, nor lighter than MS’ ClearType

How are you defining heavier and lighter? By stroke width (amount of pixels/subpixels coloured) or by stroke density (darkness of pixels) or a combination of the two? On my system and screen combination, Apple's Quartz rendering is by far the heaviest in terms of stroke width but not in terms of stroke density; ClearType is heaviest in terms of stroke density but lightest in terms of stroke width. Adobe's Acrobat rendering has lighter stroke width than Apple but lighter stroke density than ClearType.

Yes John, I forgot about Windows Safari... but the point remains the same: because of those pesky eyeballs I talked about in Mexico, the standard could only become so useless, (breaking the direct chain of good fonts between type designer and reader), and then people started to wonder about the intent of its polluting forces. And try not to compound rendering and scaling into 'a problem', if possible.

Yes Thomas, we have done a lot of research. Here is some sharing; Minion Pro and Myriad Pro in OpenType CFF render pretty well down to 9 pixels per em, and just fabulously at 12 or more, sometimes.

No Rich, "having at it" is for those who have not had enough — and I think MS has had enough too.

Cheers!

For the most part, browsers are not really the variable, but OS rendering settings are. (Special cases: IE 7 has its own unique ClearType-on override, and Safari for Windows can invoke Mac OS rendering modes, as it has them built into the browser.)

Right. Thanks Thomas, your clarifications are always helpful. I think even with these few special cases, there's cause enough to have a standard, public representation of web type rendered in each particular setting.

In order to get the most useful results, you need to further nail down *exactly* what your experimental question is (or questions are). [...] Who might use the results, and how?

Well, first of all we want to provide the design, type, and web development community with a single reference for screenshots of web type in its various rendered states. That alone would be an achievement.

What happens as a result of this reference is anybody's guess.

• Can designers hoping to use @font-face fonts on the web use this reference to judge whether it's aesthetically okay, and legible, to do so? Definitely.
• Will viewers of this reference agree that some particular rendering is "worst," once they're all side by side? Perhaps these folks will organize themselves and complain.
• Will developers of the rendering technology suddenly see their work in a different light? I doubt it, but who knows.

I also submit that it is likely that somebody has already done this sort of research. Probably several distinct entities/groups. It’s possible that one of them might be amenable to sharing at least some of their results rather than see a bunch more people spending time on it, if you get to the point of really running tests.

That's a great point. Someone must have.

Our Type Rendering Twitter account has aroused the interest of some special people already. Where else would you suggest we make our efforts known, to get the attention of these groups you have in mind?

If someone else has done this research, I have no doubt it can teach us all and save the Type Rendering project time and effort. But I can also understand the competitive advantage in having expert knowledge about web type rendering.

Maybe our effort will go far enough that more thorough, more expert researchers feel comfortable sharing—perhaps to show how much more there is to what we're discussing, perhaps to correct our mistakes ... but any way this reference develops, I think it will be invaluable.

We're building a feature for Typekit that might help here. In a couple weeks, we'll launch screenshots of every font in our library in every browser that supports @font-face across platforms. Clicking through them gives a really good idea of all the different things that happen to fonts when rendered in browsers in the real world. All the systems we're rendering on have out-of-the-box default settings — we've not yet done things like changing ClearType settings.

In the screenshot below, you can see we've organized all the browsers by operating system. (The ones grayed out are screenshots we haven't finished rendering yet.) You'll be able to click through them rapidly for comparison. Later, we'll make a bundled zip file of all of a font's screenshots so you can bring them into Photoshop and compare as layers, or whatever. We're curious what other info — like font metrics and file format — might be interesting in this context. Any ideas?

We're testing the feature now, and would love some experienced eyes on all this. If you have a Typekit account, send me an email (jeff at typekit dot com) and let me know what address you used to sign up, and we'll give you early access.

Jeff: as mentioned before, the OS is not the variable, the rendering mode of the OS is the variable. Your screen shot shows a huge number of combinations that will produce identical glyph rendering on screen.

Cheers,

T

Jeff, this new feature looks sharp! I would love to take a closer look.

Even if there is no difference in type rendering between, say, Windows 7 + Firefox 3.6 and Windows 7 + Firefox 3.5 (which I believe to be true based on Thomas' thoughts here, but which I have not seen for myself), I still think this Typekit feature is useful. Just to be able to toggle through different operating systems is great! And it's an action you take after you've narrowed your search to a particular typeface ... seems like it will be a very natural, helpful feature.

If the only differences in rendering within a particular OS are setting-specific, perhaps screenshots from such browsers could be taken with those settings enabled? Not a "worst" case scenario for each browser, but along those lines. Sort of a "most different from OS" case scenario.

>...the OS is not the variable, the rendering mode of the OS is the variable.

Well, I think it is safer to say that the option of which version of OS the user purchases, is one variable
and then the browser chosen by the user, having an option of font managements to employ, is another variable
and then the option of which rendering mode within that OS is chosen by the user, in the OS UI, is another
and if that choice has effect according to the choice of which OS font management the browser made, is another,
... and something happens unique to each size of each font, that someone might like to pre-examine before publishing becasue of that variable stack.

So, I'm not sure how you're certain that the OS, (and its version) is not a, or, the variable, or that the rendering mode of the OS is always a variable?

An Andre the Giant-sized one thumbs-up Jeff!
Is the underline on an option in some view menu?
Can there be a compare to Verdana for sizing to the em?
Can we get a compare of a single size across browsers?
Can't wait to see the whole ball of wax!

Cheers!

.
ChrisL

Great idea Jeff. This really gets the wheels turning... David, your suggestions are spot on as well. Good stuff!

In regards to Chris's main point, I concur.

I just dotted the eye so that Richard can cross the Tea :-)

ChrisL

Straight to the point, Chris ;-)
Following this topic.