Lately some “bullet-proof” cross-browser methods have arisen using @font-face:
- http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/
- http://readableweb.com/mo-bulletproofer-font-face-css-syntax/
While these provide a functional way of embedding fonts I contest they are still not “bullet-proof” since there are serious legal implications if these methods are misused. The big problem is that I can’t just take any font, toss it on a directory on my site and link to it. It would be like posting a picture of Mickey Mouse on my homepage without obtaining the proper rights.
Some “font-linking” services have started to pop up that will host the fonts for you and give you access to use them on your site for a reasonable fee. This adds viability to @font-face because you don’t have to worry so much about the EULAs. For example:
But these systems are less than ideal. Most of these services have you link to assets on their site so that they can calculate fees and manage rights. This bothers me for a few reasons.
The web is open. I understand the intellectual property issues, but all the legal ambiguity is against the spirit of open-standards. I feel if a company like Adobe can clearly state “any font in our folio can be used with @font-face if you do X” then the issue would be settled. Perhaps “X” might be to just prevent hot-linking to the file, or embed it a certain way. A move like that would take us from 9 web-safe fonts to 2309 web-enabled fonts. And they don’t need to give the fonts away either, but there needs to be a clear legally binding statement as to what modern methods you can use to embed fonts (like Cufon too). There are other services out there like fontsquirrel.com which are a step in the right direction, but it’s still legally dangerous. What if I rip off a font, come up with a fancy fake foundry name, and then post it on their site? If a client gets sued by the real creator there’s no accountability.
Security/Control. I work in a client-based industry, and a lot of them are uncomfortable with linking to assets on 3rd party sites (usually this debate comes up with tracking). What if a disgruntled employee puts body {display: none} in the font CSS file that is linking to an e-commerce client? Or even worse, a CSS expression that steals cookies? This may be a long shot, but still when you’re running a high-profile e-commerce site you tend to not quickly trust an up-start. ANY downtime means losing a lot of money, and why take the risk for a font?
Consistency. Font linking services are popping up left and right. They all have different sets of fonts. That makes it a huge pain if you’re using a font and need to find which service can provide it. There’s no register.com-esque service that pulls it all together so you can easily search. With projects on tight deadlines, finding the right font could be a nightmare.
Support. You can’t use .ttf fonts on the iPhone or iPad (based on working with a simulator). This means you must use an SVG font. For example, typekit doesn’t support this format, so if you want to use it in your project then you’re in trouble. See this article: http://getsatisfaction.com/typekit/topics/typekit_support_for_the_iphone
I want sIFR to die as much as the next person but I’m still too apprehensive to use @font-face embedding in my projects. Without being able to present a simple, open, self-hosted path on how to include custom fonts on a site, I can’t see clients signing-off. People are willing to pay to eliminate the ambiguity. As I said before, I think if Adobe shows people who have licensed the use of their fonts a clear way to use the fonts on the web it would be a big win. Many professional designers already use Adobe’s font-folio so I feel like it would be a good end-to-end solution. We’re on the cusp of having cross-browser web-based typographic support, but I’m afraid if we’re not careful there will be too much red tape and it will be generally unusable. What are your thoughts/experiences?
Tags: @font-face, css, typography
Rob,
I think you’re making too big a deal out of the legal stuff. Go to Font Squirrel (free) or FontSpring (one-time payment to own and use) and check out the selection. Also, Kernest’s fonts (free) are also available as downloadable, DIY packages.
“all the legal ambiguity is against the spirit of open-standards”. I very much agree.
See: Typekit And Copyright Fraud, Say It Ain’t So
I know a lot of type designers and I want them to make money but the truth is, Typekit is DRM and if I’m going to complain about the big guys using DRM, I’ve got to hold the little guys to account also as distasteful as it may be.
And you’re right – buying a suitable good-looking screen font available for @font-face is a bit of a headache right now.
Stay tuned at Readable Web. Things will get easier and much, much clearer in the near future.
I found your post very, very typical of how most web developers and designers feel at the moment.
See: An Open Letter To Retail Font Vendors.
I’ll be quoting you. I think your feelings are typical.
Comment by Richard Fink — March 24, 2010 @ 4:01 pm
@Richard – Hi! I work for a digital advertising agency. We do high-profile launches and our clients are prime targets for lawsuits. So what may seem like over-reacting is actually just concern since there’s a lot at stake.
Services like Font Squirrel can be ok, but even that has limitations. Some EULA’s on their site require you add a link to your site, others are just vague and don’t allow web embedding. I found a great font on there that was clearly free, but it was only Basic Latin characters which means I can’t use it for internationalized content.
I wanted to use typekit for an iPad site, but they don’t support SVG fonts, which is all iPad will accept. However typekit did say in a service ticket that they may add support soon, but that’s not enough time if you want to implement a site in time for the iPad release.
It’s getting there, but the free services are incomplete, and the pay services still need to build credibility, and be more flexible.
Comment by Rob — March 24, 2010 @ 8:16 pm
Rob – I hear your concerns and Richard is correct – the vast majority of fonts within Kernest are available for download. Yes, some of the licenses aren’t as clear as they could be, that’s why created the ‘web native’ tag in Kernest – http://kernest.com/styles/web-native .
‘Web Native’ means, among other things, the font is licensed under OFL or MIT license. More on what ‘web native’ means to me here – http://garrickvanburen.com/archive/web-fonts-identifying-a-new-species.
Comment by Garrick Van Buren — April 7, 2010 @ 8:11 am
Rob,
The question of legal exposure is one that has yet to be dealt with openly and certainly not definitively.
The following are just observations:
The type producers – including Microsoft and Adobe – have no interest in seeing the issues clarified because FUD – Fear, Uncertainty, and Doubt – are their most potent way of keeping users walking on eggshells and paying for licenses from sources they think are authoritative and safe.
Your client’s potential liability is a multi-layered issue. First, there is the private legistation of the EULA. If you’ve agreed to a EULA, abide by it. And if there is no EULA that has been agreed to (just because a EULA exists and is published somewhere, doesn’t mean you have agreed to it) and then there is copyright. Typefaces are not copyrightable and the law regarding “fonts as software” is vague in that the courts recognize that all software designed for the same purpose tends toward similarity. The law is not well-settled by any means. (My opinion but that of others, as well.)
DMCA also plays a key role.
Many of these things MUST be brought to light.
For now, certainly don’t agree to any EULA provisions you can’t abide by and still sleep nights.
The idea of having to hire an expensive IP attorney to analyze under what conditions you can use a font, is bizarre, but it’s the same case with any EULA for any software.
It’s a disturbing situation – and I believe it will hurt, not help type producers if it isn’t resolved.
Comment by Richard Fink — April 7, 2010 @ 9:03 am
@Garrick – I’ll definitely point out the web native fonts to the designers I work with. Thanks for clarifying, and reducing what @Richard pointed out as FUD.
Comment by Rob — April 7, 2010 @ 8:43 pm