Your bottom row is a bit confusing because there is ClearTyoe implementation within GDI, and this is distinguished from ClearType rendering in DirectWrite (which applies a combination of x-direction subpixel AA and positioning and y-direction greyscale AA to both TT and PS).

In IE6 and IE7, PS fonts cannot be served as EOTs, so the blue line to and from these browsers is misleading.

This is a great reference, Miha. Thank you!

A little grammar niggle: "@font-face and its rendering" (no apostrophe needed). Actually a simple "@font-face rendering" would be just fine.

What about IE9?

Thank you both for your comments, I corrected the mistakes and made improvements. I described ClearType in GDI as subpixel filtering to distinguish between Quartz with true AA in both directions.

The rendering examples are Droid fonts, which are good screen fonts. Maybe I should also include one example of a good print font with good readability – to make it more drastic :-)

Miha, that's a great diagram!
It suggests that FF and Crome under XP do not do subpixel rendering at all; however, if CT is enabled in the system they do use it – maybe that could be reflected by a small comment in the left GDI box.

I added a line that other browsers respect OS settings. There are more possible scenarios, some users turn CT off – either in OS or in IE browser. If they turn it off in OS, they still see it in IE, but not in FF and others. And so on and on …
The problem is that I have no data how many users actually change the defaults, and how.

There is also a type designer who has all control how to display TT-based font in Standard mode: when and if to display it aliased/greyscale.

Web designers haven't got a lot control, but they can force grayscale AA with CSS filters – CT enabled or not (in some browsers).

The Mac also can Alias type at the user's option based on size, and can ignore the user options per font if the font is specifically named.

Cheers!

Great resource. You should really have a line with an autohinted serif (and perhaps one with no hints whatsoever) as well! After all, that’s what causing this headache.

I've been intending to do a flowchart something like this, to correct the common impression that there are some infinite number of results from the many combinations above. Nicely done!

Cheers,

T

There isn't an infinite number of results but in addition to the four above there's aliased type and the oops I'm a slacker I'll just default to Times New Roman :D I think the slacker is the browser not the web designer.

Frode: Yes, it would be more useful, but a good comparison of rasterisers is harder [for me] and I didn’t want to include it, although it is important. I only added some basic renderings as an example.

You probably already know about it, but here is the link anyway: The different faces of type by Karsten.

>....to correct the common impression that there are some infinite number of results from the many combinations above.

Lol, this doesn't count fonts.

Cheers!

@Miha: I din’t know about that one. Thanks!

As John Hudson noted, both subpixel AA and positioning are important for smaller text sizes. Windows GDI (and Uniscribe) only provide positioning information at pixel boundaries. The DirectWrite API allows both better subpixel AA *and* subpixel positioning, plus font sizes can be any arbitrary size (GDI limits font size to integer units).

Compare this waterfall test on XP with a DirectWrite-enabled browser (IE9 beta or Firefox nightly with DirectWrite enabled):
http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls-default....

On the Mac and with DirectWrite browsers you'll see a nice smooth waterfall.

One thing to note is that Webkit browsers don't do subpixel positioning, even when kerning is enabled. There's some odd code that repositions glyphs to pixel boundaries but hopefully that's just legacy code that will get fixed at some point.

Firefox4 will probably also use Cleartype rendering on XP, similar to IE7/8, with an option to revert to standard GDI. That patch landed today, it'll be in the nightlies in the next day or so.

>On the Mac and with DirectWrite browsers you'll see a nice smooth waterfall.

...and as proven as far back as 1987(!), at the bottom of any "smooth" waterfall, are a bunch of unreadable sizes. Readability down there at text sizes in low resolution comes from non-smooth waterfalls, (and it always will).

Cheers!

@dberlow

>at the bottom of any "smooth" waterfall, are a bunch of unreadable sizes.

You're quite right.
Which is why all my test pages position the small text in the middle of the screen.
As is the case with EOTFAST's File Integrity Test Page.

@jdaggett

Thanks for the info/analysis. Interesting.

@miha

Have you thought about putting your illustration on a t-shirt? Add some border radiuses maybe to mitigate the rectangularitis, put the illustration on the back of the shirt, and come up with a kewl catch-phrase of some kind for the front. It's a winner.

John (jdaggett): Thanks! I was wondering when/if FF will have CT rendering by default. Also, I am actually using Minefield (Firefox) with DirectWrite enabled for three months now. This is handy because the headlines of all those new web fonts render much better. But, unhinted fonts still look just like in GDI CT.

Richard: LOL!

@miha

I'm dead serious. I'd buy it and wear it!
Hah!

rich

Isn’t it a little too … geeky? Besides, there is a problem of accurately printing all those jagged pixels!
:-)

I just realized the title is somewhat misleading. This applies too web safe fonts as well. Anyway, I wondered if anyone could shead some light on what might cause this rendering:
The white opaque text is pixelated, while the same font at the same size just below use Cleartype.

Link would help. Maybe it is just an image, or Flash text using OS setting bypassing IE 7, 8, or …

