Download, view, test-drive, bookmark free fonts. Features more than 13500 free fonts. Free Helvetica fonts which are one of those fonts available for the users to download for free can be used in many ways by professionals working in corporate and. Helvetica Neue LT Std 35 Thin Font belongs to the Helvetica font family. Helvetica Normal Free Font is a normal font type which is free to download for users.

For the past decade, web designers have been limited to a selection of about 13 or so ' fonts. Out of hundreds of thousands of available fonts, this is a tad limiting.

While it's theoretically possible to utilize any font you want for a web site, in order for it to display properly, each visitor must have that particular font loaded on their computer. Because of this requirement, web typography has been a wasteland, limited to only a short list of commonly available (web-safe) fonts. There have been several attempts to circumvent this problem and below, is a list of some of the most common. All have their short-comings and for me - no disrespect to very creative, determined and knowledgeable people - they all fall into the category: 'life shouldn't be so hard'!

• (typography as a graphic is seen by everyone - except search engines - and one has to play CSS games, to attempt to achieve both objectives). • (sIFR means 'Scalable Inman Flash Replacement', based on work done by Shaun Inman, et. A convoluted solution that relies on JavaScript and Flash technologies to replace web-safe text with a Flash image of the text, in your chosen typeface.) • - a JavaScript image replacement technique that's a worthy alternative to sIFR. The name is derived from 'CUstom FONts'. • - A server-side PHP script that dynamically generates images of text in the font-face of your choosing. PHP5 is recommended and requires GD library (with FreeType and PNG support enabled).

CSS3 @Font-Face Embedding to the Rescue. Even though the ink is still drying on the official June 30th release of FireFox 3.5, which supports the @font-face CSS3 selector, there has been much buzz about how this will herald a new, creative web-font landscape. Truth is that Safari has supported @font-face for a while now and Opera 10+ is reportedly going to be supporting supports it as well. In the Inspect Element Web Design & Development Blog, Tom Kenny writes, 'Currently only Firefox 3.5 and Webkit browsers such as Safari and Google Chrome will render [the @font-face selector]. Of course, older browsers such as IE6 and IE7 will not support it and with IE8's distinct lack of CSS3 feature [sic], that doesn't support it either.'

