With new media designers now ace the challenge of trying to control the way their type looks across various browsers and operating systems while keeping a cohesive look with all of their print material.

Different media (screen/print), viewing formats (projector/laptop/phone), and rendering engines exercise type in a variety of ways, and it’s extremely difficult to prepare a typeface to handle all of these situations at once.there are drastic differences from browser to browser on how the actual rendered text looks. The important lesson here is that you no matter how much control you try to exert over text, in the end, you don't get much. Not to mention most browsers are able to let users re-size and override font settings on

on the web today, there are great typefaces coming from these two different, and valid, perspectives: typefaces designed for web use at low resolution (like FacitWeb), and typefaces not designed for web use that are being improved and rereleased for better screen rendering (likeMinion Pro). Depending on the size at which one intends to set text, it’s easy to see the advantage of either approach. Type designed for low resolution looks great on screens at small sizes, and type drawn for its own sake — without low resolution antialiasing as a design philosophy — is arguably more balanced and beautiful at mid-to-large sizes.

Whether a typeface has been designed or adapted for screen use significantly influences how it will look on the web. Of equal significance to type rendering are fonts’ technical composure: a typeface’s outline and hinting instructions (or lack thereof) can affect screen rendering.

Font files contain a typeface’s vector outlines in one of two flavors: PostScript (PS) or TrueType (TT). At the most basic level, the difference between these two outline formats is a matter of mathematics (cubic vs. quadratic Bézier curves). No single font file format works in all web browsers. Adobe Typekit will serve  the most appropriate format to each browser  the emerging W3C standard WOFF (Web Open Font Format) wherever possible, Embedded OpenType (EOT) to Internet Explorer (it’s the only format IE8 and earlier will accept), and either raw OpenType (OTF) or raw TrueType (TTF) everywhere else.1 2

Most people reading text on the web view type in one of these five ways. Mac OS Xusers see Core Text, Windows 7 and Windows Vista users see either DirectWrite or GDI, andWindows XP users see GDI. 

the translation of a design into pixels is not something that happens naturally or consistently. OS makers apply different strategies to render how typefaces are displayed, and these have evolved greatly over time (and still continue to do so). As we now look closer at fonts on screen more than ever before, we realize that the rendering of these glyphs can differ significantly between systems and font formats. What’s more, it has become clear that even well-designed fonts may not look right on Windows if they are missing one crucial added ingredient: hinting.

In digital type, characters are designed as abstract drawings. When a text is displayed on screen, this very precise, ideal shape needs to be expressed with a more or less coarse grid of pixels. 

Antialiasing – grey pixels subpixels  uses RBG to control brightness of the pixel- cripser than Antialiasing  there are differences between the browsers in terms of the support given to kerning and ligatures, as well as the application of underline position and thickness, so we cannot expect perfectly identical rendering in all browsers (even on one platform).

What’s more, on Windows, the browser can have the font rendered by either of the system technologies—GDI or DirectWrite. the font format has a significant impact on the rendering. The crucial difference is between PostScript-based and TrueType-based fonts, and not the way these are brought into the browser—JavaScript vs. pure CSS, raw fonts vs. “real” Web fonts, etc. 

Each operating system contains a text rendering engine — sometimes multiple engines from which to choose. And each browser controls which of those rendering engines is used. So on the same OS, two browsers can produce text with very different appearances because they use different rendering engines. On top of that, often the rendering engines differ between different versions of the OS and different versions of the browser. Additionally, default font-smoothing settings vary by OS and OS version, and can be overridden by users’ browser preferences.

TrueType and PostScript fonts differ in the mathematics used to describe curves. ClearType is Microsoft’s take on subpixel rendering. It was first made available for GDI, the classic Windows API. Although available in Windows XP, it is not used by all browsers. In Windows 7 and Vista, ClearType is the default, which makes it the most widely used rendering technology (if we were to consider all internet users). However, it is important to note that this applies only to TrueType-based Web fonts—GDI-ClearType is not applied to PostScript-based fonts.

