Oh my gosh! Yet a another font format for the web? EOT for Internet Explorer. TTF/OTF for Safari & Opera. WOFF for Firefox 3.6 and now SVG fonts for Mobile Safari? Unfortunately, yes!

But what are SVG fonts anyway? Is this a good webfont format? Actually, it is not a webfont format at all. The purpose of SVG fonts is to be embedded inside of SVG documents (or linked to them), similar to the way you would embed standard TrueType or OpenType fonts in a PDF.

SVG fonts are text files that contain the glyph outlines represented as standard SVG elements and attributes, as if they were single vector objects in the SVG image. But this is also one of the biggest disadvantages of SVG fonts. While EOT, WOFF and PostScript-flavoured OpenType have compression built into the font format, SVG fonts are always uncompressed and usually pretty large. For example, our Graublau Sans Web fonts have just 61 KB as OpenType PS, but 172 KB converted to SVG.

This is how a SVG font (reduced to 2 glyphs) looks like

But there is more bad news: Since SVG fonts are just a collection of vector shapes, there is no way to store hinting information. Font foundries such as FSI have put a lot of effort into optimizing their Web FontFonts for small sizes on screen using elaborate TrueType hinting. But when you convert such a font to SVG all these information will be lost.

So, SVG fonts are not really an alternative to the other webfont formats. In 2008 Apple fueled the webfont revolution with the release of Safari 3.1 with support for webfonts in TrueType or OpenType format. It’s understandable that this support was deactivated in Mobile Safari for the iPhone. The screen is very small and the use of downloadable fonts hardly justifies the loading times and traffic costs of the webfonts. But this is now changing with the iPad. The resolution of the iPad in landscape mode is equal to the standard minimum resolution used for almost all websites today. The internet on the iPad is not a light version for mobile devices. So there shouln’t be any limitations either. Steve Jobs said in his iPad keynote:

»Those devices need to be far better than a laptop or the iPhone at some key task—things like browsing the web.«

But without support for real webfonts format such as WOFF and EOT, browsing the web with Mobile Safari is not really better. So I am really hoping that Apple will include true webfont formats in Mobile Safari—preferably WOFF which is also missing in Safari but has a good chance of becoming the webfont format in the near future.

The site about webfonts, but by default, no true webfonts supported on the iPad

If you want to use webfonts on the iPad today, you need to provide SVG fonts. To convert your fonts to SVG you can use applications such as FontForge or the @font-face generator from Font Squirrel. With the webfont services from Typekit and Typotheque you also get (experimental) SVG fonts support.

The Typekit homepage with experimental SVG fonts support

Linking SVG fonts in your website is similar to using any other webfont format. You just add another line to the @font-face rule in your CSS:

Note that the file name is followed by a hash tag. This relates to the font ID, which you will have to set while converting the font to SVG. The reason for this is, that multiple fonts can be embedded in a SVG document and therefore an identifier is required.

Tweet This Share on Facebook

Web FontFonts come as a download package with an EOT and a WOFF file. The official announcements states that this will cover “more than 90% of all web visitors”, but unfortunately at the moment this is marketing talk. WOFF is currently only available in the latest release of Firefox. If someone uses an older version or Safari or Opera, Web FontFonts won’t show up. I just contacted the major browser makers asking for their plans concerning WOFF, but no one is currently working on an implementation of this format. So we probably need to wait some time until this concept of WOFF and EOT (as an Internet Explorer fallback) will really take off. Nethertheless, WOFF has a very good chance of becoming the webfont format, so I really appreciate that FSI is taking the lead in supporting it.

The fonts are licensed based on the estimate number of page-views per month for the website. There are three levels: up to 500,000; up to 5 million; and up to 50 million. To me this sounds like a very reasonably deal.

A detailed user guide describes how you can link the fonts on your website. It is also important to mention that FSI’s webfonts are carefully optimized for screen. A regular desktop font converted to WOFF or EOT will very likely look terrible in smaller sizes on Windows. Only optimized screen fonts promise a good legibility across all platforms and in all sizes. The Web FontFonts certainly fulfill this promise. You can check it out by looking at the browser samples provided by Typekit.

