Embedding Unique Fonts CSS3

We’ve done a lot of work on the background of the article so far. Now let’s apply some extra styling to the actual content. We can use @fontface rules to make the headings look like they are handwritten—and this trick even lets IE in on the fun.

What is @font-face?
The @font-face rule is a way of linking to fonts on your server (just as you can link to images) that the browser downloads into its cache and uses to style the text on the page. It’s often called font embedding (though the fonts aren’t truly embedded anywhere), and the fonts that are “embedded” are called web fonts.

The @font-face rule was actually part of CSS 2 back in 1998, but was removed from the CSS 2.1 specification. It’s now back, in CSS3, and finally has widespread browser support.

Until now, without web fonts, web designers have been limited to the small handful of common fonts installed on all users’ computers, called web-safe fonts. Designers who didn’t want to use just Arial, Verdana, or Georgia (among a few more) would have to resort to images, Flash, or scripting to create their text using unique fonts. These font-replacement techniques all suffer from accessibility and usability problems to varying degrees. They’re also much more work intensive to implement and maintain, and they can degrade the performance of your pages.

Using @font-face, on the other hand, keeps real text in the page. You don’t have to depend on the user having the Flash plugin installed or JavaScript operating. You don’t have to create any images or scripts, and your users don’t have to download them. The work involved to implement it can be as simple as writing CSS like this:

This tells the browser to use the raleway_thin.otf font file to render the text inside the h1 element . If the user’s browser doesn’t support @font-face or can’t download the file for some reason, the browser simply works through the font stack for a fallback.

Using @font-face, you can display a non-standard font.

Using @font-face, you can display a non-standard font.

The font stack is the list of fonts declared in the font-family property, which the browser tries to load from the user’s machine,in order, until it finds a font it can use.

As you might have suspected, however, using @font-face is more complicated in the real world.

Choosing Acceptable Fonts
One of the big issues with web fonts is that not every font ought to be used in web pages. Some fonts have licensing restrictions that forbid such a use, while others simply don’t look good on the web.

LICENSING ISSUES
When choosing a font to use, read its license—often called an end-user license agreement (EULA) or terms of use—to see if it allows web font embedding. Many fonts’ licenses don’t, because when you use @fontface, the font file is downloaded into the user’s cache, just like images.

The user could go into her cache, take the font file, and install it on her system. Most font vendors are not interested in simply giving their products away to the thousands of people who browse your web site.

Of course, not many users are really going to go to this trouble.
But Richard Fink describes the bigger problem font vendors have with font embedding in his article “Web Fonts at the Crossing”:

The fear is that once fonts are on the web, they will become a commodity, the current model will break, and a devaluation of fonts, in general, will occur. The fear is that font designers will no longer be able to charge a print customer, say, $420 for a four-style font family with a 6–10 user license in a world where fonts are being delivered on web sites to virtually unlimited numbers of “users” who don’t have to pay anything at all. What if the web drives down prices in the print sector and doesn’t generate much revenue on its own?

Unfortunately, most fonts’ licenses were not written with @font-face in mind, so when you read through a font’s license, it may not say anything about not embedding fonts. Lack of a restriction doesn’t mean you have a free pass to use the font. It’s best to err on the side of caution and not use the font unless it explicitly says that web embedding or redistribution is OK.

This is the case even with free fonts. Just because the font vendor gave you the font for free doesn’t mean you can redistribute it. Same thing with the fonts that came with your computer. Again, you have to check the license to be sure.

Luckily, there are many places online to find fonts whose licenses allow web font embedding:

The League of Moveable Type is a small but growing collection of free, open-source fonts that are specifically provided for @font-face use. The Raleway font used in Figure below is one of these fonts.

The Webfonts.info wiki has a page called “Fonts available for
@font-face embedding” that lists fonts (mostly free) whose licenses permit embedding. But like most wiki pages, it’s not always as up-to-date and comprehensive as it could be.

Font Squirrel provides a large collection of free fonts whose licenses allow embedding. It also provides some handy tools for working with @font-face, as we’ll talk about in a bit.
Google has a library of free fonts for embedding called Google Font Directory. You link to one of the fonts on their server using the Google Fonts API, which has a number of advantages.

Most of the fonts available at Kernest are free, and all are specifically provided for @font-face use. Some are hosted by Kernest, but most you can download and host yourself.

exljbris and Fontfabric both provide a number of fonts for free that can be embedded on the web, as long as you provide attribution according to the terms in the EULAs.

All of the fonts at Fonthead are allowed to be used with @font-face as well as other text replacement methods.

FontSpring sells fonts that can be used both in a traditional way on your computer and in print work, as well as embedded on the web with @font-face.

FontShop has created web versions of several fonts, called Web FontFonts, that you can buy separately from the traditional versions.

READABILITY AND RENDERING ISSUES
Once you’ve cleared the licensing hurdle, don’t go crazy and start loading up your pages with all sorts of bizarre fonts. Every time you choose to use a web font, have a specific reason for picking that font, beyond just that it looks cool. Make sure that the font truly enhances the text and doesn’t make it less readable.

Test your web fonts with your actual content to make sure they will work. The Raleway font shown in Figure below might work well for large headings but be too thin to render well and be readable for body copy. Most commercial fonts were not designed to be viewed at small sizes on a screen, so in many cases it makes the most sense to reserve @font-face for headings and continue to use web-safe fonts like Georgia and Lucida for body copy.

Another aspect of web fonts that can affect legibility is how they are anti-aliased and hinted. Right now, web fonts are generally more jagged around the edges than traditional fonts, even when anti-aliased, usually because most were not designed to be viewed on screen. Higher quality fonts, as well as fonts that were designed for the web, have better hinting, which, in a nutshell, is a set of instructions in the font file that adjusts the edges of the characters to line up better with the pixel grids of our computer screens so they look better to the human eye. Font format plays a role in this too; TrueType fonts are generally better hinted than OpenType CFF fonts. The degree of jaggedness depends not only on the font but on the operating system and sometimes the browser; Mac is generally smoother than Windows, but can look blurry. Windows XP in particular can look quite bad if the user hasn’t enabled ClearType (Microsoft’s current technology for improving text rendering on screen).

Not only is the readability of your web fonts important, but so too is the readability of the fallback fonts in your font stacks. Make sure to test the fallback fonts so that if the web font doesn’t load, the user still gets readable and attractive text. You usually want to choose fallback fonts that have similar proportions to the web font you’re putting at the front of your font stack. That way, the font size, weight, and other styles you apply to the text will work well with whatever font the user sees.

Arial (center) and Calibri (bottom) are too small to be the best fallbacks for the Junction (top) web font.

Arial (center) and Calibri (bottom) are too small to be the best fallbacks for the Junction (top) web font

Trebuchet MS matches up well with Junction, with Lucida Sans Unicode being a good runner-up.

Trebuchet MS matches up well with Junction, with Lucida Sans Unicode being a good runner-up.

Browser Support
So once you’ve chosen a font that has the correct license and is legible on the web, all you need to do is link to it in an @font-face rule as shown earlier and you’re done, right? Well, not quite. The @font-face rule has good browser support, but different browsers want you to use different font file types.

TrueType (TTF) and OpenType (OTF) font files, such as the ones you probably already have on your computer, work in most browsers.

IE supports @font-face as far back as version 4, but IE 4 through 8 support it only if you use a proprietary font format called Embedded OpenType (EOT). EOT is technically not a font format; it’s a compressed copy of a TTF font that uses digital rights management (DRM) to keep the font from being reused.

The only type of font file that works on Safari on iOS (the browser on the iPhone, iPod Touch, and iPad, and often called “Mobile Safari”) is SVG (Scalable Vector Graphics). SVG also works on Chrome, desktop Safari, and Opera, but not Firefox. You’re probably most familiar with SVG as a vector graphics format, but an SVG file can contain font information too—after all, each character in a font is really just a vector drawing.

Using these three formats—TTF or OTF, EOT, and SVG—will make your unique fonts show up in every browser that supports @font-face. But you should also include a fourth format, WOFF, for future compatibility.

WOFF, which stands for Web Open Font Format, was introduced in 2009. Like EOT, WOFF is not technically a font format, but rather a compressed wrapper for delivering TTF or OTF fonts. Unlike EOT, however, WOFF contains no DRM. So far, the only browsers that support WOFF are Firefox 3.6 and later, Chrome 6, and IE 9, but the other major browsers are all working on adding support for it, and many font vendors have also expressed support. The WOFF specification became a W3C working draft in July 2010, so it’s now officially on its way to becoming the standard web font format. Going forward, it’s the one to use.

But don’t get too overwhelmed by all these acronyms and browsers. As you’ll learn in the next section, it’s easy to create all the different formats you need. Check out Table 3.5 for a summary of which browsers support which font types.

@font-face file types browser support

@font-face file types browser support

Converting Fonts
Some providers of @font-face-ready fonts supply you with all the different font formats you need for the different browsers. For instance, Font Squirrel offers something they call “@font-face kits,” each of which includes the original TTF or OTF font, an SVG version, a WOFF version, an EOT version, and a sample style sheet and HTML page showing the @font-face rules you need to place in your CSS.

Even better is Font Squirrel’s @font-face Kit Generator. You can upload your font and convert it to whichever formats you wish. You can also control the CSS syntax it outputs, subset the characters to reduce file size, and use more options to fine-tune the fonts .

Font Squirrel’s @font-face Kit Generator