One curious property of this rendering technology is that along with adopting the advantages of subpixel rendering in horizontal direction, Microsoft gave up smoothing in vertical direction entirely. So ClearType is effectively a hybrid of subpixel and black-and-white rendering. This results in steps within the contour, which is particularly noticeable in large sizes. These jaggies at the top and bottom of the curves are unpleasant, but unavoidable—even the best hinting cannot make them disappear.

For type in large sizes, ClearType is a step backwards in rendering quality. The gains in horizontal precision are not significant, while the rough contours spoil the overall result.  In DirectWrite (the successor of GDI), Microsoft added vertical smoothing to ClearType. This new rendering mode (so far used by Internet Explorer 9), gives us smooth and precise rendering in all sizes

TrueType hinting — sometimes more correctly called instructions— bends the contour of the letter into a slightly different shape before it is rasterized. Hinting can control the heights and widths of a font’s uppercase and lowercase letters, the widths of its individual lines, the amount of white space around letters, the size at which uppercase letters start to use different stem-widths from lowercase letters, how the angle of italic characters changes to best fit the pixel grid, and many other extremely technical details, all on a pixel-by-pixel basis. If this sounds like a rather tedious, time-consuming activity, it is, (even for type designers, who are accustomed to tedious, time-consuming activities). Finding a good hinting strategy can be tricky at times. Some more complex letters can require special attention, and design-related questions arise: do we want to keep the black strokes consistent, or should we preserve the white inner space?

In GDI-based browsers, PostScript-based Web fonts are displayed in grayscale. Unlike the prevalent GDI-ClearType, this gives smooth contours. And unlike TrueType hints, PostScript hinting is easier to create, even automatically. DirectWrite not only gives smoother outlines, it also applies subpixel rendering to PostScript fonts. Unlike TrueType rendering, however, it allows for more gray pixels in order to reflect stroke weights more realistically. That makes it well-balanced, and similar to Mac OS rendering.

GDI-ClearType is extremely dependent on good hinting.  Horizontal strokes have to be precisely defined by means of hinting, otherwise they might be rendered in an inappropriate thickness. 

In DirectWrite, unhinted PostScript and TrueType-based Web fonts show virtually the same rendering.

On Mac OS, all browsers use the Quartz rendering engine. TrueType and PostScript fonts are rendered in exactly the same way, since hinting—the biggest conceptual difference between the two formats—is ignored. The subpixel rendering on Mac OS is very robust, so this platform is typically the one we need to worry about the least. 

Apple does seem to apply some subtle automagic to enhance the rendering, but this is entirely undocumented and beyond our control.

In some cases, however, this leads to less-than-ideal results. In the above example, the large size “T” has a fuzzy gray row of pixels on top because the theoretical height is not a full pixel value, and Mac OS does not force its alignment. Unfortunately this cannot be controlled by the font maker. However, the blurriness occurs only in certain type sizes. So typically, choosing a slightly different font size fixes the problem. With a bit of trial-and-error, one can find a type size that looks comfortable and crisp.

Another difficult-to-control phenomenon is that on the Mac, type tends to be rendered too heavy. This difference is most noticeable in text sizes, where the same font can look a bit “sticky” on Mac OS while appearing almost underweight on Windows.

The rendering on iOS follows the same principles as on Mac OS—the main difference is that it currently does not employ subpixel rendering. The reason might be that when the device is rotated, the system would have to re-think and update the rendering because the subpixels are physically oriented in a different way, and the makers wanted to minimize CPU use.

Website visitors use a great variety of systems and browsers. Some are not up-to-date, and sometimes it’s not even the user’s fault, but rather a company’s policy to stick with a certain setup. My personal opinion is that we should try and give them the best rendering we can, instead of blaming OS makers, or demanding users to switch to better systems.

On Mac OS and iOS, we hardly have any control over the rendering, which is acceptable (since it’s generally very reliable). One problem is that fonts generally render too heavy. Maybe some day, Web font services can improve the consistency by serving slightly heavier or lighter fonts depending on the platform.

