is now an archive and is no longer updated, you can find new writings at →

07 15 2009

You may have seen the link flying around Twitter this afternoon, but a proposal from Tal Leming and Erik van Blokland to the W3C looks like the proper call to action for type to move forward on the web. It’s already received support from Hoefler & Frere-Jones, and I’m sure more will follow. Unfortunately it’s only a proposal at the moment, but a show of support from the design community would surely help it along.

Put simply, it’s a request for a new font-file format, specifically for the web: .webfont. This format would allow typefaces to be assigned to a domain to prevent abuse, and would allow us to use the browser native @font-face functionality as intended. No workarounds, no middlemen, no bullshit.

They’ve got my support.

For the sake of brevity, I’ve copied the highlights of the proposal here (ignoring the sections aimed at browser manufacturer’s and type foundries). You could also view the full proposal if you so desire.

The revised format [.webfont] is now a compressed file containing
two files with the following names:

— info.xml
— fontdata

The info.xml file contains numerous bits of data describing the font

The fontdata file would contain the actual font file. The name does
not have an extension so that it can be format agnostic.

[…] these files would be compressed into a single file.

The proposal goes on to list various elements for the .xml file but the important bit is this:

allow - A list of URLs allowed to use the font. Optional.

In our previous proposal we suggested an unobtrusive alert system that
would be triggered if the domain being viewed did not match a domain
in the element. John Daggett explained that he didn’t think
this would work. Instead, he suggested a “page info” window that
would display data about the page including information defined in the
font’s metadata plus same-site origin restrictions. We are very
interested in hearing from the browser developers about the
feasibility of these two ideas.

We’re hopeful that this is a good format for everyone. It gives users
smaller file sizes. It gives the font vendors a simple format that
allows them to include information about the font. It doesn’t require
entirely new technologies from the browser developers.