Font Squirrel’s @font-face Kit Generator

The files Font Squirrel produces are usually all you’ll need, but there are a couple of other tools worth mentioning that will optimize your EOT and SVG files even further. EOTFAST is free desktop software that converts TTF files into compressed but lossless EOT files; the EOT files that Font Squirrel produces are not compressed. The command-line tool ttf2svg converts TTF files into same size or smaller SVG files; you need to have Java and the Java SVG toolkit Batik installed on your system to run it.

Using @font-face
Let’s finally put @font-face to use in our page. Since it looks like notebook paper, a font that simulates handwriting seems appropriate. We picked Prelude, a casual cursive font, for the headings .

The Prelude font on the Font Squirrel site

The Prelude font on the Font Squirrel site

We’re not going to apply a casual cursive font to the body copy, however, as that kind of font at small sizes doesn’t look very good and decreases legibility.

In the exercise files for this chapter, you’ll find a folder named “fonts” that contains all the eight versions of Prelude that we’ll need for our page: EOT, SVG, TTF, and WOFF files for both the regular and bold weight of the font.

We created these versions using Font Squirrel’s Generator tool, using the settings shown in Figure above. we then remade the EOT files using EOTFAST to cut the file size of each EOT roughly in half.

LINKING TO THE FONTS WITH THE @font-face RULES
You may notice in Figure above that there are three choices in the Font Squirrel Generator for CSS Formats. These refer to three variations of the @font-face syntax used in the CSS. As with almost everything in CSS, there are multiple ways to code @font-face to get the same effect; all three syntaxes use valid, standards-compliant CSS and will work in the same browsers.

The rationale behind each of these three syntaxes is too complicated to fully explain here, and not terribly important. Any of the three will work for our purposes, and the choice really boils down to personal preference. My preference is the “Bulletproof Smiley” version.

Here’s what the Bulletproof Smiley syntax for the Prelude font looks like:

Put this Bulletproof Smiley syntax before any of the other CSS rules; it will work anywhere you put it, but you’ll learn later in the chapter how putting it at the top of your styles can improve your page’s performance.” You can copy and paste it from paper_final.html in the exercise files.

These two @font-face rules group the regular and bold font faces into a single font family by declaring them with the same font-family name, Prelude. Each @font-face rule gives the path to the font files and, optionally, the style characteristics of an individual face (such as font-weight: bold or font-style: italic).

Let’s look at just the first @font-face rule for now and go through it line by line.

The first part of the rule—font-family: ‘Prelude’;—assigns a name to the font you’re linking to so that you can later refer to this font in your font stacks. You can make the name whatever you want; it’s just a shorthand way of referring to a whole bunch of font information at once.

The second part of the rule—src: url(‘fonts/preludeflf-webfont.eot’);—gives the path to the EOT version of the font for IE 8 and earlier. This is separated out from the other versions of the fonts because IE can’t understand a src descriptor with multiple comma-separated values. It thinks it’s one big path, preventing it from noticing the EOT and being able to use it when grouped with the other files.

The next part of the rule is a second src value that lists all the font files for non-IE browsers. Each browser will go through the list until it finds a format it can use, and then download that file, and only that file, to display the text. Each font includes a path to the font file, such as url(‘fonts/preludeflf-webfont.woff’), and a format hint, such as format(‘woff’). The format hint is optional, but including it alerts the browsers about the format of each font to keep them from downloading ones they can’t use, which would waste bandwidth and slow page loading.

But you probably noticed that at the start of the second src value is local(‘ ’). What in the world does this smiley face do?

The local(‘ ’) part of the src value is there to protect IE. Without it there, IE would try to read the second src descriptor as one big path, as explained earlier, which would lead it to get a 404 error. While this doesn’t stop @font-face from working—IE can still use the separate EOT—it’s an extra, pointless hit on your server that you don’t want. IE doesn’t understand the local() syntax, and putting it at the start of the src value stops it from moving any further into the src value, seeing the url() value, and then trying to parse the path.

The local() syntax is perfectly valid CSS, by the way. Its real purpose in a @font-face rule is to point to a locally installed version of the font on the user’s machine, so that if the user has the same font as you’re embedding, he doesn’t have to download the extra file. That’s why Paul Irish, who came up with the syntax, recommends using a smiley face: we don’t want to call for a font that might actually exist, and it’s very unlikely that anyone will ever release a font named.

The second @font-face rule declares the bold versions of the Prelude font family. It gives the paths to all the bold font files and also sets the font-weight to bold inside the rule. But the font-family name is Prelude (not PreludeBold or some other variation), matching the first @font-face rule. Assigning the same name tells the browser that the file is the bold version of the same Prelude font family. Now, any time the browser needs to have bold Prelude text (because of a strong element in the HTML or font-weight: bold in the CSS), it doesn’t have to synthesize the boldness by making the characters thicker, but can instead use the true bold font files. Using a true bold or italic font face looks better than having the browser simulate it for you.