No, it’s html text. I don’t know the url. A friend asked me what caused this.

Then it may be an IE alpha filter.

And as usual Typophile denizens completely ignore FreeType with its many platforms.
Particularly appalling considering how good it looks.

FreeType wasn't ignored, it's included under "Other" on that first graphic. Given that FreeType rendering is probably a fraction of 1% of all page visits on the web, that seems pretty reasonable to me. The chart and discussion doesn't explicitly cover Windows 2000 and ME, or IE 4 and 5, either....

Cheers,

T

I highly doubt that 1% number. Anyway, Droid fonts were made with Android and hence FreeType in mind.

For completeness’ sake, here’s how it looks

And if you want to have a laugh and to confirm your point, here are the FreeType rendering in use, depending on preference and what the vendor distributes. Some certainly below 1%.

Don't get me wrong. I think FreeType rendering is not only interesting, but sometimes quite good. But it may be a little while before FreeType rendering is any significant proportion of folks looking at web pages. I based my <1% comment on previous looks at stats from various web tracking services that claim to measure such things. Looking at the latest from NetMarketShare, they would claim about 1.7% for Linux and Java combined. Seems like StatCounter says something similar for Linux plus "Other." So I'd say that I probably understated it, but I have no doubt total FreeType usage is under 2%.

BTW, with these samples, it would be really helpful to explain what the various conditions mean and what causes them. What elements are controlled by user prefs, and what's their default? What elements are controlled by the vendor's choice(s)? What choices are the major vendors currently making?

Cheers,

T

Let’s not talk about percentages. Given the global number of people using the web, even one percent amounts to millions upon millions.

I’m glad to hear you’re interested. I’ll give you a fragmentary précis.

The FreeType library itself offers a range of render modes – each with tunable knobs – and among them some are disabled by #ifdef switches in the code. Some distributions compile those in and some don’t (for confused IP reasons I suppose).

For instance,

OpenSuSe

disables both LCD filtering and bytecode hinting interpreter (default is 5th sample).

Fedora

does use an LCD filter by default but it only offers the legacy type that is intra-pixel and looks horrible with light hinting. Hence they need pixel-snapping and use sample 3 by default.

Ubuntu

found out through user polls and outright flamewars that light hinting (unhinted in x, autohinted in y-axis) combined with a newer signal-processing LCD filter is preferred by most. Hence their default font rasterization is sample 1.

Android

I’m guessing from screenshots that they disable LCD filter and use light FreeType autohinter. Hence specimen 4.

monochrome is only used by maniacs

This variance is compounded by the many ways to configure all the knobs – from config files (”.fonts.conf“) to high-level settings panels (”Best Shapes“, “Best Contrast”) – and the many different desktops and graphics libraries in use.

I’m assuming that browsers all obey the global desktop setting for their font rendering because if they didn’t they would be spammed with bug reports until they do. When it comes to taste and preference there are two dug-in camps. The ones who prefer the signal-processing look and the ones who hail from the olden Unix (or Windows) days and insist on pixel snapping or superhinting.

I think the former approach is the way forward, in particular because web fonts look good in it no matter what the format or feature set of the font is. The autohinter with the LCD filter is excellent, most robust, readable at small sizes and usable on scalable canvasses.

The only thing lacking at the moment is subpixel positioning. Still getting odd kerning in waterfalls and animations due to integer pixel effects.

These are the options exposed in the config file.

  antialias Bool Whether glyphs can be antialiased
  hinting   Bool Whether the rasterizer should use hinting
  hintstyle Int  Automatic hinting style: light, medium, full, none
  autohint  Bool Use autohinter instead of normal hinter
  rgba      Int  unknown, rgb, bgr, vrgb, vbgr, none - subpixel geometry
  lcdfilter Int  Type of LCD filter: lcddefault, lcdlight, lcdlegacy


First, thank you for taking the time to explain some of the intricacies of FreeType's rendering options. Fascinating stuff!

I do think that knowing the relative numbers of users is important, and things such as their geographical distribution. For example, if we were looking at rendering of Chinese or Indic characters, I'd be looking at the relative use of different rendering in those regions, and I might have very different ideas about the importance of considering FreeType's rendering.

For what it's worth, I share your preferences for the new sub-pixel filter. I think I'd have to see a wider range of fonts and sizes before I would want to venture a preference between light and full auto-hinter, though.

Speaking of the auto-hinter, for other folks reading this thread, I think I should explain something in the background here that could otherwise confuse some of them (I know *you* know this, and so do many of the likely readers, but I doubt everyone is aware of it)... "hinting" means something slightly different in this context than it often does elsewhere.

At the broadest level, though, the meaning is consistent. "Hinting" is additional code, applied to an outline font, which influences or even controls what a rasterizer does when rendering the font outlines to pixels or dots.

In the classic usage, the hinting code is created as part of designing or compiling the font, and the hinting is an integral part of the font file.

