The return of font embedding to the web?
Sadly, quite a bit of what I wrote in this article is based on out of date information, and on my own testing that had a fatal flaw. I’ve left the article as it is, and added corrections inline
Most web designers and developers will be familiar with Image Replacement techniques, pioneered by early CSS guru Todd Fahrner [1] (FIR or Fahrner Image Replacement technique), and subsequent attempts to address the usability, accessibility, and other concerns associated with it.
These techniques emerged to address a significant problem with web design — it was not possible to embed specific fonts in a web page. So developers you could either rely on a small number of standard fonts on various platforms (and risk losing clients, or getting fired), or use images for text in some way. IR techniques definitely had advantages over using img elements, but were, and remain, far from ideal.
What a lot of people probably aren’t aware of is that even in Netscape 4 and Internet Explorer 4 there were ways of embedding fonts (or more strictly linking to font files online that browsers could then download and use for rendering the page.)
Uunfortunately, each browser had its own, proprietary format for doing so. Then, when Netscape 6 went open source, it could not open source the TrueDoc code it used to manage embedded fonts, and so font embedding, rarely used, was dropped in Netscape. While it persisted in Internet Explorer, developers very rarely utilized it.
CSS3 (and even drafts of CSS2 in 1997 and 1998) have long promised a standardized way of font embedding, using the @font-face rule. What many folks probably don’t know is that this rule is already supported in Opera 9.5, shipping versions of Safari for the Mac, Windows and iPhone OS, and is promised for Firefox 3.1., and well as IE6 and later.
Sadly, while support for @font-face was hinted at for Opera 9.5 and Firefox 3.1 (see my comments at #4 below) this is in fact not the case sadly.
There is a catch though. All the browsers other than IE support linking to TrueType font files. Microsoft supports only the proprietary EOT file format. They are however proposing to standardize Embedded Open Type (EOT).
While the way in which you specify fonts to embed in IE (using @font-face) is identical to how fonts are specified for the other browsers mentioned, Microsoft appears to be refusing to countenance supporting embedded fonts in formats other than EOT (specifically the extremely widely supported TrueType format, which the other browsers mentioned do support.)
There’s a lot of discussion (a lot of it heated and polemical, thankfully some more rational even if passionate) going on around these issues.
Bill Hill at the official IE Blog started the conversation with the announcement of a relationship between Microsoft and font foundry Ascender Corporation, and a discussion of EOT, and technical and legal issues around embedding fonts (it might have been more politic to separate the announcement from the discussion). This post included the announcement of the Font Embedding community, which describes itself as
A resource for designers, developers and typeface creators on font usage, technology and licensing issues
Joe Clarke, who’s spoken at a number of our events, and is never one to leave folks guessing what he is thinking, rather directly criticised the post (though the criticism is not entirely focussed on the issue of font embedding).
Chris Wilson, now platform architect of Internet Explorer, long time IE developer (and prior to that Mosaic developer (prior as in 1994)), co-chair of the HTML Working Group, and long time champion of web standards also posted a detailed discussion of the issues and his thinking. He writes
I’ve been clear on this to the CSS WG, so I suppose I should be here too — we (Microsoft) should NOT support direct TTF/OTF embedding, unless 1) there is some check that the font intended that use to be allowed, which I don’t think there currently is (as it needs to refer to the license agreement), AND 2) other browsers also implement a system that actually ENABLES commercial fonts — those that are allowed to be embedded, but cannot be legally placed directly on a server — to be used.
This is followed by a robust discussion, again often polemical, but well worth reading to get a sense of the issues.
Mozilla developer, Robert O’Callahan, recently posted on this issue, and discusses some of the issues around intellectual property protection.
The following is not correct, in the sense that it does not work for Opera 9.5 and Firefox 3.1 — only Safari 3.1 allows @font-face linking to TrueType files, and IE @font-face linking to EOT files. So the technique outlined should work, but only for those browsers.
But where do we stand as web developers? I consider it very unlikely that we’ll see Internet Explorer support formats other than something like EOT (Wilson says at one point “I don’t personally even care that much if that system is EOT as it is today”). But, there is some good news in all this. At least the same standardized approach to font embedding, using the @font-face rule works for all modern browsers. While I think it will be no small time until Internet Explorer supports direct font linking to formats like TrueType, all the major currently released browsers (IE6, IE7, Firefox 3.1, Opera 9.5, Safari 3) currently, or will shortly, support font linking or embedding using the same @font-face rule.
While it appears to be a return to the bad old days of IE/EOT versus Netscape/TrueDoc, is there in fact a way of using a single style sheet and serve embedded and linked fonts to all these browsers, so that each browser will use the intended font? Well, in fact there is. Here’s how.
@font-face rules specify a name for a font (you then use this name in font-family properties in the same style sheet) and a src where the font file can be found.
Instead of just using one @font-face statement, we’ll use two. The first will specify a font with an EOT file for Internet Explorer to use, the second a TrueType file for the other browsers to use.
The first @font-face rule looks like this
@font-face {
font-family:"Fenwick";
src: url(fenwick.eot);
}
We specify a font-family name, in this case “Fenwick” (which happens to be the name of the font — but you can use any name you like here, it is merely a way of identifying the resource in the src property of the @font-face rule), and a src — which is a relative or absolute url to the font file.
(As an aside, I created these EOT fonts using the tool found at Font Embedding, and the fonts created are licensed to be used on web sites).
Next, we specify a second @font-face rule, for browsers that support TrueType file linking.
@font-face {
font-family: "Matrix";
src: url(http://www.westciv.com/CSS3Tests/matrix.ttf) ;
}
The font doesn’t look anything like Fenwick, I just happened to have it online — it’s a free font in the style of the Matrix movie’s credits.
Now, we just need a statement in our style sheet to associate these fonts with, for example, paragraphs. It’s probably one of the very first statements anyone uses in CSS
p {
font-family: Fenwick, Matrix, san-serif;
}
When a browser comes to styling paragraphs with this CSS, it will first look for a font called “Fenwick”. Internet Explorer will use the font defined in the font-face rule, while the browsers which support @font-face, but not EOT, will use Matrix. Browsers which don’t support @font-face (Firefox 3 and earlier, Safari 2 and so on) will simply show a san-serif font.
You can see this in action here.
Yes, it’s a little bit of extra work, but it’s definitely technically possible (leaving aside licensing complexities) to now embed fonts for any contemporary browser. To me this is extremely exciting.
Now what we really need is for font foundries to realize the potential bonanza for them in licensing their fonts to be used like this, rather than focussing on the possible losses of people making unlicensed copies of their fonts.
[1] Todd, an original CSS Samurai, CSS working group invited expert, and designer with Verso, one of the early super star web design firms left the world of the web to run his own bike store in Portland Oregon. Plenty of times I envy him the wisdom of that decision.
Are you positive that Opera 9.5 supports the @font-face construct?
Actually, I don’t believe any browser other than Safari supports this currently.
You fail to mention, btw, that the only part of IE’s font embedding that is proprietary has been the EOT format itself — we use the CSS3 @font-face proposal to set it up. We have also contributed the EOT format into the W3C, with support from Adobe.
And BTW — though I’ll talk about licensing in response to Robert’s post — I would explicitly note again that the direct-TTF linking will only not violate license for a distinct set of non-commercial fonts. In fact, very FEW fonts, because even most freeware fonts want attribution and their license to be delivered with them.
The problem with @font-face is that it violates the font manufacturing license agreement with the end-user. Put simply, it readily enables font piracy. Any font embedded this way can be downloaded to the web viewer’s machine, and used as if he or she had paid for the font. Hacker skills are not required. The ability to download embedded fonts is readily discoverable to any competent browser user.
I’m sure this was not Håkon’s intention (and it’s not something we knew about when we published “CSS at Ten”) but I worry that a standard for embedding typography on web pages was created seemingly without involving people who make typefaces. Why weren’t typographers consulted before the standard was released? (If they were consulted, were they asleep? Were the technical ramifications not explained to them?) These are questions for Håkon, not you, and post-mortems don’t matter anyway (except as a guide to what not to do next time). But however we got to the spec we have, we have a problem.
My colleagues and I have been greatly concerned about this issue. We want to create websites that use fonts other than Georgia and Verdana and don’t require Flash and JavaScript to do so. We want to do it with web standards that naturally extend the capabilities of CSS.
I don’t know enough about Microsoft’s approach to endorse it wholeheartedly. (That’s not a lack of endorsement; it’s “I haven’t had time to get to the bottom of this yet.”) But what several colleagues and I like and appreciate about Microsoft’s approach is that it prevents font piracy — or at least makes font piracy extraordinarily difficult.
People may resist EOT because it’s from Microsoft or because we already have a standard; but that’s putting the W3C seal of approval cart before the “don’t put font designers out of business” horse.
I have to take issue with this statement:
“all the major currently released browsers (IE6, IE7, Firefox 3.1, Opera 9.5, Safari 3) currently, or will shortly, support font linking or embedding using the same @font-face rule. ”
Firstly, if Opera 9.5 supports direct linking to TTF’s via the @font-face rule, it’s a well-kept secret because Opera’s own documentation says it doesn’t and I’ve tested it. No font-face support at all.
Secondly, Firefox 3.1 does not support @ font-face for direct linking to TTF’s or EOT’s either.
Thirdly, what evidence do you have that Opera and FF will “shortly” support it? Have you spoken with management at Mozilla and Opera about it? Or is it simply a psychic vision kind of thing?
The evidence, so far, points in the opposite direction. Hakon Wium Lie, the chief technology guy at Opera has been hawking the idea of directly linking to TTF’s for two years now, and Opera still has not done it.
See these two articles:
Forgotten Monopoly
The Next Big Thing
I believe this is because there are serious unresolved legal issues involved. Lie himself alludes to them in the articles cited.
Lastly, Internet Explorer has supported the @font face CSS rule for EOT embedding for ten years. It does not, however support linking to TTF files directly and it’s been authoritatively stated that they don’t intend to.
comment
Zeldman stated:
Wilson stated:
Wilson’s statement was the first indication, that I am aware, that the CSS3 proposal has support from a firm who is both a Microsoft competitor in Internet technologies and also a font foundry, i.e. Adobe. It says much.
@chris
it definitely wasn’t my intention to be critical when using the term “proprietary”, and it was definitely to draw attention to both the proposed EOT standardization (as a W3 recommendation, whose strong, liberal IP policy is the best possible place for it) and that the font lining/embedding mechanism was using @font-face — a (kinda only in the sense that it isn’t a published W3 rec) standardized approach, as for other browsers
@Richard and thacker
As you’ll now see from my inline additions, I made a couple of errors that reinforced one another in coming to the conclusion of support in FF3 and O9.5
I’ve been tracking reports of this for a while, and got a sense that this was coming from things like the following
http://www.mindfly.com/blog/post/2008/07/The-Good-Side-and-Bad-Side-of-Font-Face.aspx
http://css.dzone.com/news/css-support-firefox-3-and-oper
http://archivist.incutio.com/viewlist/css-discuss/93353
and elsewhere for both browsers — perhaps evidence of the echo chamber at work in a number of cases
Couple this with my testing error — I had at some time in the past installed the Matrix font on my system, and it is called Matrix — so it appeared to be supported on my system for Opera 9.5 in testing :-(
Thanks for pointing this out
john
@thacker,
the EOT proposed standard includes support from Microtype, who
Chris, is there any more information on the “support from Adobe”?
Thanks
john
Allsop–
In my view, that was a reasonable oversight.
Just from testing standpoints of an EOT is confusing … a font management application and bare minimum device fonts within the Windows font folder are a necessity. And the WEFT tool can only create fonts that are present within the Windows font folder based upon my experience. Bottom line, it happens.
Thanks for the ‘fess up. You’re a mensch, I see.
In discussing “support” for @font-face the devil is in the details — it’s important to distinguish between support for linking directly to TTF’s and thereby encouraging font theft and the wrath of the font-making community (as Zeldman alludes to) in contrast to linking to an EOT; a site specific encoded and compressed format which deliberately tries to preserve the terms of the license for the font.
@John I’ll have to look it up. Sorry, I’m on vacation this week. :) I’ll look on Monday.
@Richard,
thanks — thanks goodness this is blogging, where accuracy is optional :-/
I deliberately left out any real discussion of the legal/ethical issues around this topic for the article as I wanted to focus on the technical side. Too often all these issues get mixed up, and I think separating them out might have some value.
I do want to address the legal issues in an upcoming article. The problem is that this issue seems to largely polarize, as the discussions following several of the articles linked above demonstrate.
@Chris,
thanks — enjoy your break. Here’s hoping we get a breakthrough in what has long been desired by web designers, and which will be particularly welcome among east asian developers.
@Jeffrey,
As I mention in my reply to Richard, I steered clear of legal/ethical issues in this article. That’s not to say they aren’t important (you’ll note my example uses a TT font for which the license allows linking, and specifically licensed fonts for the EOT example)
I hope to put together something that canvasses this issues, and highlights the sense in both major arguments around linking.
@john re: legal issues pertaining to Font Embedding in browsers
I’ve looked into it quite a bit and the best roundup of the applicable case law and the main legal issues that I’ve found is:
Sony Revisited
A 27 page pdf (in readably large type) and thankfully as free of legalese as it’s possible to get with subject matter of this nature. (IMHO)
Thanks Richard,
my (non expert but not entirely untrained) opinion is that following the court’s reasoning in SONY, browsers clearly have “substantial non-infringing” uses. Even font linking to TT fonts has a substantial non infringing use (for instance linking to TT fonts that are expressly licensed for such purpose, of which there are very many).
And so, I doubt browsers implementing simple linking to TT fonts would be on any kind of shaky legal ground. Mind you, the cost of defending (and indeed bringing) such a case would be extraordinary, particularly with such a strong precedent in SONY.
I have to disagree with your assessment. I think the legal ground is very shaky and very, very difficult to assess. Much has happened since the Sony case — there’s been Napster, Grokster, Aimster, and other lower court decisions.
How gray?
Here’s a fictitious scenario quite easy for anyone to understand:
Let’s say I, Richard Fink, am browsing using Safari. And in the course of doing so I go to a site set up by Joe Allsopp that is using a direct link to a TTF font file that you don’t have a license for. At that point I, too, am infringing by having gone to your web site and loading the font into the RAM in MY computer, at MY house. I have been induced to infringe, without my knowledge, by both Apple and you. And there is case law that strongly suggests that the copyright holder of the font is entitled to damages from Apple and/or you.
Maybe even the service provider has some liability. Maybe even me. (Product idea: “Phont-Protect” — a plug-in that filters out fonts called with the @font-face rule to keep users on the right side of the law…)
Anyway, the issues are complex and the case law vague.
Here’s my bottom line question: Does Apple’s implementation of @font-face, with it’s non-discriminating ability to link directly to TTF font files encourage piracy? My answer is: Yes, of course it does.
I have no dog in this fight, I’m just very suprised that Apple would go ahead and poke Adobe, Microsoft, and the Font-Design community in the eye like this.
What did they gain except ill-will?
These are issues for the foundries, browser manufacturers, etc. to mull over. What a foundry has to explore are — what is happening within the market, how is that market changing, what is our risk if the market change is not met and if it is met, what are the finance opportunities for meeting that change.
I, as a consumer, do not give a damn about any EULA that accompanies either a font or a toaster. If I have a need to use that toaster to toast wheat bread and only white bread is allowed by an EULA, well .. enough said. That does not imply, as some have incorrectly assumed, that it means that raw font linking is supported. What it does mean, in part, is that a market need exists, that the market need is growing and that Internet communication is a vital part of business. Markets will find a way — good, bad or indifferent. It is the foundries’ choice to win or lose within that change.
Richard,
I certainly think there is an argument there around inducement to infringe. But it applies not merely to fonts — but any intellectual property — fonts themselves are not privileged in any special way over other forms of IP (in fact, in some ways, they are less privileged than other IP).
So, for a court to so decide opens up the possibility that the owner of IP in code, text, images, and so on will bring similar actions against browser developers. The RIAA would have a field day with that.
“Here’s my bottom line question: Does Apple’s implementation of @font-face, with it’s non-discriminating ability to link directly to TTF font files encourage piracy? My answer is: Yes, of course it does.”
I’d argue that it no more encourages piracy than a browser being able to link to arbitrary files served via http or ftp encourages piracy. It enables the copying of font files to a local system by those who explicitly decide to do so, in the same way that video recorders “enable piracy” by enabling copies of TV.
But this is the heart of SONY — video recorders have a “substantial non infringing use” — as clearly do browsers (even specifically with regard to liking directly to formats like TT). The inducement aspect introduced in Grokster appears to specifically address a loophole in the SONY decision that enabled file sharing services to argue SONY’s protection for devices with substantial non infinging uses. In Grokster, the court’s reasoning in very clear
That suggests strongly intent to induce, as evidenced by expression or action is required.
I can’t remotely guess why Apple has done this — but things seem to have started moving on this front — perhaps that was their intention?
@john
All points well-taken. But then why did Napster lose?
Ahh, the hell with it. My brain is fried.
@thacker
Yes, I think the font industry needs to get hip quick but I don’t have high hopes. They need someone to do for them what Clive Davis did for the record business back in the late sixties, early seventies. Re-examine the sense and purpose of traditional business practices in light of the new realities. Based on what I’ve read, the industry is still focused on print media.
Shortly before he died, famed Mafia leader Charlie “Lucky” Luciano (the “Capo De Tutti Capo” — Boss Of Bosses) gave a series of interviews in which he, at one point, complains that too many of the local bosses can’t see the big picture — “Can’t see their way past a bowl of pasta” was how he put it.
Well, it’s time for the font industry to see past the pasta, or else.
The “@font-face” ‘style’ worked like a charm in FF3.0.1. One question: how can I ‘call’ it to only one or another paragraph instead of EVERY paragraph? I really only want it for specific Lines not even really paragraphs, more like headings I guess…
Before I tried this, I had to take a capture of what I wanted and insert the pic. (see site) But now that I know this little code will pull the font (click on the word “Welcome”) I need to constrain the font to where I want it.
Make any sense? John? Anybody?
matthew
Matthew,
If you want only specific heading levels, you’d use a selector like this
h2 {}
If you want specific paragraphs, then there are a couple of options. The most widely supported is to use a class value on the paragraphs you want to style. For example
Then use this selector
p.introduction {}
or you could use the nth-child selector (supported in all current browsers other than IE). for example
p:nth-child(1) {} selects any paragraph which is the first child element of its parent element.
Try our CSS guide for more details on all of these
http://westciv.com/wiki/CSS_Guide:_Introduction_to_Selectors
thanks, HTH
john
I think I just answered my own question…
All I did was notate a number after the ‘p’ in the ‘style’ code (p1) (p2) (p3) and so on… now I can use several different fonts in different places just by calling that at the opening of the paragraph section () instead of just ()
THIS WORKS GREAT!!!!!!!!!!
(I wonder, is it supposed to work like this?)
(Have I discovered an “Undocumented Functionality” that actually is a positive instead of a pain in the @ss!)
matthew
Sorry, didn’t read before posting, didn’t think anyone else would be up AND posting to this exact blog right now!
But Thanks for the rapid response, although what I described DOES work in IE7…???
And I think what you’ve listed there is just slightly different than what I did. I think…
[…] and “embedding” (aka EOT). With Firefox about to implement support for linking à la Safari, John Allsopp has a summary of the state of font technologies and an illustration of just how easy it is to use these in […]
Jeffrey Zeldman: “The problem with @font-face is that it violates the font manufacturing license agreement with the end-user. Put simply, it readily enables font piracy”
The problem with the IMG tag is that it violates the photographer’s licence agreement with the end-user. Put simply, you’re an idiot.
Here’s how to pirate 9409545 fonts in a few minutes:
1. Install a BitTorrent client
2. Go to thepiratebay.org
3. Clicketyclick.
Notice something about those 3 steps? None involve CSS3, @font-face or anything else.
Automatic font downloading is going to enable a new market for font designers; that is, as long as they’re not as retarded as the MAFIAAs. And why do I think that? Ask yourself, what happens when someone pirates a picture / movie / mp3 and puts it on his website? Hm?
What is the point of EOT? How stupid is it for the browser to try to enforce basically DRM rules for no reason.
I mean we have copyrighted images, books, music, etc now that the browser can view without worrying about the license… It’s the site-owner who has to obey by the license, not the browser viewing the content.
EOT is just a headache anyway, it doesn’t prevent people from downloading the font anyway, especially if the font is there in TTF already to support other browsers!
It’s the website owner who has to know and obey the font license terms, not the visitors.
1) Font embedding is already available in a variety of technologies — word processors, PDFs, etc. Why is this different?
2) No other form of media currently has DRM built into the browsers. Images, videos, etc. all have copyright holders with interests in preventing them from being distributed over the internet, yet somehow the font people are succeeding in their quest for DRM where the RIAA and MPAA have failed? Can someone explain one difference between a font and a copyrighted image?
3) The DRM in EOT is pretty trivial to crack.
These “font foundries” need to realize that they have to approach the issue the same way other copyright holders do — make it clear when you license a font to someone whether its ok for them to embed it in documents, and if you find people infringing, issue take-down notices.
[…] Galbraith at Ajaxian recently posted again about using custom fonts. He points to a cross-browser solution by John Allsopp which serves EOT fonts and TTF fonts to both IE and non-IE browsers respectively is […]
@john
I got some information from H Wium Lie regarding Opera’s implementation of TTF/OTF linking via @font-face.
It is implemented in something they call Wingogi, which is a stripped-down build they use as a test-bed.
Available here:
http://labs.opera.com/downloads/
However, whether or not support for it will actually be in the next release he did not say. (I find that conspicuous but just my humble opinion.)
As of Opera 9.2 TTF/OTF linking is not supported.
Thanks Richard, most interesting,
john
[…] Bu aralar yazı tipi gömme işleri üzerine bayağı bir çalışma var. Bence çok gecikmiş bir özellik umarım tüm tarayıcılar anlaşırlarda iş tatlıya bağlanır. Bağlantı […]
[…] supports @font-face, Firefox is not far behind in supporting that CSS spec. @font-face raises font licensing problems, but we’ll discuss those another time. The risk that concerns us here is when a browser […]
[…] there’s been a spat of editorials regarding custom fonts for the web — with two competing proposals (Microsoft’s EOT and embedding a TrueType font directly […]
Well, I guess Mozilla’s gone and done it. The FireFox 3.1 Beta1 release suppports direct linking to ttf files.
Safari, now FF, but still not Opera, interestingly, insofar as they obviously (see previous post) have had it all worked out for some time.
When the inevitable piracy enabled by Apple and Mozilla’s decision displays, there is simply no way that Adobe, Microsoft, and the rest of the font industry can let it stand legally. Their hand is being forced.
Grab some popcorn!
Well spotted Richard. This makes things very interesting.
But, just to ask the obvious question, what makes fonts different from words, images, software, music, and all the other IP that browsers enable folks to “pirate”?
First, after a night’s sleep, let me amend my comment a bit while sidestepping your question, for now:
First, “Piracy” is a word with connotations unhelpful to the debate about what kind of Internet we want to have and I’m going to stop using it.
For now, I’m going with “unlicensed”.
Second, Apple/Safari and now, Mozilla/FireFox have put Microsoft, as a font vendor with a big investment in fonts, in a weird position.
Putting myself in their shoes, I ask what I would do if, for example, the Microsoft “C” family of fonts like Calibri, delivered with MS Office, were to start appearing on web servers all over the place.
Do you go down the legal road (because I assure you that a non-frivolous case for conributory infringement can be made) or do you just sit tight and take it on the chin?
I don’t know. We’ll see. That’s where the popcorn comes in — it’ll be like watching Court TV. Heck,keeping up with the MS-bashing blog posts alone could keep one occupied full-time.
Let me be clear: I hope a practical and fair system for embedding fonts in web pages gets worked out and worked out as soon as possible.
But beyond any IP issues, there are serious practical issues that need to be thought about and addressed. @Font-Face isn’t a panacea.
Fonts are referred to in CSS by name and there is absolutely nothing to prevent me or you or anybody else from simply cracking open any TTF file we want and renaming it “Calibri” or even “Arial” and then confusion reigns, potentially.
An extreme example, but you get my drift.
There is also the problem of poorly crafted fonts with missing characters and other defects. Caveat emptor.
Then, there is the issue of file sizes. A full and complete font set can be huge. For an Asian language, my understanding is that it can be over a megabyte.
One argument in favor of EOT files is that EOT is a compressed format.
Frankly, since Microsoft has submitted the EOT spec to the W3C and has announced that anybody can use it, no strings attached, I’m rather pissed that Safari and FF didn’t choose to support that first, because we’d then be that much closer to what we all seem to want. With Internet Explorer already on board.
I’ll pop back soon with a response to your actual question! ;)
Also, I forgot what’s probably the biggest problem of all — how to reconcile the design issues for browsers that don’t support @font-face as opposed to those that do. If @font-face isn’t available, what fonts get substituted and how? Which includes the need for some sort of sniff to see if @font-face is supported.
According to the CSS2 (and CSS3, but not CSS2.1) specs, @font-face fonts follow the same fallback scheme as any other font specified:
@font-face { font-family: "Imported Font"; src: url("http://site/fonts/imported.ttf"); } h1 { font-family: "Imported Font", Verdana, sans-serif; }So, the substitution works fine. The only real issue here is that your imported font may have a much greater character width than any of the default fonts, making the design look quite different if the browser cannot import the font.
@guy
Yes, but it’s not enough. For me, at least.
Not just a matter of the typeface looking different, if you’re also using ems to size containers it can look very, very, very different. Not a lot of designers or their clients are comfortable with that. I’m assuming a transitional period where more in the way of corrective action via script might need to be taken. If @font-face is not available you might want to roll back to some photoshop text or Flash, for instance.
Plus MS, (and I don’t expect this to change) will not be supporting direct linking to TTF/OTF files so you will most likely need a conditionally commented style tag or link along with an equivalent EOT file for IE.
(Once again, why did Webkit/Safari/Apple and FF/Mozilla choose not to support, as a first step, the file format with precedent and the support of the font-industry behind it? The file format with an implementation of ten years that’s currently available and ready to benefit at least three out of four people on the Internet? It IS those people we’re supposed to be serving, isn’t it?)
Instead of something they know damned well IE isn’t going to support and even if it did, in IE9, we’d still have to wait out the fall-off of IE6, IE7, and soon, IE8 to negligible levels.
Why even bother?
Is somebody trying to prove a point? Is this some kind of ideological thing that I don’t get?
Richard,
I can only speculate as to why Safari and Firefox implemented embedding with non EOT fonts. But here are a few ideas
1. From a technical point of view, I support for EOT would be non trivial to implement. Obviously, both browsers already support TT fonts, so implementing downloadable TT fonts would clearly be far far less work.
2. As open source projects, given the current status of the EOT specification, under the licenses under which one or both of Mozilla and Webkit are released, it may not legally be possible to have open source software that supports EOT decoding. This has certainly been the case with native support for some audio and video formats in OSS.
3. From a strategic legal POV, supporting DRM for fonts directly in the code base might be a slippery slope. Would it open the prospect that owners of other kinds of IP use support for DRM with respect to fonts to argue that browsers should now natively support DRM for all IP. Given the aggressive approach to both reactively and proactively defending their property rights (real, and sometimes imagined) of for instance the recording industry, do you want to give those folks an inch when it comes to dictating the content policies of your browser?
4. from a business strategy point of view, I imagine companies on the whole don’t typically support the efforts of their competitors to create industry standards.
Al as I said of these are speculation pure and simple.
Richard,
I guess a similar question can be asked of innovations like border-radius, text-shadow, css transitions and really any browser innovations.
Font embedding degrades gracefully, and as I demonstrated in this article, the two forms (TT and EOT) can sit side by side. So, I’d argue that as of wide spread adoption of FF 3.1 (some time in the next 3 – 6 months given FF upgrade rates), you’ll have font embedding technologies in IE (any version), Firefox, Safari (including iPhone), and potentially, Chrome (it seems the webkit version of Chrome was forked off some time ago, so there’d be work to be done) — covering just about every browser on the planet.
[…] A couple of months back, I surveyed the scene regarding a long cherished dream of web designers and developers — font linking and embedding. […]
For those following this thread, I’ve just posted some more thoughts on font linking and embedding, in light of Mozilla’s upcoming Firefox 3.1 support for @font-face linking to TrueType Fonts.
I’m not sure if this will work as I don’t have Windows, but can you use the fact that IE doesn’t support the format() specifier to reduce the code required to support both types of fonts to a single line?
@font-face
{
font-family: Shiny;
src: url(http://server.example/Shiny.eot);
src: url(http://server.example/Shiny.ttf) format(truetype);
}
h1 { font-family: Shiny, sans-serif; }
IE will parse the first line, understand it, and download the file. It will not understand the second line – it will try to download a file from “http://server.example/Shiny.ttf) format(truetype” – resulting in a 404, so the first file will get used.
Safari will parse both lines, the second will override the first, and thus be used.
If this method doesn’t work, you can always use conditional comments to provide one src to IE and a different one to other browsers. This way you don’t have to always have the same pair of font names in all your CSS.
[…] The return of font embedding to the web? | Web Directions […]
[…] font embedding becomes commonplace on sites catering to current generation browsers. There is a large collection of blog articles discussing the obvious ramifications of embedding commercially-licensed […]
Nicholas>
it’s not working
only the last one is used
even using !important
try it yourself next time
[…] about the challenges that arise when using @font-face. Font licensing is one (that many others have written about) and the file-size of included font-files is another, but this article is about browser […]