The Web FontFonts are available for licensing here: http://www.fontshop.com/fontlist/n/web_fontfonts/

Tweet This Share on Facebook

Tweet This Share on Facebook

http://www.fontspring.com

Tweet This Share on Facebook

Tweet This Share on Facebook

As a type and web designer, webfonts were always of great interest to me. As a type designer I was shocked, when Safari started to support linking TrueType and OpenType fonts (now usually called “raw fonts” in this context) with Safari 3.1 in march 2008. Web designers could now upload my commercial fonts to a public web server where everyone could easily download them. One year later almost all type foundries seem to remain in this shock.

But since I am also a web designer I began to see it from a web designer’s perspective. I thought about ways to improve the protection of raw fonts and also about new ways of licensing, for example web services that would host the fonts and deliver them whenever your website is being viewed. Apparently I wasn’t alone with such thoughs. Currently several webfont services are being developed. Meanwhile the percentage of users who can actually see webfonts keeps growing. Firefox 3.5 has implemented the possibility to link to raw fonts and so will Opera with version 10. So all major browsers support webfonts now! But there is also catch: There is currently no single webfont format, that all browsers and type foundries can agree on. To understand the current dilemma we need to look at the history of webfonts and the CSS “@font-face rule” that makes webfonts possible.

Webfonts history

Webfonts are font files embedded in websites using the @font-face rule. This technique was first available around 1997 in Netscape Navigator 4 using Bitstream’s TrueDoc standard and in Internet Explorer 4 using Microsoft’s Embedded OpenType format (.EOT). But both formats were hardly used, mostly because the render quality was rather poor these days and only well-hinted system fonts looked good on websites.
Today the render quality in all operating systems and browsers has improved dramatically and webfonts get a second chance. But while Microsoft sticks to its EOT format since version 4 of Internet Explorer, the developers of Safari, Firefox and Opera went a different route and implemented @font-face in a way where only raw fonts (TrueType/OpenType) work. So if web designers want to use webfonts they need to include both EOT and TTF/OTF to make it work across all major browsers.

Raw fonts and the intellectual property

For web designers using both EOT and TTF/OTF may not be perfect, but its not too hard either. The problem is that almost all type foundries don’t allow the use of their commercial fonts as “raw fonts” on a web server. They are afraid…

• that there customers might upload their print fonts to a web server without a proper web license.
• that anyone can download those raw fonts from the browser and install the fonts on the local system, without having paid for it at all.

So the foundries are hoping for a new solution, a new web-only font format. But it’s somehow ironic that at the very moment, when webfonts become finally useable across all major browsers, the foundries are trying to invent a new format that will currently not work in any browser at all and will take probably 6 to 8 years until it reaches the same level of support that EOT and TTF/OTF have today. Or as someone on a German blog put it: “The type foundries are standing on the platform arguing about the seating arrangements while the train has already left the station.”

.webfont format

One such new webfont format proposal is .webfont by Tal Leming and Erik van Blokland. It’s a zipped file that includes the font data and an XML file with meta data, such as permissions on which website the font can be used. Many foundries support this proposal, but it will certainly take years until it is included in all major browsers.

OTW and EOT Lite

The foundry Ascender proposed a new web format called OpenType Web (OTW). It is based on regular TrueType/OpenType fonts with some additional information and some changes in the format, which make it impossible to install this font on a local machine.
But Ascender realized that it may take too long to implement such a format in all major browsers, especially in Internet Explorer. That’s why they created a new proposal called EOT Lite, which is based on Microsoft’s EOT format but without the compression and the URL-binding, because these were features the developers of Opera/Firefox and Safari rejected. EOT Lite already works in Internet Explorer and would only needed to be included in the other major browsers. But then again: URL-binding and compression are the main reason for the existence of the the EOT format. Removing these features from a webfont creates a bad compromise. “And so, as I see it, an EOT Lite file is nothing more than a TTF file with a different file extension.” Quote from Richard Fink

The status quo

So there we have it: Webfonts are now supported in all major browsers, but most foundries don’t agree to the use of their fonts as raw fonts on web servers, so the web designers can’t use them. New formats are proposed, but they will take years to be included in all browsers. So what do we do? Use only freeware and open source fonts?