What do you think?



  1. It’s got my vote.

    I’m glad to see H&FJ are on board this early, especially considering the imminent release of Typekit. It’s apparent (now that they’ve given their public support to .webfont) H&FJ is not going to release any of their typefaces via Typekit. Honestly, when I can legally and easily use H&FJ fonts on the web, I’ll be a happy person.

  2. So there’s no DRM or any kind of way to prevent altering the XML file? I thought that’s what the font companies required, and that’s why this whole issue was taking so long to resolve.

  3. At first glance, I’m not sure how this is different than .eot’s compression + optional domain-specification, with the same drawbacks - it needs adoption. TTF & OTF (and EOT) exist today. We definitely need fonts designed for web use (@font-face is part of that) - but I think that’s do-able with our existing formats.

  4. @ivrsn: The .xml file would be compressed into the .webfont file, so I doubt it would be easily editable, making the font-file only usable to its owner (no hotlinking).

    @Garrick Van Buren: It appears that existing typefaces need only be compressed in to the .webfont file, but you are right that browser’s would need to make some slight modifications to handle it.

  5. Just recently I wrote an article on Russian about embedding fonts with EOT and current browsers support of @font-face.

    I am more then positive, that developers and open-source community should take advantage of EOT.

    Kyle, as you wrote “No workarounds, no middlemen, no bullshit.”; and as it is stated in proposal: “It doesn’t require
    entirely new technologies from the browser developers”.

    I disagree. Look at the EOT.

    1. It is already closed-for-desktop format.

    2. It is already supported by browser with greatest market share.

    2. It does great job with compression (even much better then RAR, ZIP or GZIP)

    3. It covers DRM that pleases font foundries.

    4. EOT offers great subsetting options. CSS3 unicode-range spec probably doesn’t even know that EOT exists. This part of specification presumes, that there will be separate versions of fonts for Latin, Cyrillic, Math and so on… How uncomfortable is that? With EOT you need only one font. You can even subset based on characters used on one page…

    5. Adobe, Monotype and many others support it.

    6. It is already open-sourced!

    W3C should get the Font WG finally going and start updating and working on EOT to get the fonts to the web faster. Only then, if developers will feel like it, they can embed web table to TTF, OTF, create TTW or .webfont. Whatever. Internet market will decide what is the best.

  6. @Kyle Meyer’s “The .xml file would be compressed into the .webfont file, so I doubt it would be easily editable, making the font-file only usable to its owner (no hotlinking).”

    Not to sound rude, Kyle, but this is very naive. How long do you think it would be before someone took the spec and produced a simple application that would allow you to edit the domain information in the .webfont file on the fly? I’d put good money on a wager that such an application would be written before anyone even produced any .webfont files. As soon as the namespace and compression format are given, you’ll have people working on automation tools to easily produce and edit .webfont files. And there isn’t even anything dodgy about that. Those would be useful for all kinds of legitimate uses.

    I’m all for solutions to get more foundries on board with @font-face. I’m just not sure how .webfont actually solves any of the potential copyright issues that have these foundries gnawing their fingers off. Frankly, I doubt there will ever be such a solution—like all other kinds of publishers (news, music, etc), foundries are just going to have to adapt to the fact that life on the internet does not conform to the same set of rules as life in the real world. In the real world, when you sell someone a font and they use it in their magazine, other people can’t lift it and reproduce it with a minimum of hassle. In the tubes, they can. That’s just the nature of the medium. Either foundries need to get over it and find a way to work with the technology, instead of trying to force it into a “real world” (read: out-dated) rules model…or they’re going to gradually fade away. Much like other companies which didn’t manage to adapt to a new paradigm. Companies like horse-shoe manufacturers. I’m sure if foundries were able to adapt when metal stamps stopped becoming the norm for delivering font faces, they’ll be able to adapt to the internet. They just need a kick in the butt. Maybe the growing number of quality, open source fonts out there will suffice to that end. Maybe not. I’m not too worried. There are plenty of good alternatives that can be used with @font-face right now, without commercial offerings.

  7. This does sound like a good solution.

    @D Bnonn Tennant
    You’re right, tools will appear to change the meta data. But as you say later on: “foundries are just going to have to adapt to … life on the internet”. And this is what webfont is!

    People who want to use the anti-webfont tools are already downloading hundreds on fonts in torrents. This won’t change. But this is a hurdle for the casual downloader who doesn’t understand the legality of saving a copyrighted image/font from the internet. And if that’s enough for the foundries, then this is the best solution; no workarounds, no middlemen, no bullshit.

  8. I’m pretty sure it’ll get cracked in not time at all, but I can’t actually think of a viable solution myself.

  9. This sounds like a possible solution. I’m always happy to see any progression on @font-face. Does this mean that a font will have to be re-licensed/re-purchased for each domain its used on?

  10. It’s an intriguing proposal, that at first glance seems easily reverse-engineer-able: all I’d need to do is grab the .webfont file, extract it and edit the URLs within the info.xml property. Next re-compress it back up and upload it to wherever I’ve specified.

    Before really putting my shoulder behind any single solution I’m going to wait to see what the folks behind Typekit come up with.

  11. When it comes to getting around the DRM, that’s a given. No solution is bullet proof, but as Stuart said above, those people weren’t likely to purchase the typeface to begin with. So it’s no loss to the foundry at the end of the day. It’s still enough of a hurdle to keep their paying customers paying, and secure them a new market of paying customers with interactive designers.

  12. Just a note to say thanks for your support, Kyle.

    Joey, for what it’s worth, nothing in .webfont is incompatible with Typekit, which is why you’ll see that they’ve just come out in favor of it as well. I’m glad to have their support as well.

    Kindest Regards,


  13. As Ryan Roberts says: it’ll will cracked in no time.

  14. Awkward to find myself touting a Microsoft technology, but I’m with Nikita on this one.

    What you’re describing is done better by .EOT. EOT encrypts the font, and cannot have the original font files reverse-engineered out of it. It uses OpenType, as opposed to TrueType. These two aspects put it so far ahead of other browsers’ implementations of @font-face in such desirable ways, it’s really surprising how much the design community can stand to not check it out for what it is, and spin out a million hairbrained shoddy alternatives in the meantime.

    Currently it is difficult to implement — you’ll need to convert any TTF fonts you want to use to OT with specialist software, and the encrypting application is Windows-only — and of course IE=<7 is the only practical supporter.

    But when people say they’ll @font-face to refer to their ttfs first and then write back-up code for their IE eots, their IE ‘alternative’ is much more secure and far more flexible.

  15. I don’t get either why there isn’t more talk about the EOT’s. Quite strange - it has been around forever and it actually was MS that did it!

    It was back in the days when the IE dev-team though the web should be as interactive as possible and began developing the tools for it. When “interaction” was THE buzz-word to use (1997-1999?…) They actually was ahead of their time with image filtering and crazy stuff like that. It’s quite funny when one thinks of it… :)

  16. @Tommie: I think you actually stated one of the bigger reasons why nobody talks about EOT: It was Microsoft that made it. People are pretty wary of any kind of solution that comes from Microsoft, as they have a history of being huge jerks.

    On top of that, even if they *have* come up with something good in EOT, it’s still encumbered by the fact that you have to convert everything to OT (one hurdle that .webfont gets to ignore, as it is form-agnostic), and THEN you also have to convert that OT font to EOT, which you can only do on one platform, a platform that ISN’T used by most designers (and, likely, type foundries), with one tool (last I checked, at least).

    EOT really heavily restricts the people who actually want to use it, which is NOT a good idea.

  17. @Ian:
    You’re quite right in saying that EOT takes more effort to implement, but it is practically achievable - and doesn’t involve such a crippling paradigm shift for foundries as simply having your fonts given away in whole whenever they are used, while still providing real text without technology dependencies that can be selected, copied, etc…

  18. Several of the participants here should be interested in this — instruction of how to easily convert TTF to OET using open-source tools: