Web Fonts Now, for real

David Berlow of The Font Bureau has proposed a Permissions Table for OpenType that can be implemented immediately to turn raw fonts into web fonts without any wrappers or other nonsense. If adopted, it will enable type designers to license their work for web use, and web designers to create pages that use real fonts via the CSS @font-face standard.

My April 21, 2009 A List Apart interview with Berlow explains how a permissions table would enable type designers to support @font-face without DRM or intermediary hosted licensing. A press release provides more detail:

Future web users will not want their browsers clogging the workings of their Operating Systems with fonts, or the browsers’ presenting the users with web content that the user cannot read. In addition, web users do not want imprecisely or un-aesthetically presented content where a simple type-bearing graphic would suffice. Lastly, users do not want fonts to be able to give fraudulent users the unique corporate appearance of a genuine company.

So far, the browsers allowing use of the @Font-face font linking are installing and removing fonts in an invisible way, but future browsers may need to more intelligently manage web fonts for users as more sites employ them. Here, the proposed table can help by containing the links from which the fonts came, and determining their cacheability based on the user’s browsing history. More importantly, the recommendations section of the proposed table could allow a browser to offer reconcileablilty of any font treatment in conflict with a user’s ‘preferenced’ desires in areas such as sizing of type, presentation of line length and potentially dangerous type treatments such as rapid text blinking.

The Permissions Table proposal will be announced tomorrow on newsgroups and forums frequented by type designers.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009