On Windows, hinting matters—especially for TrueType-based fonts (the only Web fonts Internet Explorer 6–8 will accept). Apart from that, one significant control we have over the rendering is the choice between TrueType and PostScript. Except for very well-hinted fonts in smaller sizes, the latter is equal or superior in rendering, and easier to produce. Even though DirectWrite is making Windows rendering more pleasant, it will not remove the necessity to provide well-hinted fonts.

 While most Web fonts currently on the market are TrueType-flavored, I am expecting that the industry will largely switch to PostScript, which is the native format nearly all type designers work in (the fonts that are easier to produce).

Typekit has also started to implement a hybrid strategy by serving display fonts as PostScript in order to trigger smoother rendering in Windows GDI.

While the GDI ClearType jaggies are unavoidable for IE 6–8, all other scenarios produce nice, smooth results. This also means that we will still need fonts that have decent TT-hinting—the browser share of IE6–8 is still too big to deliver fonts that don’t at least render in a clean fashion

a bad font, or a poor choice of font format (like OpenType CFF on most Windows browsers today) can look awful on most computers. 

That’s one of the many reasons to consider using the WebINK web font service. With a font service, your site will always use the correct font formats, without any code changes on your part.

OS- not the browser most times.

http://www.webink.com/pricing

It’s no surprise that Apple-rendered text reflects this same slickness, some would argue to the detriment of legibility. Core Text type tends to respect a typeface’s designed shape, which essentially means thicker letters (rather than pixel grid strictness). This can make letters, as well as spaces within and among letters, seem blurry at paragraph sizes. However, at very large sizes Core Text type looks natural and smooth.  Core Text uses subpixel antialiasing.

Microsoft sub-pixel antialiased text is crisp and legible at the expense of style (and at the cost of many font production hours, but we’ll get to that in a future post). As Joel Spolsky once noted, there is a philosophical difference between the two companies’ approaches, and this is evident as we compare Apple’s Core Text to Microsoft’s DirectWrite.

DirectWrite, the latest and greatest text rendering engine for Windows, is available onWindows 7 and Windows Vista. It is markedly clearer, smoother, and has less intense color fringing than Core Text and older Windows text rendering engines. 

in DirectWrite are used not only to antialias text but also to space letters horizontally, which means letters can sit more naturally next to one another than in Microsoft’s older text rendering engine, GDI.

In keeping with another philosophical difference between Apple and Microsoft, Windows operating systems provide users with several antialiasing preferences from which to choose:ClearType (sub-pixel antialiasing), Standard (grayscale antialiasing), or no antialiasing(black and white text without any smoothness). By default, ClearType is enabled in Windows 7 and Windows Vista, and Standard is enabled in Windows XP.

Windows Standard antialiasing is in good ol’ grayscale. This is how most Windows XP users see type on the web .Grayscale antialiasing adjusts whole pixels at once, doing its best to approximate the partial presence of a letterform by showing a solid gray representation of the two-dimensional area consumed by the shape’s overlap upon a given pixel. Grayscale text is not sharp enough to be very legible and, combined with Windows’ philosophical preference for snapping to pixel edges, does not adhere to the design of a particular typeface very well

Type rendering is the product of many layers of technology. Operating systems, web browsers, font smoothing preferences, font files and outlines, hinting, and type design philosophy: All of these play a role in translating the beautifully drawn shapes of our favorite typefaces into pixellated screen text. So the next time you see a web font that looks excellent (or awful), consider the mix of responsible technologies at play.

No one way of rendering is “correct.” 

Fonts that render well

Minion Pro, Myriad Pro, DejaRip, FF Meta Serif Web Pro, and FF Dagny Web Pro

Missing: I have not included details about Linux or Android OS.

Tot test:

Any Mac browser

• IE9

• IE8 with ClearType enabled

• IE6 with Standard antialiasing enabled

• Firefox 4