DECLARING THE FONT
Adding @font-face rules to your CSS doesn’t actually make the fonts show up anywhere; it simply links them, so they’re ready to be downloaded and used when you need them. Let’s call them up in our h1 and h2 elements. Add Prelude, the name of the font we assigned in the @font-face rule, to the start of the existing font-family values in the h1 and h2 rules:

The sans-serif fallback fonts in the font stacks don’t look anything like the cursive Prelude script, of course. We chose to do this because there aren’t really any cursive web-safe fonts we can rely on as fallbacks. If someone is using a browser that can’t do font embedding, I’d rather they see some nice, clean Helvetica or Arial text than whatever random cursive font they might have on their computers.

Note that the h1 rule sets the font-weight to normal and the h2 rule sets it to bold. This tells the browser to use the regular member of the Prelude font family (the first @font-face rule) for the h1 elements and the bold member of the Prelude font family (the second @font-face rule) for the h2 elements .

The cursive Prelude font in the headings on our page

The cursive Prelude font in the headings on our page

We now have handwritten cursive text showing in our headings that is resizable, selectable, and indexable. There are differences in the anti-aliasing and hinting of the text between browsers and between Windows and Mac, but the advantages of real text outweigh the inconvenience of its slight jaggedness in some browsers .

@font-face browser support

@font-face browser support

Different platforms and browsers, such as Firefox 3.6 (left) and IE 9 (right), display the anti-aliasing of the headings differently.

Different platforms and browsers, such as Firefox 3.6 (left) and IE 9 (right), display the anti-aliasing of the headings differently.

IMPROVING PERFORMANCE
If you view your page in a browser now, you may notice a lag between when most of the page loads and when the handwritten font displays.

Webkit-based browsers don’t show the @font-face-styled text until they’ve finished downloading the font file.

The headings are invisible while Safari or Chrome downloads the font files it needs.

The headings are invisible while Safari or Chrome downloads the font files it needs.

In Firefox and Opera, the fallback fonts show for a moment while the font file is downloaded, and then the browser re-renders the text with the new font. This is called the Flash of Unstyled Text, or FOUT, a term quippishly coined by Paul Irish.

These font-loading lags are usually a minor annoyance, but in some cases they can be quite noticeable and problematic. Fonts for non- Western languages, such as Chinese and Japanese, can contain thousands of characters and be several megabytes in size; these huge font files take a long time to download, of course. Also, users on mobile devices in areas with poor coverage, or at hotels with notoriously slow connection speeds, may be left waiting for the web fonts to appear for quite a while.

There are a number of things you can do to minimize or do away with the FOUT or the invisible text problem in Webkit:
Keep your font file sizes as small as possible to begin with. Subsetting the characters within each font to include only the characters that you need can really help in this regard; the Font Squirrel Generator lets you do this.

Put your @font-face rules at the top of your style sheets. This increases the chance that the browser will download them before the other files called for in your CSS, such as background images.

Get the browser to download the font file as soon as possible by, for instance, calling it on a hidden element at the very start of your page. You can adapt many image preloading techniques.

Host your fonts elsewhere. By serving your fonts from one common location, you increase the chance that the visitor already has the font file in his or her cache, instead of having to download the same exact font file again from a new location. The font-embedding services listed earlier allow you to do this, as does Google’s Font Directory, but you can also upload fonts you personally own to the TypeFront service. TypeFront hosts the fonts you give it, converts them to all the needed formats, and serves them only to the sites you specify.
Set the Expires header in .htaccess to a date far in the future so that when a font is downloaded once, it’s cached by the browser and not requested again for a very long time. This doesn’t help with the initial page load when the browser first downloads the font, but it should help on subsequent loads.

Gzip your font files. Stoyan Stefanov found average file-size savings to be from 40 to 45 percent. But he also found that this doesn’t really help WOFF files, which are already very compressed, so this may not help you much with the FOUT in Firefox. However, gzipping should help Opera avoid or minimize the FOUT and Safari and Chrome show the text sooner.

Use scripting to hide all the content for a couple seconds while the browser downloads the fonts. This doesn’t actually speed up downloading the fonts, of course, but it keeps the user from ever seeing the FOUT’s disorienting shift in fonts. Paul Irish provides two different JavaScript options to do this, one of which uses Google’s WebFont Loader JavaScript library.

Our font files already use a subset of all characters and are called at the top of the CSS, so we’ve covered the most basic @font-face performance best practices. It’s beyond our scope to add any of the scripting or server-side techniques to our page, but this gives you a number of things to try if you’re having trouble with web font loading times.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

CSS3 Topics