[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb[/tags]

49 thoughts on “Web Fonts Now, for real”

  1. Not before time.

    The key aspect of this working will be the lack of intermediary hosted licensing (which, unless I’m mistaken, is one of the aspects of Typekit that causes concern). As a designer working with legally purchased fonts, I’d be more than happy to scale up a license and pay a little more for the ability to use the fonts I use in print on the web. However, I’d prefer not to have to rely on a third party to host licenses, etc.

    Long may the progress that’s being made on this issue just now continue; it’s great to see web fonts finally appear to be reaching the tipping point.

  2. What exactly is to be implemented here? What do browsers/viewers/tools do with all this info? If this is informative-only, well fine, but this appears to be a DRM-lover’s wet dream.

    John Daggett
    Mozilla

    P.S. Nice to see that blinking is making a comeback!

  3. This is all well and good, but this particular barn door should have been bolted years ago—the horse is long since gone. Foundries dragged their collective feet at a critical junction & have left themselves commercially vulnerable as a result.

    @font-face has been around for years—well before CSS3; and only now someone from a font bureau (well, the Font Bureau) puts forward a realistic proposal, now, at a time when Safari, Firefox & Opera (10) all support @font-face. Foundries should have initiated this conversation years ago, when @font-face first made its appearance in the CSS spec.

    I don’t mean to put down foundries: their work is critical & I deeply appreciate what they do. I wish I had something more positive to add to this, but their inaction has put them in a dangerous place. It reminds me entirely too much of the behaviour of the music, film & even the newspaper industries. Like them, foundries are going to find that their business models are changing drastically, but that they may have forfeited directing that change.

  4. This seems sort of like attaching a file to a movie that says DO NOT STEAL and expecting it to work.

    There will always be people who steal. Nothing will stop them. This proposal is not for or about them. Professional designers creating websites for businesses, non-profits, or their own purposes (blog, zine, app) will use fonts licensed for that purpose, just as we use stock or commissioned photography and illustration.

    Legitimate designers don’t steal photos or illustrations because there’s too much at stake. A client sued for unwitting copyright infringement, who turns around and sues us, is the last thing any designer needs—not to mention that we wouldn’t want to put a client, illustrator, photographer, or any other human being through a copyright infringement ordeal. It’s the same with typography. I want to use great fonts, but not at the cost of violating my license agreement or putting a client at risk (or becoming known as the designer who compelled a type house to sue).

    Presently my options for using real type include setting type in Photoshop and using CSS image replacement to swap it (or using an IMG with alt text); Cufón or SIFR (which type shops aren’t crazy about, and which can be cumbersome to implement); or third-party solutions like Jeff Veen’s Typekit, a new web service offering a web-only font linking license on a hosted platform (which, when it opens, may be the perfect solution until the type foundries agree to a standard).

    What I’d like to do instead is use the simple CSS @font-face standard (with JavaScript to make it work in IE). But I can’t do it under the present font licensing scheme. Berlow is proposing a mechanical addition to fonts, which any font maker can easily implement, that will indicate if a font is licensed for web use.

    How does this tally with the .webfont format proposed by Tal Leming & Erik van Blokland? A lot of foundries (Porchez, FontShop, Emigre, et al) have already backed this proposal, but isn’t it in opposition to David Berlow’s?

    It is another proposal (and, it seems to me, a simpler one) for the type design community to consider. The type design community will decide—hopefully with encouragement and thoughtful feedback from the web design community.

    If Font Bureau were to adopt its own proposal tomorrow, I’d buy me a web-licensed version of Franklin and rework the headers on zeldman.com tomorrow night.

    this appears to be a DRM-lover’s wet dream.

    It’s not DRM. It’s a component of a font that says the font is licensed for web use.

  5. Thanks for answering most of the posts, JZ.

    I wish I had something more positive to add to this, but their inaction has put them in a dangerous place.

    This is interesting. No two browsers agreed on which @font-face font format until this year, and not a single web developer has shown any of us “inactives”, code within the w3c recommendation that will query the UA and download the proper font format to each user.

    It reminds me entirely too much of the behaviour of the music, film & even the newspaper industries…

    That’s probably because, like us, none of them want to step into a the non-profit business mode the browser makers seem to want everybody to embrace, don’tcha think?

    Unlike us, however, none of those industries mentioned, are trying to get a 21st century meta-data file like this one added to their formats to make it easier for users to make music, to make films, or to make newspapers with the assistance of meta-data to guide them.

    Cheers!

  6. @dberlow,

    No two browsers agreed on which @font-face font format until this year, and not a single web developer has shown any of us “inactives”, code within the w3c recommendation that will query the UA and download the proper font format to each user.

    That’s absolutely true—the specific font format & its method of implementation have been up in the air. But surely you don’t mean to suggest that you couldn’t see this coming?

    It reminds me entirely too much of the behaviour of the music, film & even the newspaper industries…

    That’s probably because, like us, none of them want to step into a the non-profit business mode the browser makers seem to want everybody to embrace, don’tcha think?

    Well, other than the swipe at browser vendors, I agree completely! My point above was that ruminating over what to do for 10+ years isn’t a recipe for success. Perhaps it was too harsh for me to term this behaviour “inaction”, but if there has indeed been action behind the scenes, this action has been both very slow and, worse, ineffective.

    In all of this back and forth, we’ve not thought much about the old Microsoft EOT option (although Mr Zeldeman mentioned it previously). Here’s the thing: it more or less does everything Mr Berlow wants it to do, it’s already out there, Microsoft has offered it to the W3C and… Well? And what? I’ve read the publicly-available minutes, and there just seems to be the same-old suspicions of MS’s motives. There could have been movement behind supporting this format by the other browser vendors.

    But that’s by the wayside. As I was trying to say in my original comment, these arguments should have been made years ago, not suddenly on the cusp of (or after!) new @font-face-supporting browser versions.

  7. Unlike us, however, none of those industries mentioned, are trying to get a 21st century meta-data file like this one added to their formats

    Glancing through your OTPermTable proposal, I see a lot of phrases that start with “Permission for font software to be…” Are you expecting client applications to enforce these restrictions, or are they just for the lawyers?

  8. Ray wrote In all of this back and forth, we’ve not thought much about the old Microsoft EOT option.
    Exactly! It took us (Ascender Corp) awhile, but we figured out that while the proposals for a new web font format (such as .zot and .webfont) are nice, they don’t solve web designer’s needs today. They will take 3 to 5 years before they would become finalized, blessed by appropriate folks, and then implemented widely in enough browsers that web designers would start using it. Haven’t we all waited long enough? Isn’t there something else we can do today?

    That’s why we came up with our proposal. It removed the 2 things that the browser makers found objectionable: IP protected font compression and URL binding. One of the nice things about EOT Lite is that it works today in all versions of IE. Yes, it does not work today in Firefox, Safari or Chrome. But it addresses the needs of commercial type designers who want to license their fonts to web designers but don’t want raw TTF/OTF fonts to be used.

    One of the nice things about the proposed OT PermTable is that it also can be implemented today. The OpenType font specification allows for private tables to be used – so there is nothing to stop a type designer or font vendor from implementing a PermTable in their fonts.

    In summary, a type designer can choose to add a PermTable to their OpenType font, and then deliver it either as a raw TTF/OTF font, or as an EOT font. Either way, it allows type designers to add more information to the fonts to clarify licensing rights, usage recommendations, or other meta data for customers.

  9. It’s not DRM. It’s a component of a font that says the font is licensed for web use.

    If there is required behavior for client applications based on this data, it is very much a form of DRM. Same as DVD region codes, which simply indicate the region of usage. But since players are required not to play discs with a region mismatch, that makes it part of a DRM mechanism.

    I think David originally suggested that client applications could only use fonts with a PERM table but weren’t required to actually restrict usage based on the fine-grained permissions but that’s not at all clear from the proposal.

  10. I have to side with John Daggett on this one. At TypeCon here in Atlanta, I was discussing the perm table with Ted Harrison of Fontlab who also felt strongly about it because the four levels of embedding permissions currently in use were designed before the web was a consideration. He also said that it was proposed mainly out of sense of frustration because font-makers felt frozen out of the process that was going to decide their fate on the web. Ted’s first point makes sense.

    Want to add a permissions table? Absolutely, add one. I’d love to be able to query the font file and find out what the authors allow and don’t allow.
    Hunting down external EULA’s are a ridiculous waste of time.
    The rub comes in when you require the user-agent TO ACT on information in that permissions table. Which, as John says, is most definitely a form of DRM. Which Ascender has just REMOVED from EOT with EOT Lite.
    Let’s not worm ourselves deeper into a morass. If all a user agent or other supporting application does is report the information inside the table, then what additional protections to the font-maker does it provide?
    Please, let’s stay focused. There are more pertinent solutions on the table.

    Is EOT lite an acceptable solution in the short term? That’s question number one right now.

  11. The rub comes in when you require the user-agent TO ACT on information in that permissions table. Which, as John says, is most definitely a form of DRM.

    Is that correct? As part of David Berlow’s proposal, the browser is required to do something in response to information in the permissions table? If so, it would make the browser the guardian of a type designer’s rights, which is indeed a form of DRM, and it means not only type designers but also browser makers have to approve and implement the proposal.

    That’s not how I understood the proposal, but I could be wrong. David Berlow, can you comment?

  12. Is EOT lite an acceptable solution in the short term? That’s question number one right now.

    I (perhaps wrongly) understand EOT Lite to be a form of DRM. Is it not?

    I also have reservations about the additional packaging EOT Lite requires. Berlow’s proposal appears to remove the need for additional packaging and handshaking. I support it on that basis. Am I off-base?

    Without violating the rights of type designers, web designers should be able to serve a font with @font-face, period—with no technical or legal burden to obscure the font, no third-party intermediation, and no scripting, except what might be required to trick IE into “supporting” @font-face as other browsers already do.

    As I understand David Berlow’s proposal, I buy a web-licensed version of a font I want to use in a design, and I’m done. I can go ahead and use @font-face without technical or legal impediment.

    Is it more complicated than that? More complicated even than EOT Lite? Color me confused.

  13. As I understand David Berlow’s proposal, I buy a web-licensed version of a font I want to use in a design, and I’m done. I can go ahead and use @font-face without technical or legal impediment.

    Given that the PERM table is buried in the font binary, and that it isn’t enforced by the UA (and will never be), there is effectively no difference between using a PERM table “webfont” and a raw OpenType font. Likewise, there’s technically nothing to prevent a foundry licensing you a raw OT font for use on the web. The reason you’re ‘done’ is the licence, not the PERM table.

    The issue is that it is hard for a foundry to assert their moral rights over their work in an accessible way within a raw OT font. An unenforced PERM table suffers from the same problem. It’s buried in the font and ignored by the UA, whether that be a browser or a desktop application.

    A proposal like Leming and van Blockland’s .webfont provides the user with both the information and the opportunity to Do The Right Thing in a format agnostic manner that doesn’t require browser manufacturers to act as licence police.

  14. Pingback: Greatcalls
  15. @jeffreyzeldman
    Without my going on and on in response to all of your questions and concerns – which do deserve answers and that I will make it a point to answer them on my blog as part of my coverage of the Web Fonts issue and the TypeCon 2009 Web Fonts symposium.
    I’ll try to catch you up. You’ve had tsurris, or so I’ve heard.
    Here’s the nub of the issue as I’ve seen it unfold in numerous forums and the W3C mailing list:
    The concern among font-makers is twofold:
    1) Linking to “raw” OTF files makes it easy to download them
    2) The downloaded OTF can then be easily installed in the OS
    Number two is of greater concern than number one.
    What font-makers have asked for is, in the phrase used by Vlad Levantovsky of Montoype, a “garden fence” that, at least, makes the font file web-specific and therefore uninstallable in such an easy fashion.
    THAT’S the killer: the easy installability. No fence.
    Now, EOT has morphed into EOT Lite which makes EOT little more than an alternative font file format: the DRM-like requirement of “binding” the file to a particular domain via rootstrings has been removed, and – unfortunately, at least to my desires – the MTX compression which is still under Patent by Monotype has been removed.
    EOT Lite still supports sub-setting which is very useful in cutting down the humongous file sizes we’re dealing with.
    And so, an EOT light file becomes a TTF or OTF by another name which, in the eyes of font makers, at least provides that “garden fence” against easy installation.
    I’ll ask Bill Davis of Ascender to check my facts on this and re-post if I’ve gotten anything wrong.

  16. As far as I know, no DRM (ok, or sort of DRM) will stop someone from illegally finding/copying/etc. some content.

    Same applies to fonts, no matter if they can be used on the Web or elsewhere…

    So I think that the easier is to use/embed fonts in Web pages, the better. Everything else will just make matters more complicated. Users won’t win from this, nor browser makers, nor designers, nor font foundries…

    Just my $0.02…

  17. Pingback: Retrograffica
  18. Pingback: Design Diário
  19. Pingback: News - 5pieces
  20. If the browsers don’t let anyone copy the protected fonts it downloads, no-one is losing anything; if someone wants the font, they can go and buy it. In this way, anyone anywhere can download the font to use, through the browsers — as long as free fonts can be downloaded freely.

    The subset of possible thieves, really, is shrunken down to usually-honest professionals. If the foundries can have a trusting relationship with the developers, things will go smoothly.
    Essentially, it could be just like it is today: administrators pay for a font, and they get the font files. They’re expected to install it only on the number of machines they have licenses for, but they can move the fonts around as they wish. As long as someone doesn’t notice something wrong, it’s assumed that they’re being good. That system is working, so far.

  21. If the fonts will be used without the commercial pressures and are not violating copyright – you can not turn a blind eye to this problem. Such cases should be solved in different ways. In each case – has its own denouement.

  22. Thanks for the information, ist is helpfull for us. Greetings from GERMANY from TOM.
    my motto: mountains never meet, people always

  23. Pingback: Font-Face Heats Up

Comments are closed.