惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
雷峰网
雷峰网
Recent Announcements
Recent Announcements
月光博客
月光博客
G
Google Developers Blog
腾讯CDC
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
T
Tenable Blog
云风的 BLOG
云风的 BLOG
W
WeLiveSecurity
博客园 - 【当耐特】
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
博客园 - 聂微东
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
P
Privacy International News Feed
MyScale Blog
MyScale Blog
K
Kaspersky official blog
T
The Blog of Author Tim Ferriss
Attack and Defense Labs
Attack and Defense Labs
Spread Privacy
Spread Privacy
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
aimingoo的专栏
aimingoo的专栏
I
Intezer
Vercel News
Vercel News
小众软件
小众软件
Simon Willison's Weblog
Simon Willison's Weblog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
Latest news
Latest news
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tor Project blog
S
Security Affairs
P
Proofpoint News Feed
博客园 - 三生石上(FineUI控件)
博客园 - Franky
C
Cyber Attacks, Cyber Crime and Cyber Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
美团技术团队
Recent Commits to openclaw:main
Recent Commits to openclaw:main
S
Security @ Cisco Blogs
L
LINUX DO - 热门话题
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
D
Docker
L
Lohrmann on Cybersecurity
F
Full Disclosure

David Baron's Weblog

Software engineering, responsibility, and ownership Software engineering, responsibility, and ownership David Baron's weblog: Security and Inequality Running animations on the compositor thread David Baron's weblog: Tying ecosystems through browsers David Baron's weblog: Payments on the Web Thoughts on migrating to a secure Web David Baron's weblog: The need for government David Baron's weblog: Priority of constituencies How browser developers should seek feedback from Web developers A possible approach to shorter release cycles David Baron's weblog: Fifteen years Why debug builds (and assertions) are important Ten years of the Mozilla Foundation Open licensing at the W3C Why adding compositing and blending to CSS is harder than it looks How you can help with removing -moz- prefixes Moving bug history out of the primary display of a bug report Beware of locale-specific behavior in the C library Eating dogfood and shipping software Specification style and the future of the Web The bug system I wish I had CSS border-image changes and unprefixing Improving font size readability on Firefox for Android David Baron's weblog: CSS Animations, part 2 Hue-preserving color inversion with SVG filters Changes to handling of @-moz-keyframes David Baron's weblog: window.matchMedia() David Baron's weblog: CSS Animations What does a blur radius mean? Crash analysis in the future David Baron's weblog: calc() David Baron's weblog: colorDepth David Baron's weblog: Hidden complexity in specifications The most important field in a bug report: the summary WOFF font format submitted to W3C David Baron's weblog: :-moz-any() selector grouping setTimeout with a shorter delay Faster repainting in SVG foreignObject David Baron's weblog: Distributed Extensibility David Baron's weblog: Broadening crash analysis Correlating crashes with binary extensions or plugins David Baron's weblog: ex-HTML Web Accessibility as a Political Movement David Baron's weblog: CSS priorities David Baron's weblog: Bug priorities David Baron's weblog: Semi-vacation Some new CSS features in Firefox 3 David Baron's weblog: New selectors David Baron's weblog: The age of bugs Seeking a good Linux distribution David Baron's weblog: Teaching to the test David Baron's weblog: March 2008 David Baron's weblog: February 2008 David Baron's weblog: January 2008 David Baron's weblog: October 2007 David Baron's weblog: September 2007 David Baron's weblog: August 2007 David Baron's weblog: June 2007 David Baron's weblog: April 2007 David Baron's weblog: March 2007 David Baron's weblog: January 2007 David Baron's weblog: September 2006 David Baron's weblog: August 2006 David Baron's weblog: July 2006 David Baron's weblog: May 2006 David Baron's weblog: February 2006 David Baron's weblog: January 2006 David Baron's weblog: December 2005 David Baron's weblog: October 2005 David Baron's weblog: September 2005 David Baron's weblog: June 2005 David Baron's weblog: May 2005 David Baron's weblog: April 2005 David Baron's weblog: March 2005 David Baron's weblog: February 2005 David Baron's weblog: October 2004 David Baron's weblog: September 2004 David Baron's weblog: August 2004 David Baron's weblog: June 2004 David Baron's weblog: May 2004 David Baron's weblog: April 2004 David Baron's weblog: March 2004 David Baron's weblog: February 2004 David Baron's weblog: January 2004 David Baron's weblog: November 2003 David Baron's weblog: October 2003 David Baron's weblog: September 2003 David Baron's weblog: August 2003 David Baron's weblog: July 2003 David Baron's weblog: June 2003 David Baron's weblog: May 2003 David Baron's weblog: April 2003 David Baron's weblog: March 2003 David Baron's weblog: February 2003 David Baron's weblog: January 2003 David Baron's weblog: December 2002 David Baron's weblog: November 2002 David Baron's weblog: September 2002
Downloadable font formats for the Web
David Baron · 2009-03-18 · via David Baron's Weblog