(Source: ') I know it's popular to bash Internet Explorer, but Tom (and others) need to check their facts before they publish false information! Firstly, Microsoft has been supporting font-embedding for over a decade (since IE4 in 1997) and also the font-face tag and @font-face CSS selector. Secondly, the @font-face selector was a (dropped in CSS2.1). It's made a comeback and hopefully will become a web standard. Updated:4-Feb-2010 (Chrome 4 now supports @font-face by default) Secondly, Chrome doesn't support @font-face by default. (Apparently, Google supported it in an early beta release and then disabled it for subsequent releases, for 'security reasons'. To activate it, users must add a command-line switch --enable-remote-fonts.) ().

The beauty, of course, is that it's now possible to embed fonts for IE6, IE7, IE8, FireFox 3.5+ (PC & Mac), Safari (PC & Mac) and (soon) Opera 10. According to our June 2009 web stats, that's over 97.5 percent of our visitors - about as 'cross-browser' as you're going to get in today's online world! (Dunno about macIE or other browsers. I'll have to rely on reader feedback.) How @font-face Works: Easy Peasy The great news about CSS3 support of the @font-face selector, is that - unlike work-a-round techniques - it's easy to use. Fonts without hoops!

Just upload the font file you want to use to your server - making sure that you're not violating any copyright rules - then embed it, using the following CSS: Code. The CSS code above defines a font called 'yourFontName'. You may use the actual font name - or - for testing purposes a unique, made-up name. Whichever you use, all you need to do is reference it again in the CSS, wherever you want to use it. Note: the CSS3 specification provides for several font formats: 'truetype' (ttf), 'opentype' (ttf,otf), 'truetype-aat (ttf), 'embedded-opentype' (eot) and 'scalable-vector-graphic' (svg,svgz). C'mon, is it Really that Simple?

Of course not! If there's one thing we've all learned about the Internet, nothing is really that simple and embedding fonts using the 'new' CSS3 @font-face selector isn't any different. 'So, what's the issue?' You might ask. Though Microsoft has been supporting font embedding since IE4 (1997), it's current support for @font-face is done a tad differently. Different enough, that it'll ignore a pure, valid CSS3 version. Internet Explorer supports only their proprietary 'Embedded OpenType' font (eot) file format and it will incorrectly parses CSS that includes 'format' values.

To achieve cross-browser compatibility, one must create some redundant CSS. The overhead isn't much and the gains, of course, are great.

Using Microsoft's free (or this easy ), one can create a Microsoft proprietary OpenType font file (having an EOT extension). Upload both the EOT and TTF files to your server. Ashrae Standard 70 2006 Pdf Free. Using a single @font-face selector, load the Embedded OpenType font (EOT) for IE6, IE7 and IE8 first then the TrueType Font (TTF) for FireFox 3.5+, Safari (Win & Mac versions) & Opera v10+.

You've just served the vast majority of your website visitors. In addition, the process degrades nicely. Browsers that can't load your special fonts won't miss a thing, as they'll be using the secondary, tertiary or generic fonts you specify. Additionally, the process is relatively future-proof. If Internet Explorer ever does support the CSS3 @font-face rules, then it'll simply utilize that bit of code already there.

If not, you're covered there too. An example of some final, CSS3-valid code might look like this, for a cross-browser compliant embedded font: Code. Though you can name use any font name, use the real one (capitalization matters) for the 'local' declaration. This will give non-IE browsers an opportunity to look for the font on your visitor's computer. If it's loaded, it'll saves a TTF download.

(Note: The local declaration is required, because it confuses Internet Explorer, which will fall back to the EOT file without trying to download the TTF). Hints, Tips & Observations I'm no font expert, just a web developer that's eager to utilize more than a limited number of fonts. When I realized that it would be possible to utilize embedded fonts for over 95% of our visitors, I spent a fair bit of time, playing around.

Some of what I discovered along the way, contradicted what I've read elsewhere. Below is a brief list of this empirical knowledge, which I hope will help more people to use and understand this technique of font embedding. • Get Out of Font Hell Fast by Letting the Squirrel Crack Your @font-face Nut - I wrote this article days after cross-browser font embedding became technically feasible (July 4, 2009). The work-flows to embed fancy fonts have evolved to become much easier & faster. Here is an updated @font-face work-flow, which uses two very handy tools: • Find a font you want to use. (I generally use True-Type Fonts, but I'll bet other formats will work).

• Verify that you can use the font on your website. (i.e., don't violate the copyright. Just as you wouldn't with images). • Upload the font file to Ethan's. (I generally choose the 'expert' mode, generating only the EOT and TTF formats. I might subset a font more - or less - depending on how I plan on using it & the TTF file size. I strive for file sizes of less than 70KB.) • Save your kit, which includes all you need to deploy your fancy font: the HTML, CSS & font files.

(I usually tweak the font & file names to my liking). • To save even more bandwidth, run the EOT file through Richard Fink's command-line utility program (EOT Fast compresses EOT files, making them up to 70% smaller) • Put IE First - In the CSS, it's important to put the IE EOT 'src' first.

It's also important that 'src' is the only declaration. If you add 'local' or 'format', IE won't understand it and it will fail.

• CSS3 doesn't do EOT - Despite reading that the 'embedded-opentype' (EOT) is one of the formats allowed in the CSS3 @font-face selector, it either doesn't work, won't read the MicroSoft proprietary EOT flavor, or something else as I couldn't get FireFox to utilize the same EOT font file as Internet Explorer. (Pity, as it means loading the TrueType version, as well as the proprietary EOT version).

• Testing can be tricky - In the @font-face CSS, if you use the actual font name for either the 'font-family' declaration or the 'local' declaration and that font is loaded on your computer, will grab your locally-loaded font (i.e., doesn't test the font download). To make sure that the browser is downloading the font from your server correctly, you'll need to either (a) unload the font from your local computer or (b) rename the font in the CSS to something you know doesn't match any of your loaded fonts. • src: local('font name'), local('fontName'), local('otherFontName'), local('some other font name'), url(./font/font.ttf) format('truetype'); Load Local - Once you determine your font download is working, rename the font in your CSS to its true name. Your visitor might have that font installed.

You can use multiple local() declarations. If you know the font might have several names, use this to your advantage, like the example here (note syntax options). Non-IE browsers will look for the font in each location, stopping when it finds one or at the TTF download. (IE doesn't look locally in @font-face, so don't even try adding local() for the EOT line). • Trouble-Shooting Tips - Having problems deploying @font-face can be frustrating and discouraging.

To test embedded fonts, it is important to make certain the font is NOT installed locally and to test the page in a variety of browsers. Since this article was published, I've helped a lot of people with their fancy @font-face fonts and below is quick list of typical problems (i.e., before you asking for help, be certain to check this list!): • Syntax - Sounds simple, but make certain your syntax is 100% correct.

Teachings Of The Buddha Jack Kornfield Pdf Reader. Quotes around the local() filename, dash between @font and face. Nothing will work if the syntax isn't right. (be sure to select the 'CSS Level 3' profile) is the best way to check the syntax.

• Font Location - This trips up a lot of people. An absolute path of '/font/yourFont.eot' generally isn't the same as the relative path 'font/yourFont.eot'. Relative paths are relative to what?

The base URL? The CSS file?

The HTML folder? Relative paths can be confusing! Keep things simple and use an absolute path. (I generally create a 'fonts' folder right off the web-root and put all my fonts there. Then I use the absolute location '/fonts/font.eot' for all of my fonts. It's short, sweet, will always work and -bonus- it's domain-independent). To test if your location is correct, plug the URL 'where the computer thinks your font is', into the browser address bar and the result should be a download of the font.

If you get a 404 'File not found' - location is likely the problem. • Corrupt File - I've seen corrupt files, either totally munged font files which are unusable or, more recently, fonts that work locally, but contain minor errors (typically fails in FireFox). (This is hard to test, but I've found that running fonts through Ethan's will clean them.) • Windoz Server? - Recently, discovered that 'in IIS v6 and later, you must add a MIME-type of application/octet-stream for both.OTF and.SVG in order for those types to be served properly on windows-based servers'. (Thanks for sharing this, David!) • WEFT - At the time the article was published, Microsoft's free WEFT Tool was one of the few ways of generating an EOT font file. Since then, new and better tools have been developed (see #1). Unless - for some reason - you're still using WEFT, you can ignore the items below.

I leave them here just in case someone is still bent on using WEFT. • Using WEFT Dont' use the WEFT wizard. WEFT wants to create a 'font object' and subset it for any and all fonts it finds in webpages you specify. All you really need is the conversion part of WEFT. Here's an easy WEFT workflow: • Load your TrueType font (i.e., drag it into the Windows font folder); • Start WEFT (it'll create a database of 'loaded fonts' on opening, so you'll need to rebuild the database if you load your font while WEFT is running); • Pick the font(s) you want to convert (Tools >Fonts to Embed >Add. >Select a font on the list >repeat if you want to convert more); • Close the window and then do the conversion (Tools >Create Font Objects >Set location of the font object and 'allowed roots' >Finish); • Upload your newly-created EOT font file to your server (I generally rename mine and make all the characters lowercase).

• Use TrueType Fonts - Even though the CSS3 @font-face selector provides for several font formats, WEFT will only convert TrueType fonts (Supposedly, WEFT will convert OpenType fonts as well, but the few that I tried didn't work, as they didn't show up in the selection list of 'embeddable fonts'). • Some TrueType fonts won't convert - Some fonts are designated as 'non-convertible' by the designer, or there are other problems. WEFT shows a list of. • Converting OTF to EOT is More Work - Presently, it's a two-bank shot. First, convert the OTF file to TTF using or this. Then you can use,, or to convert the resulting TTF to an EOT.

• Understanding 'Allowed Roots' - There are a few tricks to understanding WEFT. A big one: the EOT font file you create will only work for URL's you designate (i.e., 'allowed roots'). If you own your own domain and want to be able to use the font file on any page, you'll need to specify both the 'www' and 'non-www' roots. Conclusions Because FireFox 3.5+ supports the CSS3 @font-face selector, cross-browser font embedding is now both possible and practical. The effect this will have on the web should be dramatic, replacing a decade-old typographic wasteland with a tastier and richer diversity of fonts. While cross-browser deployment isn't ideal, the benefits of utilizing CSS to embed fonts is obvious: It's lightweight; it's valid CSS (CSS3); it's easy to do; it's search engine friendly; it's cross-browser compatible; and (yay) it relies neither on either JavaScript or Flash. The only downside is the slight overhead in downloading font file(s) and - - may not render even for those browsers that support it.

The technique degrades nicely to the normal 'web-safe' or generic fonts you specify. Now Go have some fun! UPDATE 25-Aug-2009: I've recently found two online TTF->EOT converters: • Casey Kirsle's (easy-to-use & works) • Sebastian Kippe's (which doesn't appear to be working at the moment) Hint: Both conversion tools are based on an Open-Source utility called '. The utility is written for a UNIX O/S, but the download ships with a windows-based, command-line binary. (See the for more information). UPDATE 30-Aug-2009: Found an easy that converts OTF to TTF (it also converts.dfont files to.ttf). Works a treat!

UPDATE 1-Sep-2009 Opera 10 released It supports @font-face, but is picky about the syntax in the 'local' declaration. Needs local('font') or local('font'), but won't interpret local(font). UPDATE 4-Sep-2009: Based on work by and, the cross-browser @font-face CSS has been improved. () UPDATE 8-Sep-2009: Had a devil of a time getting the Chrome command-line switch to work, until I discovered that it's --enable-remote-font (not --enable-remote-fonts - plural). ( EDIT: The problem was likely some internal developer confusion over the spelling, but issue appears to be limited to version 2.0.172.43 (and earlier?).

I'm now on v3.0.195.21 (winXP sp3) and it's definitely plural.) UPDATE 19-Oct-2009: Looks like the of Chrome will have font-embedding turned 'on', by default. UPDATE 5-Dec-2009: Chrome support for @font-face, by default, has been pushed back to the release (waiting on a response from Apple).

UPDATE 21-Jan-2010: Added a troubleshooting section (List Item #10 #6 above). Note: Need to revamp the overall list and de-emphasize WEFT, because Ethan's is an easier, more comprehensive & online solution for conversion, cleaning and reducing file size. UPDATE 4-Feb-2010: Chrome 4.x now supports @font-face by default (Earlier entries about issues w/Chrome and @font-face support have been grayed out) UPDATE 26-Nov-2010: iOS 4.2+ now (in TrueType format). This means that mobile Safari, running on an iPad or iPhone, will see your TrueType fancy fonts!

UPDATE 27-Dec-2010: Added @font-face, which showcases two long-overdue additions: Ethan's and Richard's. (Added Community Chest card 'Get Out of Font Hell', revamped 'Tips' section & shoved most of the kludgy WEFT stuff into the afterthought basement).

UPDATE 2-Mar-2011: now fixes FOUT using a timer. The bug was first reported on.

Glad to see it fixed and look forward to FireFox4 public release. (Lots of spent a tad of time on FOUT work-a-rounds). Peter - In a word, no. First, I see no benefit in setting font-style and font-weight to 'normal', as both are defaulted to 'normal' anyway. For the sake of brevity, omit them. Second, your results are odd, because that FFx would be the browser that understands this code, not IE. (IE doesn't understand 'format()' and skips over tries to download a very strange font file, which results in a 404 'File Not Found' from the CSS contained in this @font-face selector).

Bottom Line: You'll need to use two @font-face selectors Use one @font-face selector, as described in the examples above. Hope this helps. In the past I've used the Font Replacement from the article in A List Apart This technique replaces text by cached images that are created server side.

One of the advantages is that the XHTML source contains the 'normal' text so it's read by bots. However the latest HTML5 techniques (not only the fonts) are awesome. It won't be long before I completely ignore backward compatibility. I've waited too long for this. Maybe degrade gracefully like we did with jS: 'You have a shitty browser, contact the vendor.'

Richard - LOL. No-one likes to be told they're wrong, me included!

Did I jumped to conclusions? Turns out - I did. I spent so much time the other day, testing and retesting Paul's 'bulletproof' CSS, that I left that fancy font loaded on my computer. (Bit by #8 in my own 'hints' section!!). Hopefully, Chrome will support @font-face 'out of the box' at some point in the future.

*goes to fix the text copy* (In addition to embarrassing myself of Ralf's blog, I've included his information on Chrome support). Thanks, Richard, for pointing this out, making me look twice and for the informational link! @stk - Writing as somebody who's played around with font-linking a lot, the same thing has happened to me many times.

Once font-linking really gets rolling - and if FF supports the new iteration of EOT it will happen really fast - investing in a font-management program that can dynamically load/unload or install/uninstall fonts quickly and easily becomes a must-have in any web designers toolkit. Don't feel bad. I reported that Chrome had font-linking, too.

I wasn't wrong, and neither were you, technically. It did support it, but then, in the next upgrade, they turned it off! Cheers, rich. @Richard - What version of Chrome are you using and on what platform? (I'm running the current production version on windows 2.0.172.43) It's --enable-remote-font for me, as plural doesn't work (and why I was frustrated, when I first tried to use it). I'm still digging into this.

I've been rooting around in the Chromium/Webkit code and realize there's a way to enable remote fonts via the preferences file (just not sure the syntax). While I've seen the command-line switch as --enable-remote-fonts (plural) in the code, I can't explain why it doesn't work for me (it's singular in a couple of the bug / review responses). What version of Opera are you using (and platform)? Do you have a link to the test page that's not working for you with local()?

(I'll come round and have a peek with my version - 10.00/b1750/Win32/XP). If I can add my advice at this point, also: Make a simple sample page with the font in the same directory as the sample page and test to make sure the correct font is showing up without the complications of a lot of CSS on a complex page. How was the EOT created? There's always the possibility it's corrupted or has root strings enabled and IE is simply refusing to display it. A simple sample page will reveal that. Always a good idea to take variables out of the mix and test for basic functionality first.

Cheers, Rich. Martin - First the good news. Your CSS @font-face declaration appears fine. The TTF and EOT fonts are found, where the CSS says they are, as I was able to download both. The bad news is that the TTF file is corrupt (assume the EOT too). It downloaded on my XP machine as a 517KB file, which seemed a tad large and wouldn't open - 'not a valid font file'.

More good news. I was able to snag a free copy of the (comes-with-a-Mac) Zapfino font following the links on. It's only 77KB and you can download it. I'll leave it to you to make the EOT, though I do recommend you follow Richard's suggestion and put any/all @font-face selectors first in your CSS. Hope this helps. @stk, thanks for the tips!

I´ve moved the @font-face to the top, re-exported the font, but still no luck. The TTF is from my Mac, and the EOT was created from console using ttf2eot. 517K Zapfino.eot 516K Zapfino.ttf FireFox (3.5.3 Mac) recognize correct filetype for both. I noticed that it´s not only IE that don´t use the provided fonts. Non of the browsers on Windows displays it.

Mac works as it´s embedded there. I tried the fonts you found online too, without luck I´m afraid. Martin - First, I have to say that despite the nifty graphics, sucks!

(Only one of the 9 browser versions they offer actually renders @font-face properly - Safari OSX. Not much help to you, since you probably already have that.) All supported FireFox versions are less than 3.5 (which is when FireFox begins @font-face support). I tried IE6/7/8 against this Randsco article and they all failed to correctly render @font-face. (I'd use the service Richard suggested, though I haven't tested it myself). Secondly, I don't have a Mac ( Help change that!

Download my, vote for it and leave a comment at the! ) All I can say is that when I download the Zapfino font [517KB] it won't open in my XP folder and I get a message 'not a valid font file'. Have a look at '>this test page, where I've used your CSS and point to the EOT and TTF file I suggested you download earlier. It *should* look fine in your Mac (Safari or FireFox3.5+). It also looks fine in IE6,7,8; winSafari; FireFox3.5 and Opera10 on a PC. (Try that service Richard mentioned). I did have to fiddle with the font sizing, as your font stack sizes were a tad small for the Zapfino font (which is one of my gripes about CSS: You can't easily assign font sizes for each font in a font stack - independently).

EDIT: Though the fonts show fine, you've got some CSS breaks in the menu area between IE8, IE7 and IE6. Plus the Tittinn graphic appears to be a PNG with transparency, which doesn't render in IE6 (change to a GIF and you'll be fine).

Richard - Aruba? Thanks for the links, I'll have to test them out. For the PC, I test against installed browsers and use. I must rely on sites like those you linked to test MAC browsers, since I don't own a MAC. BTW, a reader (via email) came across a TTF font that wouldn't load in FireFox. In an effort to determine why, I installed FontForge and made some interesting discoveries.

I'll be sharing them in an upcoming post. (You work w/FontForge much?) Lost Souls - Glad you like the tutorial. Thanks for saying so and good luck getting those Rock'n-Roll fonts going (and with the band)! Don't work with fontforge at all, as yet.

I'm a windows guy who's going to have to invest in a Mac. Don't want to go to the installation troubles of installing fontforge on windows. Love to hear what you've discovered. Major rumblings in the web fonts department over the past few days.

Two web fonts related articles in AlistApart: And my own chirpings from the trees: IMHO - web designers will, and should, become active in screen font design - especially in the tweaking and repairing of existing fonts with open licenses. Unfortunately, I don't believe the 'pros', that is, the retail font design community is going to be of much help. And we'll soon see where Microsoft stands in all this, too. Let's proceed. (As if we weren't going to!) rich. Tom - Without a link, the only thing I can check is the @font-face syntax (which appears to be fine). Generally, deployment issues involve one or more of these three things: 1) Syntax; 2) Font file location; 3) Corrupt font files; To test (2) hit - If the file downloads, then the font is where the CSS 'thinks' it is and you're OKAY.