But what FreeType does is to ignore any hinting code in the font file, automatically hint the font on the fly, and then use that new hinting as input to the rendering of the font. Given that the FreeType auto-hinting is better than that in many (probably most) fonts out there, the results are likely to be reasonable. Especially so given that FreeType's auto-hinting is presumably tuned to work as well as possible with FreeType's rasterizer.

This is an important distinction, because a lot of people who develop fonts or web font services hang out here. The main take-away for them is that with FreeType, the hinting in the font is irrelevant. What matters for FreeType is the nature of the design and the quality of the outlines.

I'd also be curious to see how equivalent outlines in perform in FreeType rendering when the variable is whether they are OpenType CFF vs TTF. That could be very interesting....

Regards,

T

P.S. (edit) I welcome any corrections if I have misunderstood what FreeType is up to.

This is an important distinction, because a lot of people who develop fonts or web font services hang out here. The main take-away for them is that with FreeType, the hinting in the font is irrelevant. What matters for FreeType is the nature of the design and the quality of the outlines.

You are spot on with this insight. And it surprised me that just that work went into crafting the next Ubuntu system font.

The only two reasons I can think of for commissioning the hinting was to make sure that it would look acceptable cross-platform when used as a webfont on corporate and community websites (just the topic of this thread) and to please the few users savvy enough to edit config files and enable the formerly ”infringing“ TrueType byte-code interpreter.

No idea if that’s money well spent.

I would guess that TrueType and CFF fonts are rastered identically. Are there examples in the wild that are straight conversions that I could use?

@towolf:
I would guess that TrueType and CFF fonts are rastered identically. Are there examples in the wild that are straight conversions that I could use?

Linux libertine comes in both CFF and TTF flavoured, you may check it. I don't recall any difference in rendering between both, but I never paid close attention.

@towolf: I'd also be more than happy to do a quick conversion for you, of any open source font you care to name. Actually, I might do some outline attacks anyway, because what would be interesting to me would be to see if outlines optimized for a given outline format do any better than outlines just converted to that format. I'm thinking particularly what happens when one makes TTF from PS outlines without clean-up, or even (if one starts with non-cleaned-up TTF outlines) going the other direction.

Assuming you're willing to sink some more time into doing the screen shots of course! :)

Cheers,

T

I’m happy to provide samples for anything you throw at me. In the format you wish.

Khaled’s suggestion was a good one since the fonts are only a download away.
Apparently there are some differences both in outlines and in kerning. I have no idea if that is due to the fonts themselves. I suppose the tool used is FontForge.

This should be animated at 1 Hz.:

and difference view

And since this thread is about @font-face, here’s your blog both in 100% zoom and zoomed out (w/ Ctrl-Minus). Browser is Chromium 6. It certainly has worse font support than Mozilla at this point. In particular text-rendering: optimizeLegibility; where they enable kerning tables is kinda broken.

You can see how robust it is even at miniscule sizes.

Tom Phinney:

>This is an important distinction, because a lot of people who develop fonts or web font services hang out here.

I'm with you so far...

>The main take-away for them is that with FreeType, the hinting in the font is irrelevant.

Say what? With FreeType, the hinting in the font is as relevant as the FreeType implementation allows.

>What matters for FreeType is the nature of the design and the quality of the outlines.

... and this is not true of Cleartype or Quartz?

Thanks for the truly perplexing paragraph.

Cheers!

In particular text-rendering: optimizeLegibility; where they enable kerning tables is kinda broken.

I've found that optimizeLegibility makes text invisible in webOS and breaks font-variant: small-caps in some browsers, too. Could you detail what you saw in Chromium 6 Linux?

@David B:

>> The main take-away for them is that with FreeType, the hinting in the font is irrelevant.

> Say what? With FreeType, the hinting in the font is as relevant as the FreeType implementation allows.

True... but are any of the major implementations using the bytecode interpreter? I have the impression (and I'm open to correction) that pretty much everybody these days is using some version of the autohinter tech.

>> What matters for FreeType is the nature of the design and the quality of the outlines.

> ... and this is not true of Cleartype or Quartz?

I might have more clearly said "the only thing that matters" instead of "what matters" (that is, hinting doesn't matter). This is equally (or more) true for Apple's Quartz rendering. But we've covered that ground before on Typophile.

Of course the nature of the design and the quality of the outlines always matter for rendering and legibility. In the pre-ClearType and Mac Classic days one could use TT hinting to bend the outlines to one's will, but not so reliably today!

Cheers,

T

I've found that optimizeLegibility makes text invisible in webOS and breaks font-variant: small-caps in some browsers, too. Could you detail what you saw in Chromium 6 Linux?

I think what you refer to is this: http://crbug.com/51973

I’m seeing span-like HTML elements that run into each other and overlap. It looks as if the calculation of the widths of those happen before the adjustment by kerning is taken into account (or vice versa). The thing is, a page reload usually fixes things. Could be a sporadic Heisenbug, or a race condition.

The most reliably broken page I’ve seen is one where the text block is unfolded by animation (again, fixed by toggling it):