Nice Web Type

Nice Web Type is one place for web typography, following experiments, advancements, and best practices in typesetting web text. Handcrafted by Tim Brown, Type Manager for Adobe Typekit.

Web font licensing: the basic idea

This font licensing stuff makes my brain hurt. Maybe writing will help. If you don’t write, you don’t know what you think.

Typekit and .webfont

I was reading Christopher Murphy’s summary of the .webfont proposal and this paragraph made me pause:

What’s appealing about this proposal is its reliance on an existing standard – @fontface – that removes the need for workarounds and hosted solutions (one of the key criticisms of the Typekit proposal).

As I understand it, the real difference between Typekit and the .webfont proposal is that .webfont, while it seems a very good and open solution, will need browser maker support in order to work. Typekit could theoretically work right now.

Typekit will obscure fonts so they’re difficult to steal; .webfont requires that “illegal use” conditions be built into future versions of web browsers.

Another important difference is that .webfont would free designers from having to subscribe to a service. But that won’t negate Typekit.

Typekit will provide more than fonts for use with @font-face. It will offer a single, well-designed interface for font management, plus other goodies like hands-off fallback methods for displaying your fonts even in browsers with no support for @font-face.

OpenType Permissions Table

Jeffrey Zeldman reasons out a third alternative in this post and a followup comment about David Berlow’s proposal – a Permissions Table for OpenType, which Jeffrey describes as follows:

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.

It’s possible that a foundry like Berlow’s Font Bureau, as Zeldman points out, could be ready tomorrow, but browsers would still have to catch up and support license enforcement … right?

The gist of it all (I think)

The .webfont and Permissions Table proposals are very good ideas that require technical and logistical action from stereotypically sluggish industries. Typekit, if it were released tomorrow, would be ready to use.

I have no problem paying for Typekit first, then rolling my own @font-face code when the web font standards and browser support have caught up … assuming, and it’s a large assumption, that fonts I put into my websites using Typekit can be used if I discontinue my Typekit subscription (license ported somehow, or typeface available for web embedding from some other source).

