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
Filed under: Browsers, CSS, Design, Fonts, Real type on the web, Standards, Typography, Web Design, Web Design History, Web Standards, spec, webfonts, webtype
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.
[...] Zeldman on a proposed webfont permissions table. This seems sort of like attaching a file to a movie that says DO NOT STEAL and expecting it to work. [...]
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!
[...] This counts Font Bureau out of the above list of foundries which support the .webfont proposal. Jeffrey Zeldman likes the idea of this proposal. Perhaps this will spell another split in the ranks. It seems to me [...]
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?
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-facehas 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-facefirst 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.
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
IMGwithalttext); 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.
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.
It’s not DRM. It’s a component of a font that says the font is licensed for web use.
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!
@dberlow: What’s your opinion on Leming & Van Blokland’s proposal?
[...] 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. — 16 July 2009 [...]
@dberlow,
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?
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.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?
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.
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.
[...] Zeldman reasons out a third alternative in this post and a followup comment about David Berlow’s proposal – a Permissions Table for OpenType, [...]
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.
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?
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.
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.
[...] 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 … [...]
@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.
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…
[...] iampariah: Web Fonts Now, For Real – Jeffrey Zeldman [...]
[...] O futuro da tipografia na web. [...]
[...] 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 … [...]
[...] Web Fonts Now, for real [...]
[...] you’re not already confused, then let me introduce you to David Berlow’s (The Font Bureau) Permissions Table for OpenType proposal. (Technical specification here). Without getting too technical, I think Berlow’s proposal can be [...]
[...] David Berlow’s proposed inclusion of a permissions table within OTF font files, titled Web Fonts Now, For Real, web standards advocate Jeffrey Zeldman posed a question regarding EOT Lite, the hastily named [...]
@jeffreyzeldman:
An answer to the first of your questions regarding EOT Lite is posted.Jeffrey Zeldman Questions The EOT Lite Format
More to come.
@ilovetypography chimes in on the question of “web fonts, where are we?” After some light technical discussion, he says where we are is Typekit.
[...] behind his company’s EOT Lite proposal in response to a question I raised here in comments on Web Fonts Now, for Real. The name “EOT Lite” suggests that DRM is still very much part of the equation. But [...]
[...] 20 Jul 2009 Web Fonts Now, for real [...]
[...] you’re not already confused, then let me introduce you to David Berlow’s (The Font Bureau) Permissions Table for OpenType proposal. (Technical specification here). Without getting too technical, I think Berlow’s proposal can be [...]
[...] [...]
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.
[...] David Berlow 的 Permissions Table for OpenType 提案可以给我们一些提示（技术细节 [...]
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.
[...] A good summary by Zeldman on another option for embedding fonts on the web. http://www.zeldman.com/2009/07/16/web-fonts-now-for-real/ [...]
Thanks for the information, ist is helpfull for us. Greetings from GERMANY from TOM.
my motto: mountains never meet, people always
[...] you’re not already confused, then let me introduce you to David Berlow’s (The Font Bureau) Permissions Table for OpenType proposal. (Technical specification here). Without getting too technical, I think Berlow’s proposal can be [...]
[...] Open Type Permission Table Open Type Permission Table Specs [...]
[...] 关于这一技术 David Berlow 的 Permissions Table for OpenType 提案可以给我们一些提示（技术细节），简单说，就是在字体文件中嵌入许可信息，比如，在字体中嵌入某个站点是否拥有使用某个字体的许可的信息。 [...]
[...] trivially take it off a webserver and install it on their machine. These two proposals offer a “garden fence” approach to protection; it’s still quite easy to get inside and snag the font, but [...]
[...] trivially take it off a webserver and install it on their machine. These two proposals offer a “garden fence” approach to protection; it's still quite easy to get inside and snag the font, but [...]
[...] Владом Левантовским из Monotype, а стала известною в пересказе Ричарда Финка), то есть пожелали иметь такой формат шрифта, который, [...]
[...] Typekit 的实例（http://forabeautifulweb.com/）：最后的思考 我们需要一致意见，然而一致意见只能通过妥协获得。字体业并没有一个行业协会可以投票通过某个决议，最接近的办法是找出所有支持 .webfont 的字体公司。尽管 .webfont 存在安全问题，然而绝大多数重量级字体公司都支持 .webfont，见 @typegirl 的 Twitter 消息 Most of the important foundries are supporting #webfont。如果最终无法达成一致，.webfont 将永远停留在提案阶段，如果达成一致，我们在浏览器中看到 .webfont 的最早时间恐怕也要2011到2012年。最终不管哪个方案获胜，那些字体设计师们也要抓紧时间，多数字体目前还没有为在屏幕上显示进行优化，如果他们要和那些已经做了优化的字体（如 Verdana）竞争的话，他们前面的工作还很繁重。本文国际来源：http://ilovetypography.com/2009/07/20/web-fonts-%E2%80%94-where-are-we/中文翻译来源：COMSHARP CMS 官方网站 [...]
[...] you’re not already confused, then let me introduce you to David Berlow’s (The Font Bureau) Permissions Table for OpenType proposal. (Technical specification here). Without getting too technical, I think Berlow’s proposal can be [...]
[...] Web Fonts Now, for Real: David Berlow of The Font Bureau publishes a proposal for a permissions table enabling real fonts to be used on the web without binding or other DRM. — 16 July 2009 [...]
[...] convalescing, I read a fascinating discussion over on Jeffrey Zeldman’s blog. In this article, Zeldman publicised the fact that David [...]