There's been a bit of debate over the past year or so about W3C possibly doing work in the area of font formats for downloadable fonts. Downloadable fonts are a good thing because they increase the capability of the Web platform (and thus its competitiveness relative to its proprietary competitors), give designers more capabilities to use in their work, and improve the accessibility of Web content to tools and users by keeping text as text rather than leading it to be converted to images.

Microsoft Internet Explorer has long implemented downloadable font support using the Embedded OpenType (EOT) format, which was previously proprietary but has now been submitted to W3C in two parts, EOT and MTX. WebKit, Mozilla, and Opera have now implemented and have either shipped or are planning to ship in their upcoming releases support for downloadable fonts using the widely-used and implemented TrueType and OpenType font formats (the latter is a standard, the former is roughly a pre-standard subset of it, or something like that).

For previous parts of this debate, see posts by Bill Hill and by Chris Wilson at Microsoft, and a post by my Mozilla colleague Robert O'Callahan.

I think there are two big questions in this debate. First, which restrictions would make which font foundries comfortable with selling their fonts for use on the Web? Second, which restrictions don't put an undue burden on browser makers, Web authors, or Web users?

I'd like to look at the EOT proposal in the context of these questions. EOT is a wrapper around OpenType fonts that adds an extra header before the font, and in which some of the contents of the font may be compressed with a different compression algorithm (MTX) and/or obscured using XOR. The extra header contains a root string that gives the hostname or domain with which the font is allowed to be used.

EOT does three things that I'm aware of that might make font foundries more comfortable selling their fonts for use on the Web. These are:

  1. The font is in a different format, so people can't just copy a font off a Web site and drop it into their fonts folder. (They'd need a tool to turn it into something they could do this with, which is expected to make them more aware that what they're doing may be wrong.)
  2. The font is tied to a particular Web site, so somebody writing a different site can't accidentally copy or link to the style sheet (e.g., a style sheet on a site with a liberal re-use license) and thus end up accidentally using the font without paying for a license.
  3. The font is tied to a particular Web site by the root string embedded in the font, so somebody writing a different site can't copy the font to their site without using a tool to modify the root string field inside the EOT file.

So I'd like to consider my second question first. One of the arguments about EOT is that this third point (and, more generally, the presence of the root string in the file format) is a form of DRM, which is in general known to place an undue burden on all participants in the process (those licensed to use the font, those who develop the software to use it, and anyone else involved) both because because DRM technology often places obstacles in the way of rights that they do have and because the presence of DRM can add additional (perhaps troubling) legal constraints because of laws written specifically about DRM. DRM has also generally proven ineffective, since those determined to break it are capable of doing so. (In the case of EOT, how to break it is documented in the standard itself, which is public, so there isn't even a claim that it might be unbreakable, merely one that it requires effort to break.) I think we should avoid DRM or any DRM-like formats on the Web, for the above reasons, and because one of the core principles of the Web and the technology used to build it is opening up access to information, while DRM is about restricting such access. So I'm opposed to having any DRM-restricted formats on the Web.

Now, my first question: what makes font foundries comfortable licensing their fonts for use on the Web? No matter how downloadable fonts on the Web work, some foundries will never be comfortable selling their fonts for such use. Other foundries, on the other hand, have licensed fonts under open-source licenses. So the question here is not one of absolutes: we should accept that nothing will make all font foundries happy. The question is one of magnitude: we'd prefer that more fonts be available for use on the Web, for the same reasons that we want downloadable fonts in the first place.

So the question is: how many foundries will sell their fonts for use on the Web given a particular set of restrictions? The cross-domain check that Mozilla already implements for its downloadable font support (and is probably a good idea for other reasons) gives foundries item (2) above in the list of what they get from EOT. If we were, say, to standardize a new font format that is the same as OpenType except for an additional 8-byte header at the beginning of the file, that would also provide item (1) in that list.

We could just ask the foundries what would make them comfortable, but when we do, we have to remember that foundries are likely to prefer that browsers have more restrictions. They're not yet comfortable with the business model of selling fonts for use on the Web, and they can't (yet) watch other foundries practicing such a business model. Furthermore, if they would prefer more restrictions, but are still willing to sell fonts for use on the Web with fewer, they have an incentive to say that their breaking point is higher than it really is as part of a negotiation process.

So I think the best path forward, to avoid burdening the Web platform with technology that it doesn't need and that can be harmful, is to determine by experiment how many foundries will sell their fonts. Browsers should all ship interoperable support for downloadable TrueType and OpenType fonts, and then we should see how many authors want to use it and how many fonts become available. Some foundries might only become willing to license their fonts for use on the Web once they see other foundries making money off such business. Once we've observed how many fonts become available once the technology that Mozilla, WebKit, and Opera have already implemented is widely deployed, we can try to determine if additional technology (such as a font format that is simply TrueType plus an extra 8-byte header at the front) would lead to a significant increase in the set of fonts available for use on the Web.