Webfont services

I think these first examples of commercial webfonts show very clearly how commercial webfonts can enrich websites.

Professional web designers want professional typeface for their work and corporate clients want to use their corportate typeface on their websites – and there is a solution that works today: Webfont services like Typekit, Fontdeck and Kernest. As I said in the beginning of this article, it’s the solution from the web designer’s perspective. An external service that you embed in your website like a route plan from Google Maps. You don’t need to worry about different font formats, browsers version, compression and subsetting – the webfont service will automatically deliver the right CSS and the right font file to the visitors of your website. And these webfont services can even include some level of protection, so the font foundries might agree to the use of raw fonts with these services.

Using a webfont service is certainly a very different way to license a font and many are being sceptical about this concept. Here are some common concerns:

What if the service fails and the fonts are missing?

Don’t worry, the developers of those webfont services are well aware of this issue and will host the files on Content Distribution Network (CDN) that can guarantee the constant delivery of the fonts all over the world.

But I don’t want external services, I want all files on my server!

Yes there was a time when a website was nothing more than a folder with lots of files in it. You could stick it on a CD-ROM or upload it to webserver, it would always work. But today there is hardly any website left, that doesn’t use a permanent database connection or external services like Google Analytics. Today a website must work on a device that is online and therefore external services are a commonly accepted tool.

Don’t forget that webfonts are a piece of software that needs maintanance. Your page might get a new domain and you need to update the URL-binding in the fonts. You site might be translated to Russian and you need to change the subsetting to reflect that. A new browser version might handle some @font-face descriptors or OpenType features differently and the fonts need to be updated …

And that’s where you can rely on a webfont service that will handle this automatically and generate all the necessary files on the fly.

So now I have to pay forever to use a font instead of just once?

Yes and no. Sure, you now just rent an access to a certain font file. But that has also some big advantages for the users. Traditionally fonts are licensed for a flat fee and only after your payment do you get a chance to to use the fonts. So you are forced to buy a pig in a poke. It may not work for you or your client might reject the font. So even if you never use it, you have paid the full price.

But with webfont services it would be really easy to offer a trial period. You could play with several fonts, present them to you client and when the trial period is over you could decide whether you stop using the font or whether you start paying the monthly fee. And if you, let’s say after 6 months, don’t like the font anymore, you could switch to another one or just cancel the subscription and you have probably paid much less that you would with traditional font license.

Interviews

I asked Jeffrey Veen from Typekit and Veronika Burian from Type Together about their opinion on webfont services. Here are their answers …

RH: Web designers often say they want full control over the fonts and don’t like external services. What do you think are the most important advantages of using webfonts as a service?

»I think the tide is changing a bit. I see many sites linking to third-party Javascript frameworks like jQuery, or using Amazon S3 for image hosting.
There are really two things to consider: reliability and performance. Typekit is hosting fonts on a global content delivery network with redundant servers in North America, Europe and Asia. Most organizations can’t afford to host with providers like this, so the reality is that Typekit fonts will be served more reliably and with lower latency than most of our customers’ sites.

The second thing to consider is how browsers request content from servers. Many people assume that adding third-party servers will slow them down, but the reality is it actually helps quite a bit. Browsers have limits on how many simultaneous requests they will make to individual servers. By hosting parts of your site on different domains, the browser will open more connections and load things like fonts and stylesheets much faster than if they were hosted on the same server.«

RH: Type foundries are used to license their fonts to commercial design studios and other corporate clients. Webfonts might reach a much wider audience – do you agree? Which customers do you want to address with Typekit?

»We’ve identified a number of audience segments that could benefit from webfonts, and Typekit will have multiple ways of addressing them. Working designers who maintain brand identities only scratches the surface of what’s happening on the web today. Social media has blurred the distinction between publisher and consumer. There are an estimated 184 million blogs in the world today, all of them building a unique voice and identity. Some of us may see the vast unwashed masses on MySpace as a design disaster, but it also represents a first step towards people expressing their online identity visually. Webfonts will accelerate all of that.«

