Starting in 1998 with Internet Explorer 4, and then from March 2008 through March of 2010, one by one, all of the “big five” desktop browsers—Safari, Firefox, Opera, and Chrome—have rolled out roughly comparable implementations of @font-face font linking. With these, an indispensable piece of the web publishing puzzle—a piece missing since the web began—has fallen into place, and a true web-specific typography can begin to take shape.
First, a roundup of recent events:
- A Web Fonts Working Group was chartered at the W3C on March 18, 2010. Its first order of business was to establish the WOFF specification as the standard compressed “wrapper” format for delivering sfnt (OTF and TTF) fonts on the web.
- Font rendering in IE9 using Windows’s DirectWrite has been unveiled via the see-for-yourself IE9 Platform Preview.
- The first round of web font preparation tools like Font Squirrel’s @Font-Face Generator and EOTFAST have appeared.
- A new wave of “font hosting and obfuscation” services (FHOS) have appeared alongside Typekit, Typotheque, and the free and open source Kernest.
- The first “trusting” web font licenses from commercial font designers have appeared.
- The CSS3 Fonts Module has evolved to include some of the advanced features of OpenType.
- Adobe Flash, once a reliable cross-platform means of text replacement (sIFR), now appears permanently crippled.
- Google has launched a free font-hosting service for a growing library of fonts. All of them available for self-hosting, too.
Let’s take them one at a time…
WOFF#section2
WOFF was formally submitted to the W3C Fonts Working Group on April, 8, 2010. Unexpectedly, Microsoft co-sponsored the submission along with Opera and Mozilla and support for WOFF is featured in developer preview builds of IE9. WOFF will be the standard “transport format” for fonts. It’s already in Firefox 3.6+, and the makers of Chrome have announced that it, too, will soon support WOFF.
Now, WOFF, unfortunately, has been hyped in ways that can mislead. So let’s stop a moment because it’s important to know what WOFF is and, just as importantly, what it isn’t.
Like its older cousin, EOT (Embedded Open Type) a WOFF file is, essentially, a zipped font file. It is not a font format in and of itself. It’s a font file that’s been packed up to travel. As PNG and JPEG are to image formats like BMP and TIFF, WOFF is to TTF and OTF. (Except that, unlike a compressed image, the original font can and must be extractable from the compressed file.) In practice, WOFF and EOT are very similar and the compression ratios are about the same.
WOFF is not a magic font format that will once and forever break down all the barriers that have stood in the way of licenses for commercial fonts. No, font producers’ fears about the web are much more complex than that—and we’ll examine them shortly in connection with FHOS.
IE9 and DirectWrite#section3
IE9 uses Windows’s DirectWrite rendering API. If you haven’t downloaded the IE9 preview I suggest you try to do so, it might cheer you up. If you spend any time at all with it, you won’t want to go back to IE8 and/or XP. (Mac users, no guffaws, please.) The font rendering in IE9 is worlds apart from what we’ve all come to expect. It’s certainly on a par with the Mac and in some ways arguably better. But whatever your personal opinion, at least the difference boils down largely to a matter of taste. One of the great side-effects of the focus on web fonts was the spotlight on just how wanting font rendering in browsers running on Windows had become in comparison to browsers on OS X. Note also that DirectWrite is a Windows API, not specific to IE, and other browsers like Firefox will be implementing it as well.
IE9 and @Font-Face the CSS3 Way#section4
What makes @font-face a viable cross-browser proposition now, today, is that—amazingly—IE has supported @font-face for over ten years. However, IE9 will be the first implementation of @font-face as described in CSS3.
The main changes are these:
Font Formats#section5
In addition to TrueType (TTF) fonts, IE9 will support PostScript-flavored OTF CFF fonts, as do the rest of the “big five” browsers. Now, removing this barrier to interopability is a good thing, but a word of caution is in order: If only in the interest of backward compatibility with IE 6–8, it will be some years before web fonts can stop being predominantly TrueType. IE 6–8 will only accept a TrueType font packaged as an EOT. And there are rendering issues to consider in other Windows browsers, as well.
Hopefully, font designers will help out by making their fonts available in TrueType with adequate TrueType hinting. Unless, as one type designer quite seriously suggested to me, everyone should just hold off on web fonts for however long it’s going to take for IE8 to fall off the map. Hah! Too late.
Syntax#section6
Within an @font-face “declaration” in CSS3, you, as a web author, get to do what the operating system does for you with the web-safe fonts. You get to group fonts into font-families by “declaring” them with the same font-family name. You get to differentiate members of that family by “declaring” each to be a differing combination of font-style (normal, italic) and font-weight (normal, bold).
Be aware that the terms font-weight and font-style have different meanings inside the @font-face declaration than they do outside the declaration in the main CSS rulesets. Inside the declaration, “font-weight:bold” means, “this is the bold member of this font-family;” outside the declaration “font-weight:bold” means, “apply bold to this text by using the member of this font-family that was declared as bold.”
In IE6–8 @font-face works the same way. However, in order for EOT files to work right, some of the naming and descriptive data within the TTF file from which the EOT is made needs to match up with the CSS declaration. Most of the time there’s no problem. But once in awhile certain fields inside the font’s data tables need modification. Should that happen, the issues are fully known and easy to fix. (The docs for EOTFAST have details.)
Tools for Web Fonts#section7
The essential tools web authors need have emerged:
The Font Squirrel Generator#section8
The Generator is a suite of online tools offering conversion, subsetting, CSS generation, and more. At the moment, it’s simply head and shoulders above anything else available on the web and, in the hands of font designer and web developer Ethan Dunham, it continues to evolve.
Also, you might want to familiarize yourself with some of the following free tools being used behind the curtain at places like Font Squirrel, Kernest, and Google:
- FontForge is a full-featured font editor with all sorts of scriptable server-side goodies. It’s also open source.
- sfnt2woff is a suite of open source tools for packing TTF and OTF CFF fonts into WOFF files.
- ttf2eot is a precursor to EOTFAST. It creates uncompressed EOT “lite” files.
- TTX is a tool to convert OpenType and TrueType fonts to and from XML.
- Fontue is an open source engine for serving fonts plus font-processing scripts, too. Contributions welcome on Github.
- WebFont Loader is a JavaScript library that gives you more control over font loading than the Google Font API provides. It was co-developed by Google and TypeKit.
EOTFAST#section9
Developed by myself and Philip Taylor of Cambridge UK, EOTFAST is a free, easy-to-use alternative to Microsoft’s nightmarish TTF-to-EOT conversion tool, WEFT. Use EOTFAST to create natively compressed EOT files for compatibility and quicker page load in IE 6–8. Note also that the EOT format has not been deprecated and will continue to work in all rendering modes of IE9, making it a handy way of targeting all versions of IE without resorting to conditional comments.
Trusting Licenses#section10
Trusting licenses—fonts at volume prices that provide both installable TTF or OTF files for ease of development as well as files for posting on web servers—are available from Font Spring. And the site provides—as every web font vending site must—an in-browser specimen sheet of the font so you can see what you’re really getting before you buy. Hopefully, other shops will adopt this simple licensing model.
Font Hosting And Obfuscation Services (FHOS)#section11
Until @font-face, browsers relied on the underlying operating system for fonts, so unlicensed use in web pages was never an issue. The OS acted as not only a technological, but a legal conduit as well. Rights to use the web safe fonts came with the operating system. But @font-face bypasses the OS and, instead, the fonts come from web servers. This presents commercial font producers with the prospect of great loss of control and a completely new set of legal realities. It also brings the prospect of a huge new market, but within the font industry it’s fair to say there has been less excitement about that than there has been wariness about the potential loss of control. The web market is an unknown, the print market is established. The conflict of new media versus old media is playing out once again, this time with fonts.
The concerns of commercial font producers go much deeper than the scenario of some visitor to a site seeing a font they like, digging into the CSS, and downloading it. Let me offer the following explanation so you can better understand why font services that employ obfuscation and, in some cases, rather long, obtuse, and grumbly licensing agreements, exist.
Font producers have seen what happened to the music, book, newspaper, magazine, and stock photo industries and they are afraid that the same thing is now about to happen to them. It’s been called the iTunes Effect, and it’s about price.
Font designers are very still very much focused on print. By and large, the money is in catering to professional customers in the printing industries: Books, magazines, displays, etc. Prices usually move on a sliding scale based on the number of users. 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 websites 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 it’s own?
Buyer Beware#section12
In response to this “Internet Threat,” some commercial font design houses have opted for font hosting and obfuscation services (FHOS). These services use, essentially, the Amazon Kindle model but instead of books you get what books are made with: Typefaces. Fonts are doled out in a measured and controlled way so the font creators know where each one is going and how it’s being used. The obfuscation focuses on preventing casual download and making the font uninstallable in the OS and therefore unavailable to print layout programs like InDesign. For these services, keeping the font file firmly in hand is the prime directive.
Growing out of discussions between representatives of font producers like Microsoft, Adobe, Monotype Imaging, and others in the wake of Typekit’s appearance last year, the past few months have brought FHOS offerings from Microsoft’s font distribution proxy, Ascender Corp, Extensis (specialists in font-management and licensing management software), Monotype Imaging, and a collective including David Berlow’s Font Bureau.
I can tell you that the folks at Extensis, Ascender, and Monotype are genuinely happy and enthusiastic about providing fonts for the web. But certainly they won’t be quick to point out that the delivery system for those fonts is crafted within the constraints of a clever but hacky DRM-like structure. This is understandable. But attempts to identify and prevent instances of unlicensed distribution through code have proved counter-productive for just about everybody and it’s hard not to view obfuscation as futile and irrelevant in the long term.
Font designer Ray Larabie said it best:
Protecting fonts from being installable in an OS will seem quaint and silly in a decade when using fonts for something other than the web will be a rarity. Install fonts on your OS? Whatever, grandpa! In the near future, nobody will even want to install a font on an OS.
Buyer Be Thankful#section13
But then again, there’s a flip side. You can view FHOS as a phase. Services are innovating. For example, the WebINK service from Extensis features a free installable “preview wizard” of sorts called Type Drawer that enables you, among other things, to instantly swap selected fonts on your page with drag and drop simplicity. This can be a huge time saver and it is certainly the kind of authoring tool designers need. Right now it’s proprietary to the WebINK service, but still it helps in shaping things to come.
A Checklist For Font Services#section14
Personally, my focus is on providing information for do-it-yourselfers. And as a web author, now that I don’t have to rely on the OS for fonts except for fallback, I’m uncomfortable with the idea of having an outside entity in control of something as basic and fundamental to the design of my site as a typeface. Further, every independent web designer I’ve spoken to about it has said they simply would not, under any circumstances, saddle a client with an ongoing expense for fonts. Thousands of free fonts are available, and many of them are of as high quality or higher than those offered by the services.
Certainly you should know, at the very least, what the technical differences are between what the service does and what you could do if you hosted the files yourself. Influenced by the checklist recently proposed by the EFF in connection with the explosion of digital books, here’s a kind of consumer checklist for those considering FHOS:
- Exactly what inefficiencies are being introduced in the effort to prevent visitors to your site from downloading and installing the font in the OS? And how many additional http requests are being made as a result?
- Has caching been disabled? Will users be subject to a Flash Of Unstyled Text (FOUT) with each session?
- If font file splitting is being utilized as an obfuscation technique, how might it effect things like spacing and kerning? And does the file splitting increase the likelihood of failure in some browsers?
- Is the service truly “standards compliant” in that it allows you to use the CSS3 standard in its full breadth and scope as it is currently implemented by those browsers that support @font-face?
- Is the End User License Agreement or Terms of Service understandable? As a business contract, are you comfortable obligating yourself or a client to its provisions? If you stop using the service and begin to host your own fonts, can the agreement conceivably compromise you in any way?
- What is the privacy policy? Is the activity on your site being monitored and logged and if so, how? And what is done with that information?
- Do the terms of the contract define the rights of visitors to your site? As your “users,” are visitors licensed to use the font not only for onscreen display, but for printing and the creation of PDFs, as well? Are visitors who attempt to download the font files individually exposed to any risks under the DMCA? (Let’s face it, we all deconstruct and examine parts of other people’s sites. That’s the web.)
- Once WOFF (and EOT) support is ubiquitous, is there a path to self-hosting or will you forever be locked in to the service?
Comments, please.
Advanced Features Of OpenType#section15
With Mozilla’s John Daggett taking the lead as author of the CSS3 Fonts Module, an impressive team of “invited” type design experts are doing the hard work of thinking through the problems of advanced typography at the W3C.
In the near term, this can have a big impact on the display of mathematical symbols and non-latin languages.
The Future Of Flash Text Replacement#section16
It’s been years now and Flash still isn’t allowed on the iPhone. It’s forbidden on the iPad. Steve Jobs’s recent pronouncement has gotten a lot of attention and it’s very hard to see Apple backing away from this decision. Plus, the iPhone and iPad both support a much simpler and elegant @font-face alternative to font rendering using the SVG format. For any developer contemplating a new project, it’s hard to see how sIFR makes any sense. @Font-face presents a lower learning curve and it doesn’t need to have a future, it is the future.
Google Hosts Fonts#section17
In a suprise development that grew out of informal talks with the folks at Typekit, Google has become a provider of openly licensed fonts via the Google Ajax API’s. It’s been set up as an open source project and you’ll find documentation, examples, and information on how to contribute at its GitHub repository. Unlike a lot of open source projects, this effort has a full time curator in Raph Levien. Interestingly, in spite of the fact that fonts are quite often the product of teams, some knowledgeable observers assert that fonts defy open source collaboration. Well, we’ll see.
Making It Work Today#section18
All together now, let’s get really confused: for IE 6–8 you can only use TTF fonts wrapped up as EOT or EOT “Lite” (uncompressed). For Firefox, Opera, Chrome, and Safari, you can deliver TTF or OTF files either “raw” or, in some cases, wrapped up as WOFF files or as data URI’s inside a stylesheet. SVG will surely be a major font format going forward but its main virtue today is support in Mobile Safari for the iPhone and iPad. Got that?
Yes it is confusing. At first. Major changes always are. But I expect that web authors will do what web authors have always done: Find a way to make it work. The raw materials are there. The tools are there. The workarounds are there. So put together some sample pages and templates, and prepare for the crossing. The time has arrived.
I know that @font-face has been around since IE4 but the recent developments have been great and I can’t wait to see what the future of web fonts brings.
It not only changes the way that I design but the way that I code. Now that I’m needing text-replacement less and less, my sites are more quick; something that is incredibly important now that Google are basing rankings on site speed (to a certain extent).
I feels like I read at least one article per week about new developments in web fonts. Every time I see an article I think to myself great, finally a solution to the age old web font problem, yet after every article I come away with the same, empty feeling. While all the articles I’ve read about the progress of fonts on the web all discuss various thoughts about how things will eventually change, so far the end result is still hacky workarounds and mixed ‘standards’. sIFR, cufon, @font-face, and on and on and on and I’m still left with no single good solution. If I want to display an image on the web, I can easily post a gif, jpg, or png. They work. No kludgy workarounds needed (IE/png yeah yeah). I don’t mind discussing the progress of fonts on the web, in fact it’s vital for progress to be made, but can we stop rehashing the same argument about what currently works and doesn’t work and how ‘someday’ things will be better? Let’s focus our energy on advocating a real solution, one that will benefit font and web designers. Why it’s taken over a decade and a half to get fonts right is beyond me.
I think we already have great solutions for webfonts. Despite rendering issues, that will soon be covered by Microsoft on Windows, and despite the time taken to users upgrade, I feel comfortable about the WOFF solution (and I’ll be even more pleased with the advanced OTF capabilities).
I can’t though be more unsatisfied with the overprotecting rules pushed by font foundries. It seems like they’re trying to cover they fear of not controlling their product by fooling customers with confusing EULAs and abusing fees. They advertise themselves as underpaid geniuses and ending treating customers as thieves. It’s clear to me, by observing fair distributors like FontSpring and exljbris, that there’s something wrong with the “traditional” and bigger foundries business model.
What I can say by myself is that I won’t bite. I’ll continue to buy fonts from small foundries and hope that someday the bigger ones will eventually see the money they lost by treating web professionals with such ignorance.
I also wanted to say that I really admire font designers, their passion and their product. I understand that they are trying to figure how to distribute their work. Maybe they should take some lessons from small and successful software companies.
I feel optimistic about this empty feeling – as catchmyfame described – going away.
First off, I’d be remiss not mention “Fontdeck”:http://fontdeck.com/ as another font service to add to the mix. Plug over.
Secondly, I think it’s worth taking a step back and thinking how far webfonts have come in a matter of about 18 months. _catchmyfame_ may say _it’s taken over a decade and a half to get fonts right_ but the reality is that it’s taken only year and a half. Webfonts only really became a viable possibility once Safari and in particular Firefox supported them as well. Until that happened we could only use EOT on IE and that simply wasn’t good enough.
What has happened in a matter of months is the opening up of a whole new marketplace – nothing unusual there; it’s what the Web is good at. But what also happened was a complete turnaround of an industry – font ‘foundries’ and designers went from ignoring the web as a marketplace to embracing it. Maybe not all whole heartedly, and certainly not all immediately, but nonetheless I think the font design community (for that’s what it is) deserves some kudos for this, and should be cut some slack. Any comparisons with the music industry should be dismissed as hokum.
A correction: IE8 can, in fact, render EOT with CFF/PostScript outlines (unlike previous versions). For a while, the trick was actually getting such an EOT built, since WEFT doesn’t support CFF/PS. Today, there are some options for getting such an EOT built. Of course it will look pretty bad, since IE8 still uses GDI, which doesn’t do a good job with CFF/PS fonts.
@catchmyfame:
@font-face doesn’t belong lumped together with sIFR and Cufon. @font-face is a standards-conformant solution. There is nothing temporary or hacky or proprietary about it. Implementations may differ for awhile but that IS the way fonts will be linked to web pages. Period.
@victornogueira
I, too, like the simplicity of a pay-once and be done licensing model. I believe a lot of customers will be lost to those who don’t offer it. But that said, +1 to what Richard Rutter said about comparing font designers to the recording industry. I haven’t seen any villains appear in this drama yet. Just people trying to figure out how to adjust to the realities of digital distribution.
@Richard Rutter
I’m sorry. I had no idea Fontdeck was out of Beta and alive and going. Hey, keeping up with this stuff is starting to get complicated, you know? Gotta sleep, sometime. I owe you a blog post for this, certainly. 😉
Note: I have to fly from Florida to Rochester, New York today but I’ll back…
I asked this one over on typophile.com earlier today, but did not get any bites. Does anyone here know why iPhone/iPad/iTouch only supports SVG @font-face implementation, and not TTF (or WOFF)? Seems strange to me since Safari supports TTF from version 3.1 and later. Richard referred to SVG here as a “a much simpler and elegant @font-face alternative to font rendering” and “a major font format going forward”. Please elaborate. Might help to explain why Apple is not supporting TTF for Mobile Safari.
I’ve been trying all sort of hacks, scripts and what not to add custom fonts to my websites for a long time.
The solutions described in “Making it work today” are the first that actually worked. I didn’t think I would see a custom font render on IE6 in Windows XP. And by custom I mean any font that doesn’t come with a standard installation of Windows, Mac and most Linux distributions.
It’s not perfect, but to me it’s fine for now.
bq. As PNG and JPEG are to image formats like BMP and TIFF, WOFF is to TTF and OTF.
I think this is a bit misleading. A jpeg is a file format and a compression method. Tiffs can use jpeg compression (or zip, or LZW). PNG isn’t just zipped BMP either.
Otherwise, very interesting article 🙂
@chris roberts
Why does Safari Mobile only support SVG? I don’t know, a mystery to me so far. But other mobile platforms don’t support @font-face at all, as yet, either. Expect to see fallback fonts for some time to come.
@Radu.Tanasescu
I’m glad the “making it work” rundown helped clarify things for you.
@skilldrick
Consider me niggled. In broad strokes, though, I think the analogy between WOFF and compressed image formats like PNG and JPG helps get the point across.
I knew there was a reason I was holding off on buying that typeface I really liked from this big name distributor. (That kind of behavior is not usually in my nature) I reread that distributor’s confusing EULA and right away saw exactly what Richard was talking about. Went over to fontspring and found the exact same font for the same price (with an option to purchase @font-face for a little extra) with a lot less restrictions. Thank you both!
Hi Richard — a nice article, with some good info. As you summarized, “Yes it is confusing.” I think part of this has to do with the variety of different perspectives on this topic.
Like you and many other readers of this article, my company, “Ascender Corp”:http://www.ascendercorp.com, is passionate about web fonts and the potential it has for all the stakeholders. We have invested a lot in developing various web fonts solutions and web sites. Our goal is to provide web designers & developers with the best quality fonts and the typographic tools they need to implement web fonts.
Unfortunately in your article you have glossed over some key points that add to the confusion.
*Quality*: this is one of the key challenges with web fonts today. Fonts may look good at large headline sizes but totally illegible at small text sizes. Fonts may not look the same in Mac and Windows. Fonts used in a Photoshop wireframe design mockup may not render same when viewed as web fonts in web browsers. Why is this? The simple answer is that web fonts are different from print fonts.
High quality web fonts need to be carefully designed, hinted and proofed. At Ascender we have chosen not to simply dump our collection of 10,000 print fonts onto the web. This would be a disservice to the market and would not further our collective goals of improving the typography and readability of websites. Instead we are investing a significant amount of time and resources in optimizing fonts for the web.
Our efforts are led by Tom Rickner, the renowned type designer and font developer who hinted the fonts we all use everyday (and many take for granted) in Macs, PCs and mobile phones: Georgia, Verdana, Segoe UI, Droid, Prelude and others. We have a very strict, high quality bar that we have set for the web fonts we offer today, and those in development. In summary, not all fonts are created equal and web designers will figure this out one way or another (hopefully by not “pulling a Boing-Boing” by trying to implement a poor quality free font).
*Font Hosting Services*: I think it is a bit disingenuous to add “obfuscation” and try to coin a new acronym to describe our approach to serving web fonts. Don’t we already have enough acronyms? EOT, WOFF, TTF, OTF, SVG, FOUT… 🙂
One of the many benefits of web fonts hosting services is that they simplify the process and cut through the confusion. Making web fonts simple has tremendous value to web sites of all shapes and sizes. The service we offer at our “FontsLive”:http://www.fontslive.com site, and the service we are developing with the Font Bureau at “Webtype.com”:http://www.webtype.com will provide significant value to both those who want to host their own fonts and those looking for an easy way to plug in web fonts without all the hassles that you’ve pointed out.
What I take issue with is your comment that Ascender’s web font delivery system has “a clever but hacky DRM-like structure”. We went out of our way to avoid DRM, and built our system following web standards without “hacks”.
Best of all, our web fonts system works for both our customers who use our hosting service and for those who host our web fonts on their servers. So yes, even a web font hosting service still has value to websites that want to host their own fonts. One of the benefits of FontsLive.com, and soon Webtype.com, is that we can generate all the web font files along with the CSS which customers will need, thus simplifying the process even for self-hosting websites.
The value we provide is not only high quality web fonts optimized for rendering on screen, but also an easy way to obtain and implement the web fonts. So I think your comment about web fonts hosting services being “a phase” may not prove to be true in the long term. Only time will tell. I look forward to ten years from now and looking back on 2010 as “˜the year of web fonts’ to see how it turned out for us all!
To: Bill Davis
>Our efforts are led by Tom Rickner
Who I’ve had the pleasure of spending the past few days with at the Future Of Reading Conference at Tom’s alma mater, RIT, in Rochester, NY. (Along with your colleague Steve Matteson, too.) Great people, and deeply committed to quality font design.
Quite true.
As for my choice of words, I stand behind them. But if, in the future – as user agents and business practices change – they no longer apply, I will happily say so loudly.
All I advocate is informed, smart decisions.
So what I would suggest is this: anyone reading these comments should go right ahead, try your service(s) under the free 30 day trial, and then, kindly report back on what problems, if any, they found and/or foresee. Including the pricing (based on bandwidth) and in light of the checklist.
Fair enough? That would be a win all around, I think.
Great article –
I’ve been waiting for this day for a long time however, something tells me that millions of dreadful websites made with Comic Sans and Papyrus will be popping up everywhere.
But current implementations are either too legally restrictive or too technically complex to be worth our time…
@Richard,
_> As for my choice of words, I stand behind them._
I think you missed my point that you make references to Typekit, but then say that Extensis, Ascender and Monotype use DRM or hacks.
Not true at all.
We went out of our way to design our FontsLive site making it as efficient as possible, and delivering W3C compliant web fonts. I can’t speak for the others, but I don’t think any of us appreciate being painted with a broad, tainted brush. -:)
Richard: The www needed this article. I feel, however, you omitted to say EOT has always been able to overcome the licensing problems with domain specific fonts.
Why doesn’t WOFF do this? It’s beyond me!
Why didn’t the community embrace and develop on EOT? Probably because the old eot generator from MS offended us so badly with lots of other things besides TTF and OTF to EOT conversion, muddying the process with unrelated, un-useful functions. But EOT still remains a zipped, DRM’d format.
After reading this article, I got interested in trying out @font-face. The resulting performance made me think I must be doing something wrong: 7 to 11 seconds to load my page?! I began to look around for solutions but all I got was confirmation that this was ‘normal’ for font downloading. (See “Steve Souder’s Tests”:www.stevesouders.com/blog/2009/10/13/font-face-and-performance/) I must admit I am rather disappointed, but hopeful. Is there a solution to the performance issue?
RE: the guy who posted comment #18. Yep, tried that too. Some of these load times are just out of control.
Also tried Google fonts. Some are okay, buy on the whole they’re nothing much.
At this moment in time, I’ll stick to what’s already on user’s systems. Trebuchet, Arial, Georgia and Times. Just like ALA!
In listing point #3 in the initial roundup of the article there’s a link to EOTFAST. This website is reported as an attack site by Google. See link for details
“See link for details”:http://safebrowsing.clients.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=http://eotfast.com/
Hello,
First of all, thanks for the article. I’ve translated it to Russian and posted in my website, while keeping all the credits:
http://cascadi.ca/misc/fonts-at-the-crossing/
“Protecting fonts from being installable in an OS will seem quaint and silly in a decade when using fonts for something other than the web will be a rarity. Install fonts on your OS? Whatever, grandpa! In the near future, nobody will even want to install a font on an OS.”
definetely 😉
Im not complaining, but it would be nice if there was a general font format that all browsers accept! Less trouble in finding free fonts that work for all browsers. 🙂
Hi, I am new to this blog and this is my first post. I really enjoyed the article so I said I would say my bit. I have being doing Web design in Ireland for 3 years now and for ages I always had the problem with fonts, which ones to choose, which will actually come out ok on web browsers? For the first year I used Arial (save as houses) then I dabbled in Georgia and Myriad Pro and others. I eventually got sick of them and wanted a good choice so I researched it and kept seeing Google fonts coming up. I tried it out and WOW once you install them they look mint on a website. You get a great variety and you can type the words you like and see what they will come out like (in browsers) before downloading the font for FREE. If you are a newby like myself you will love this tip. Hope im a help to someone
Thanks for the info I always find it difficult to present information in a professional manner while obtaining the not so serious feel of a site. by the time i get to choosing a font im usually burnt out so thanks.