13 comments

  1. Jason Santa Maria 17 Jul 2009

    Right, serving fonts is just one of the services Typekit will provide, in addition to smart fallbacks and some other goodies. As you can see from the development screenshot we posted to Flickr, you’ll also be able to customize a typeface’s character set to make the files smaller (for instance, if you know you need a typeface just for numbers, we can make a file that only includes those characters).

  2. Johno 17 Jul 2009

    Tim, you‘ve beaten me to it. I was in the middle of writing about the current web fonts situation.

    The point Jason makes is important. The ability to use just a subset of a font (font files can be pretty big and may include character sets that you’ll never use) is a big plus.

    Moreover, — and this is something I’m stressing in my article — the .webfont solution is something to look forward to in 2011 or 2012 (perhaps later). TypeKit, on the other hand, is just around the corner.

  3. Tim Brown 17 Jul 2009

    Looking forward to your post, John. I always enjoy your insight, and actually I’m flattered to have contributed to this public discussion in a way that you would have.

    Thanks for sharing here. You too, Jason. Good points, both.

  4. Paul Randall 17 Jul 2009

    What I am not 100% is how this will work for older browser, such as IE6. Will we still have to do browser checks and use something like Cufon, or could Typekit deal with this aswell?

  5. Christopher Murphy 17 Jul 2009

    All great points and in many respects I agree.

    You’re absolutely right when you highlight the fact that both Tal Leming and Erik van Blokland’s .webfont Proposal and David Berlow’s Permissions Table for OpenType proposal would “require technical and logistical action from stereotypically sluggish industries.” However, in the browser vendors’ defense, they do appear to be moving just a fraction more quickly now (that said, this is from a somewhat slow pace to start with).

    I think your idea of paying for Typekit first, then rolling @font-face markup when it’s supported is probably the route most web designers would embrace. I, for one, would prefer the knowledge that I have a measure of control over the files in lieu of relying on a third party hosted solution and the potential problems that may bring.

    In Typekit’s favour this allows them to craft a service that’s so easy to use few will choose to make the jump to maintaining their own files, preferring instead the simplicity of the service and the “smart fallbacks and other goodies” Jason refers to above. In some respects this is a little like the simplicity of iTunes, it’s simple, fast, reliable and makes trawling for peer-to-peer MP3s (and other content) too much hassle.

    iTunes has proved that a well-designed, well-considered and beautifully crafted service can be appealing to many. Yes, it’s true typefaces are more expensive than audio and video, however, many designers bill their clients for typefaces as part of a typical project budget. If Typekit can create a compelling service then this might win many over because ‘it just works’.

    The point you make in closing is probably the point that concerns most about Typekit. The ‘what if I choose to discontinue my subscription, what then’? Until this is clarified it’s difficult to choose any proposal. We need all the cards on the table, then we can all make an informed decision.

    Still, it’s good to see the ball rolling on this. For that we owe a heartfelt thanks to all those that are working on the various proposals in the pipeline. Without their effort we’d very likely be where we’ve been for far, far too long.

  6. Brendan Falkowski 17 Jul 2009

    I’m not aware of pricing scenarios for TypeKit, but won’t the service potentially limit the creativity of less affluent designers. For freelancers budgeting an additional $25/month (wild guess) will be a tougher gambit than agencies will face.

    Should poor designers be relegated to the core web font stack?

    This masks the real issue and segregates us as practitioners. Browser support needs to be bolstered concurrently as service-based workarounds provide relief now.

    To TypeKit, kudos on limited character set options. Obviously some smart people working over there.

  7. Johno 17 Jul 2009

    Christopher

    «what if I choose to discontinue my subscription, what then?»

    I imagine that, if you have a font stack it will simply display the next or first typeface in the stack.

    Brendan

    «but won’t the service potentially limit the creativity of less affluent designers?»

    No, it won’t. There are typefaces I’d love to use in my own work, but they’re simply out of my price range (Trinité, for example). Either one absorbs the cost or passes it on to one‘s client; if that’s not possible, then go with a more affordable option. Bigger agencies have bigger budgets, but that doesn’t stop freelancers from producing exceptional work — both on the Web, and in print. That’s not intended to sound confrontational :)

  8. Christopher Murphy 17 Jul 2009

    Johno

    «I imagine that, if you have a font stack it will simply display the next or first typeface in the stack.»

    I don’t doubt that that’s exactly what will happen (especially when looking at the development screenshot at Jason’s Flickr stream). However, this is still a concern – and one that I imagine would concern many working designers.

    I work on a web site for a client, specify a typeface with Typekit. For a full year after launch everyone’s happy. The client’s site is entirely rendered in curvaceous Bello courtesy of Underware (they manufacture chocolate and just love Bello’s distinctive curves).

    One year on my client’s budget’s been slashed due to a drop in profits – everyone’s dieting – they can no longer afford to pay my rates. They decide to bring in a younger designer, fresh out of university (one of my graduates perhaps).

    My subscription for Bello, for the aforementioned company, comes to an end as they are no longer a client. Suddenly, no Bello, just austere, very un-chocolatey Georgia. The client’s unhappy, thus ensues much to’ing and fro’ing.

    As contributors to the comments here we all 100% understand what’s going on, and why this has happened. The client – an everyday user – sadly doesn’t.

    I imagine there are a great deal of designers kicking around these ideas and wondering how exactly the service will work. Hence my point above, “We need all the cards on the table, then we can all make an informed decision.”

    Like your point above, that’s not intended to sound confrontational. Just kicking around ideas. ;-)

  9. Eric Fields 17 Jul 2009

    Graceful fallbacks sound nice, but that means I probably wouldn’t use this for anything more important than headlines — such as branding or any other instance where an exact font is *necessary*.

    I’ll have to put a Typekit clause in proposals, too. “I’ll be using this thingamajig, but someday I might cancel my subscription, which means your fonts might look less fun and you won’t be able to easily do anything about it.”

    But, aside from that — awesome!

  10. Brendan Falkowski 17 Jul 2009

    @ Johno

    All valid points. Nobody has the option to embed type as they wish today, but TypeKit promises a taste.

    Consider how TypeKit could be packaged:

    1 – Unlimited everything (flat fee)
    2 – Type stacks available on unlimited sites (flat or variable fee)
    3 – Type selected x # projects using (variable fee)

    My concern is the cost of entry will be high with TypeKit. 37 Signals still has this problem despite their lauded products. Consider a small agency vs. freelancer using Basecamp:

    $50 Plus plan over 5 employees (or $10/user)
    $24 Basic plan over 1 employee (or $24/user)

    Scale affords the agency more resources and functionality – and it should – but the individual is effectively priced out of the service. Sometimes costs can’t be absorbed or passed along.

    We can bill clients for the entire Trinité family ($4239) or a single Helvetica face ($29) just the same. TypeKit is not giving us more typefaces, it gives us consistent application of any licensed type. That’s the value.

    Designers with unrestricted type usage will have more creative potential.

    For this reason, costs must be scaled realistically for all scenarios. Can TypeKit be affordable for a personal blog and Ars Technica simultaneously? I hope so.

  11. Brook Elgie 18 Jul 2009

    .webfont requires that “illegal use” conditions be built into future versions of web browsers.

    Although I’m not entirely sure what you mean by this, I’ll just clarify that the current .webfont proposal doesn’t require that browsers prevent “illegal use”. The proposal does suggest that browsers give users access to metadata from the .webfont (including licensing info) from within the UI somehow (in the Page Info window, for example).

  12. Tim Brown 18 Jul 2009

    Brook, thanks for clarifying. What you said in this comment at Jeffrey’s site is equally illuminating.

    In retrospect, I should not have put the words “illegal use” in quotes. That terminology wasn’t borrowed from anywhere, nor did I mean to suggest that the use of typefaces outside of their EULAs is a frivolous matter.

    When I wrote that bit, I was thinking that some method of enforcement would be necessary to notify type sellers of fraudulent use … or shame website creators/owners by telling their sites’ visitors, “What you’re viewing is not legal.”

    In the comment of yours I referenced earlier, on Jeffrey’s post, you wrote, “[...] there is effectively no difference between using a PERM table ‘webfont’ and a raw OpenType font.

    Having read that, and your comment here, I realize the advantage that .webfont offers is that the information about legal use for a given typeface would be more available.

    What actions, without support via web browser makers, might a web designer, website owner, type designer, or website visitor be able to take to act on this information?

  13. Rapid Prototyping 24 Jan 2011

    I will be waiting for both the .webfont solution and the type kit too. I think the time will decide how will be able to make use of in easy and appropriate way. Every one will try to find some short cuts or even the easy access for the both. Let it release first and much more can be done later on. It is hard to predict about the prices too. So should wait with good hope for some time and then decide for which thing to go first.

Twitter: @nicewebtype
Dribbble: timbrown

Combining Typefaces

 

I wrote a small book about combining typefaces. Buy it for less than the cost of a fancy beverage.