RH: What’s your opinion on the debate about webfont security and the ongoing discussion about better webfonts formats?

»We’ve written about this on the Typekit blog, both in our support for Tal Lemming’s and Erik van Blokland’s .webfont proposal, as well as our in-depth explanation of how we’re serving and protecting fonts.

I see a couple issues here. First, the type industry is fortunate to be able to learn from recent history. Media companies have struggled for a decade with the balance of protecting their assets while enabling as big an audience as possible. They’ve tried different DRM schemes, which have pretty much all failed. They’ve tried strong-arm legal tactics and learned that suing their best customers is a short-term solution at best. There’s a lot of precedent there, and I think we can skip over a lot of earlier mistakes.

But I also believe there are unique qualities to fonts that make the analogy to music, photos, and video a bit weaker. Unlike, say, stock photography, fonts are pieces of software used to create visual communication. Not only that, but the same software used to create a work is needed to view the work. So type designers are having their entire source code sent to every person who views a web page. That’s the reason why so many of the foundries are being cautious and proposing new formats. There are parts of this new world that have no precedent and we all want to make sure we think about this very carefully.«

RH: Webfonts are uncharted waters for type foundries. Why do you decided so early to team up with a webfont service to bring some of your fonts to the web?

»We think it’s a great idea to bring finally good typography to the web. We understand, that web designers have been long keen on having access to a broader range of typefaces. Various workarounds exist, but never took off on a big scale. So, when TypeKit asked us to participate in their new scheme, we thought that it is a very promising business model that is fair to both parties, the web and type designers. It has the potential of promoting good typography in a legally safe environment and at the same time bring some revenue to the type designers, who spent long hours designing good fonts. It might also push type developers to add extra value to their fonts for the web, by preparing them for on-screen viewing, i.e. hint them properly.«

RH: What are your expectations for this new market, its growth and customers? Are your customers requesting webfont licensing?

»Yes, we have been asked a few times about our policy on licensing for the web. At the moment, we allow for font embedding, but not font-linking, except via TypeKit. We think, it’s a growing market with a lot of potential. The demand for fonts on the web seems very high. However, it’s also a competing market and the players (browsers, foundries, W3C) are not unified enough and don’t have a common opinion or interest in the same issues. I fear this slows down the process.«

RH: What is your opinion about the whole issue of webfont security? Are you satisfied with the way your fonts are obfuscated through the Typekit service?

»It’s impossible to completely avoid font piracy. Our fonts have been hacked and are already available illegally on various sites. Personally, I am not so bothered unless the fonts are redistributed and/or used for a clients project with monetary gain. As far as I can tell, that hasn’t happened yet. TypeKit is using several techniques to make it harder for users to gain access to actually working fonts. Although it’s possible to download the font files from the source code of the website using the fonts, it takes some effort and technical font knowledge to make them into fully working fonts again that can also be printed. I seriously doubt that any decent designer would use them for a client project and risk legal prosecution. So overall, I believe TypeKit is doing a good job in regards to webfont security.«

Conclusion

If webfont services manage to find a pricing scheme that works for the users and the foundries I predict them to be extremely successful in the next couple of years and webfonts can be a huge an unprecedented market for the font foundries. A new webfont format like .webfont might emerge over the next years and can then be available for conventional licensing (i.e. without renting). Webfont services can easily include such a new format, but it will take a very long time until it can make the current use of EOT and TTF/OTF superfluous.

Related links:

• Webfonts.info
• Webfonts.info RSS-Feed
• Follow me on Twitter

Tweet This Share on Facebook

Tweet This Share on Facebook

Tweet This Share on Facebook

Tweet This Share on Facebook

Now more and more commercial font foundries have overcome their shock and have announced to support @font-face embedding for their fonts. Most notably, David Berlow of the Font Bureau has just announced that their fonts will soon be available for @font-face embedding. Font Bureau introduces a new permission table included in the fonts, but this table is currently not technically enforced in any way, so there are no limitations like the URL-binding feature of the EOT format. 

I am keeping track of foundries supporting @font-face embedding on this Webfonts.info Wiki page.

Tweet This Share on Facebook