To test (3) I've generally pulled the TTF file into the Windows Font Viewer or WEFT (tried to convert to EOT). If the file is corrupt, then would be revealed. HOWEVER: I recently ran into a case where the EOT worked fine for the IE browsers, but the TTF didn't work for FFx, et al.

The font file was in the correct spot AND the WinFontViewer saw it 'without issue'. Digging deeper, the problem was with the font file and. I managed to edit the font file and fix it. (Going to be the focus of an upcoming article). Thx so much for your aticle about @font-face, I didn't even know this new feature was implemented in Firefox 3.5!

Of course, I have a little problem: what to do - if there's anything to do - when a TrueType font I need SO MUCH, doesn't work with Firefox in TrueType format (Windows browser), but works perfectly in Internet Explorer 6/7/8 and Firefox 3.5 Linux? Yes, I did test on several computers with different browsers, and checked the font wasn't installed in the O/S. The funny thing is that I converted this original TTF font into EOT format for Internet Explorer (thanks to the, and the EOT format is the one who turns out to be OKAY, but not the TTF, and only in Windows Firefox browser! BTW, the doesn't convert anything (file 'To' is empty), too bad because I thought maybe I could convert the TTF into some other font format that FireFox could display that correctly. Then, I tried to download the free font again from other websites, under different names (but still the same font), but it still doesn't work.

It's a pity because I really need this particular one for a special project and I even tried to use 2 other similar fonts and the same problem happens! I tried other completly different fonts to be sure it wasn't a bug from my Firefox 3.5 browser, but they appear quite normaly.

Hum, do you have any suggestion to help me convert or 'debug' this damn TrueType font, or just explain a little bit how a TTF font can appear fine in the linux version browser of Firefox 3.5 and not windows XP? Anyway, thanks to anyone who finished the reading, it was a bit long to detail my problem:-(. @Elody - Running your font through the font validation tool called FontLint gives the following errors: File checksum is incorrect. Missing required table: 'post' Windows will reject fonts with an OS/2 version number of 0 Validation VascaBerriaTT.Failed Self Intersecting Glyph Missing Points at Extrema Bad version number in OS/2 table (must be >0, and must be >1 for OT-CFF fonts) Bad sfnt file header -------- So, just a bad font all the way around. The conversion process in Font Squirrel obviously fixes some of these issues just by re-rendering them.

Elody - Thanks for linking the font. I've been working with Ethan (over at Font Squirrel) and others, testing this font in FontForge.

The good news is that using this font (and a few other 'problem' fonts), we've been able to help Ethan author significant changes to his (i.e., see the 2009-11-30 release notes on that page). The bad news is that FireFox still fails on various TrueType fonts (without warning), because of font file problems.

*If* this happens to you again (i.e., FFx doesn't seem to render the font), the best advice is to run the font through the font generator. It will likely fix these problems and allow it to render correctly. At this point, I'd say, 'The best practice for @font-face, after identifying the font you want to use, is to make a font kit using Ethan's.'

Doing so will likely fix any FireFox rendering problems before you encounter them. Again, I'll provide detailed reasons & evidence in my upcoming article, 'Fixing @font-face Fonts'. Paolo - I'll need to look at your unusual case in more detail, because I need to look into the specification for @font-face (is it meant to fallback on a character-by-character basis?) Can you link to the two font files?

(I'm thinking of a more direct approach: rather than rely on browsers to fallback a certain way, create a single new font, one which contains the union of characters you want). Need to play more. Ahmed - The page you link uses two identical 'local();' sources, for each of the three fonts. While this is redundant (you only need to use one, unless you know - or think - the font may be installed on visitor machines under various names, then you can use as many 'local()'s as you want) it shouldn't be the source of your problems. The only font you're using with which I have experience is 'Lexographer' (used in this article). Lexographer isn't rendering in IE8 for me. The first two appear fine in my IE8.

FireFox, contrary to what you said, isn't 'perfect' for me. There, the second font isn't rendering. See my note for Elody above, because that may well fix your FireFox issue. I'm not certain about the Lexographer bit in IE8, as I know it works here, your EOT file location looks OKAY and, besides the redundant 'local()' source, the syntax appears to be fine. Recommendation: Run all three TTF files through the, upload the resulting files to your server and make certain that each font is rendering as expected.

Once each has been 'filtered', tested and works. THEN combine them into your page. @stk - I'm not too concerned with the size. The SVG version of my 53K Helvetica Black.ttf came out at 60K. Personally I'm a bit less concerned with an extra half-second of loadtime(for broadband users of course, dialup users in 2009 should know everything will load dirt slow) and more concerned with my visitors seeing a version of the site consistently across as many browsers as possible. As for the next Chrome, I'll make the appropriate changes when it's released. In any case @font-face is something I only stumbled upon in the past few days and I've got you to thank for this incredible tutorial.

This is a great write up! I am very interested in rich text solutions aside from building images / building flash websites. I think using something like this for body text & something like sIRF for headlines can provide to be a great answer to those dreaming about sharing better text experiences. If you can design for 90% of browser & have a great fallback for the others that do meet your requirements you will be safe. Just find a good standard font similar to what you want to use as all fallback & all will be good!

Hi there, I recently ran into an issue where @font-face declaration (using kits from FontSquirrel) worked excellent when developing locally, but when deployed to a production site, only IE would render the fonts correctly (using the.EOT file). After doing some digging (inspecting resources in Safari and Firefox), it appears that some issues may be related to just *how* the fonts are returned to the browser from the web-server. According to the resource inpsector, it turns out that, when developing locally (using IIS 5.1 on Windows XP), fonts declared using the @font-face declaration are returned with a content-type of 'application / octet-stream', so @font-face works flawlessly in all the browsers tested (IE7, IE8, Firefox, Opera, Safari). On our production server (IIS7), the.OTF and.SVG files are actually being returned with a content-type of text/html, which causes a '404 - Not Found' error to occur when the get request is made to get the font file, which thereby results in the fallback font in the font stack being rendered. The.EOT file seems to be returned with the proper content-type, since IE downloads and renders the fonts just fine. I'm not a webserver guy, so I've got our IT/WebServer manager taking a look.

There may be a setting or settings that have to be adjusted in IIS so these file types are served with the proper content-type. I'll post back when I have more information, but this may be an issue for those people that just can seem to get the fonts to render in Firefox / Safari on their production websites. And, then again, I could just be wrong altogether.

I'll let you know as soon as I know. Hey Scott and family: If you're going to be using @font-face web fonts check out this new free tool: EOTFAST is a utility for creating natively compressed EOT files for use with any domain. Convert once, use on any site. Savings in file size typically range from 45% to 70%. It's fair to say that other conversions utilities like Microsoft WEFT or ttf2eot are now obsolete. For example, a first-rate screen font like Droid Serif starts out at 169kb as a TTF with the full character set, but as an EOTFAST file it weighs in at only 80kb. (With still the full character set.

Compression is lossless.) The documentation contains information for designers looking to prepare fonts for use on the web.The download package also contains a HTML 'EOT File Integrity Test' page and a helpful 'fallback' test font. Is a must-have for anyone looking to use @font-face web fonts today. Hi Scott, impressive article - sounds so good that it's almost incredible. But it works, that's great.

Just some question here and wondering about your opinion. As you said Internet Explorer used the the font-face rule with.eot files since version IE4 in 1997 - all IE versions including 6,7 and 8 work with it. The market share of IE back in 1994 was an impressive ~90% (if I'm right) but it never succeeded and it was dropped. Why did they drop it?

I guess because of the font licensing issue. As you are downloading font files and distributing fonts which might be under copyright it would infrindge copyright laws. So my question is why should that now suddenly work? The copyrights are still there and the principle is the same.? I guess this is why font replacement techniques as sIFR and cufon popped up - but even they have downsides as we know. To me, the technique works and it is indeed nothing new, not even the fact that it works on 95% of browsers (as it did back in the 90's) but is it 'the solution'? So would you use the technique for a client like adidas let's say using a Frutiger or Helvetica?

Sam - It 'suddenly' works because browsers (other than IE) are honoring the reintroduced CSS3 @font-face recommendation. No, font-embedding isn't 'new', as you pointed out. What is new, is cross-browser support for font formats other than IE's proprietary EOT fonts (i.e., TTF, OTF and SVG formats). Font replacement techniques cropped up as a way to achieve cross-browser support for 'fancy fonts', but IMO are way more complicated and convoluted than need be. Yes, there is a whole issue of font copyright (similar to image copyright and content copyright). I would ammend Gyo's response by saying, 'You're only supposed to embed fonts whose license allows you to do so.'

(Not everyone plays by the rules). Would I use this simple, cross-browser CSS3 technique on a large client site? (e.g., Adidas.com) You bet! (but I'd also make certain to avoid any copyright infringement, whether that involved paying for a font or not. I'd highly recommend to Adidas that having written proof of permissions was necessary and even to the point of adding it to a colophon page, to avoid ambiguity). Hope this helps, Sam. Cheers - stk.

I am having problems with embedding fonts on and having them display on IE. If I have a local 'Ethiopic' font on my machine AND it is specified for Ethiopic text under Tools/Options/Fonts, then it WILL display. If I don't have a local 'Ethiopic' font on my machine, then it DOES NOT display on IE. Of course this is a problem, since this displaying uninstalled fonts is the whole point of the exercise!

Firefox is not affected by this problem. I will confess to not having done the 'selector' you have done. First things first. It looks like a great trick though! Thanks for any help or insight that you can give.

Videot - First, what language is 'am'? (It's not on the ).

The good news is that I can grab your and download the. The bad news may be two-fold. First, the CSS you're using isn't the recommended cross-browser CSS covered here.

Not sure if that's the problem, but I'd recommend using it. Secondly, you're grabbing that EOT file off a 3rd-party server. *IF* WEFT was used to make the font file, you may *never* get it off that server (see notes about WEFT in the article - requires user to specify hosting servers). Also, there's no guarantee that the file isn't corrupt (plus dependencies on 3rd-party servers is never a good thing). Recommendations: (a) use the syntax outlined in this article and (b) grab the original TTF file and run it through to get (and host) your own TTF and EOT files. Hope this helps. Am is Amharic, the national language of Ethiopia.

According to AM is the code for Amharic/Ethiopic text. Okay, I will try both your recommendations. The third-party server is my personal server, which I am using because I have more access to than the corporate server (one reason why one might use an absolute URL).

I created the EOT's involved and enabled all the domains. Still, I see the possibility that a firewall somewhere may be mucking things up. So to clarify a relative file reference. If I leave off the path, does the eot/ttf files have to be in the CSS directory or the html directory? Thanks so much for your help!

Duda - Which font doesn't show. #1 or #2 or either? 'real-font-name' means 'the font name that's likely to used on a local machine' (if it's found on a visitor's machine, it'll use THAT font, rather than download the version on your server).

You'll want to check why FireFox isn't downloading your TTF file (is it where it 'thinks' it is?) A link to your page would help. Guiye - Yes, that's one of the pages I found while Googling for the problem. Thanks for your feedback! Glad you got it sorted. Duda - Firstly, on the left-hand menu text (About Us, Portfolio, etc.) relies on JavaScript for formatting.

Looks like crap in my FireFox browser, which I normally run w/JS disabled. I don't see any reason why that relies on JS (?) and I'd recommend changing that to CSS, so it looks good no matter what.

Secondly, after having a look at your style.css file, I think your problem is what I thought - 'Where your font files are isn't where the browser expects them'. I looked at your H2 tags on (i.e., 'WE ARE HAPPY.' I see h1 through h6 all use the 'CondensedBlack' font family, which is defined as being url('HelveticaHeue-CondensedBlack.ttf'). The problem is likely that the CSS file is in some template directory, along with the font files (e.g., http:⁄⁄yoursite.com/wp/template/name/). Some browsers will look for files relative to the CSS file, so that 'font.ttf' can be found in http:⁄⁄yoursite.com/wp/template/name/, but others can't.

According the the CSS, FireFox is looking for the font in http:⁄⁄yoursite.com/font.ttf (and not finding it). What I recommend is this. Create a fonts directory off your webroot (typically 'public_html' (e.g. Http:⁄⁄yoursite.com/fonts) and put all your font files in there. Then, in the CSS, use a simple, absolute reference to the font file location url(/fonts/font.ttf). This will keep your fonts neatly organized, keep your CSS simple and - more importantly - fix your problem.

PS - The 'egg/brain' logo design work is very well done! I have converted the fonts to.ttf again using an online converted,, and now the font its running on FF on XP (my girl's computer). I uploaded the site to the right location so ROOT. And its with the right content already. As im not a html developer, and i needed to have this done quickly, i used as a base a template, that after i completely customized.

So Im not sure how to change the menu from JS formatting to css. Do you still have the problem seeing the menu. IM GLAD THAT YOU LIKED THE LOGO. Thank you very much, Duda. Serrano - Sounds intuitive, but I could see where it might trip someone up (there's so many places that problems hide, sometimes it's not readily apparent that it's a 'simple' thing, eh?). Will add & thanks for the note! Devon - An iframe inside a frames site?

Let me be the first to say, 'blech'! I'd recommend removing frames, as it's an ancient (and problematic) layout constructor. Regarding the @font-face. I found one of your fonts but notice you're using a 'relative' location in your CSS - that is url('fonts/karine.ttf'). Try changing it to the fully-qualified (absolute) URL linked above and see if FireFox give you satisfaction. Thanks for your response. As far as the relative url goes, it's not that, the font worked fine with the relative url and the whole url, UNTIL i added the php page in the iframe - in the php page's style code i use the full url, and it works in all browsers except firefox.

The only place i'm using the relative url is for the rest of the page (not the iframe) and it works in firefox. So that's not it.

Any other ideas? And as far as frames go, i'm only using an iframe because i know of no other way to contain a php generated page in an existing page - is there one? I assume i could make it all one huge page, putting all the html AROUND all the php stuff, but i don't really know how to do that and then i'd have one HUGE index page instead of a simple index page with seperate php sections in their own iframes like i have now. By rest of the page, i assume you know which parts i mean - everything not in the iframes. On my (latest) firefox the rest of the page works fine, and was not affected by adding the iframe.

It's just the content IN the iframe that doesn't work. And again, it does work in opera, safari, and chrome. ONLY not firefox. Which seems odd. The index.html has the style code in it, and works fine.

The php blogs that i implemented in the iframes, each have separate style.css pages, and on each of their style pages i put the @font-face code with the whole urls. Do you have any suggestion as to how to avoid the iframes? The only reason i'm using them, and the php blog at all, is so that the other people in my band, who do not know html, can easily log in and update the website themselves. I know no other way of doing this, but would love any suggestions. The new IE9 now supports TTF embedding.

While this is a good thing, it poses new problems because you will want the IE9 not to use the EOT font, but the TTF font instead (if you have a font with OpenType features, that is). So yet again, we have to revise the way how @font-face embedding must be coded. I am making tests with conditional comments.

I have deleted the EOT @font-face rule from the normal CSS and put it into its own CSS file. Then I have included that special CSS file with a conditional comment before the other CSS: