...note that in removing URL-binding this format no longer conforms to the OpenType spec’s definition of document font embedding.

You are saying that the OpenType spec's definition of font ‘embedding’ as it relates to web fonts requires URL binding, yes? So in effect you recognise two different kinds of font linking, one of which constitutes ‘document font embedding’ because the fonts are bound to a particular URL. Is that correct? Can you point me to the part of the OT spec that explains this? I've looked, and I don't see anything that would lead obviously to this interpretation of the word ‘embedding’.

Since the non-IE browser makers have explicitly rejected URL binding -- hence why it is not included in the CWT format --, by your definition there are no embedded fonts in use with those browsers -- yes? -- even though the mechanism of linking may be identical to IE EOT linking excepting URL binding?

This looks to me like a recipe for confusion; indeed, it is a recipe that we're already tasting.

Secondly only allowing “installable embedding” fonts to be used. As we do not propose changing the OpenType font specification’s definition of “installable embedding” it would still be the responsibility of web site creators to confirm that the font license allows raw-font linking.

Any free or open source font will have a license that permits format conversion, hence I don't see any reason at all for supporting raw font linking. You get the same mileage from supporting WOFF, with the added benefit of format-side compression.

If a font is not encapsulated within a document or tied to it (via a binding type mechanism) then it's not document font embedding. I do not believe there's any confusion here, as font EULAs typically say what's okay and what isn't, supplementing the permissions bits.

In my opinion the additional hoop of format conversion would have been a good one, but we've moved beyond that now. I don't think the other browsers are considering dropping support for raw fonts.

Si, I think no one would disagree that a font ‘encapsulated within a document’ is embedded. What seems to me problematic is the assertion that ‘tied to a document’ also constitutes embedding. The former is common usage and understandable from non-specialist usage of the word embedded; the latter is a stretch, and to say that it is ‘the OpenType spec's definition of document font embedding’ is a really big stretch, because this is what the OT spec says re. the OS/2 fsType bits (the only part of the spec font embedding is discussed:

Embeddable fonts may be stored in a document.

Stored in a document. The spec doesn't say anything about ‘tied to a document’, nor any other wording that would lead obviously to such an interpretation. It simply isn't normal English usage to equate embedding with some kind of strong linking. Embedded reporters in Iraq operate within army units; they're not strapped to the outside of the humvee.

In my opinion the additional hoop of format conversion would have been a good one, but we’ve moved beyond that now. I don’t think the other browsers are considering dropping support for raw fonts.

For free and open source fonts, format conversion is barely a hoop. The same sites that make the TTF files available can make the WOFF files available. In neither commercial web font licensing nor in distribution of free and open source fonts is anyone anticipating end-user format conversion. That really is something we've moved beyond.

But while we've moved beyond end-user format conversion, we've spent months -- successfully -- moving Mozilla and other browser makers toward a web-specific font format. Sure, those browsers that already support raw font linking are not going to remove such support, but that support is meaningless if an interoperable format acceptable to the majority of font vendors is implemented. And such a format works just as well and in exactly the same way for free and open source fonts.

Meanwhile, I am concerned that if IE starts supporting raw font linking, even with the restriction that it only applies to fonts with the installable embedding bit set, then you will encourage an ‘ecosystem’ in which TTFs and OTFs are uploaded to web servers, an ecosystem in which all the other browsers will be ignoring the embedding bits. As I wrote to the W3C list in August, I think the argument that raw font linking for free and open source fonts is somehow magically separate from the issue of unlicensed use of commercial fonts is a naïve fantasy:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1316.html

___

You wrote above re. WOFF support: EOT started with a long list of supporters too.

Monotype and Adobe, if I recall. Who else?

And why, for ten years, did EOT go nowhere? Primarily because it only worked on one browser. So that should tell you that the success of a web font format is dependent on browser interoperability, not on advanced sign-up from font vendors. You need the format to be agreeable to font vendors, but it is the implementation in the browsers that will make it successful.

EOT was a format that the makers of IE wanted font vendors to support. WOFF is a format that makers of fonts want IE to support. That seems to me an important distinction.

I don’t want to editorialize too much as the point of this post is to solicit feedback. The “URL-binding = font embedding” discussion with the foundries took place ahead of this press release which also lists out the long list of “supporters”. People are free to argue this point, but it seems largely academic as foundries have moved on.

With respect to raw fonts, the argument that IE is the only thing holding back the floodgates of abuse, seems a bit disingenuous. Foundries are lining up to license their fonts through Typekit and similar services, and the other browsers don’t seem to be backing away from raw-font support. In addition given browser upgrade cycles it could be years before WOFF support reaches even half the browser install base.

The font makers to whom I have spoken who are making use of Typekit-like services are doing so because such services offer various kinds of server-side obfuscation as protections of the font. If these services were simply serving raw TTFs or OTFs direct from their servers to users' browser caches, then foundries would be no more interested in these services than they are in raw font linking. I've discussed this with a lot of colleagues, and very few people are open at all to raw font linking per se -- this is why font makers developed WOFF --; raw font linking with server side obfuscation seems acceptable to some people, but not to everyone. Further, the Typekit people are themselves in favour of a single interoperable format, so that they can move away from serving multiple formats, and seem to understand that they will attract more foundries if they are able to completely bypass raw fonts as a format (which they will be able to for Firefox 3.6).

...other browsers don’t seem to be backing away from raw-font support.

In the Spring of this year, raw font linking was being pushed by the non-IE browsers as the preferred interoperable web font format. Since then, they've pretty much stopped talking about it, in the case of Mozilla have worked with font makers to develop and implement WOFF, and have even tested CWT implementations. No one is expecting them to remove the raw font linking that they already have, but they have certainly backed away from it as a viable interoperable format, mainly because both font makers and Microsoft have said that they find it an unacceptable risk to font IP. The point I am making above is that even with the proposed limit to fonts with installable embedding bits, the active encouragement of raw font linking increases the risk to font IP. If you want to protect font IP on the web, the easiest way to do so is to avoid a mechanism that takes TTFs and OTFs and gives them away to every visitor to a webpage. Trying to limit that mechanism on one browser to fonts with a specific fsType bit setting doesn't seem to me worthwhile, because a) it encourages use of a format that other browsers will not limit and b) just makes your browser seem less capable than those other browsers to the average user.

In addition given browser upgrade cycles it could be years before WOFF support reaches even half the browser install base.

Which is a very good argument in favour of CWT (EOTL as was). Which I have been saying since June, despite my misgivings about the format and my preference for WOFF. CWT needs to be taken seriously, by font vendors, web authors and browsers, because it does provide a broadly compatible interim web font format.

Raw font linking won't be taken seriously by most commercial font vendors, excepting insofar as some measures of server-side obfuscation are acceptable to some. Since an IE implementation of raw font linking limited to free and open source fonts with installable embedding is not practically compatible with the non-restricted implementations of the other browsers, i.e. web authors won't be able to use the same fonts reliably across browsers unless they are free or open source fonts, it does nothing to solve web font interoperability in a way that is meaningful to professionals. As MST demonstrated last year, with Ascender's help, most free fonts are not worth what one pays for them.

Si: The “URL-binding = font embedding” discussion with the foundries took place ahead of this press release which also lists out the long list of “supporters”.

Thanks, this is helpful information. You see, I presume, how a discussion that took place more than a dozen years ago, and didn't involve many of the people now engaged in making fonts and discussing web fonts, and whose equation of ‘URL-binding = font embedding’ doesn't seem to be documented anywhere, might not be the best source of information for the current discussion. I'm not trying to be difficult, only to determine who thinks what and why, since clearly people have different interpretations of what embedding means. It would be really, really nice though, if ‘the OpenType spec’s definition of document font embedding’ were actually included in the OpenType spec!

Thanks for these comments. Will pass them back to the IE team.

Cheers, Si

"we would like to see WOFF supporters and other foundries start licensing fonts in the format before we jump on board"
Looks like a chicken and egg scenario.

"same-domain linking" is enabled by default in FireFox and Opera from what I have experienced. There is also a condition to disable this in .htaccess files for font servers. Webkit based browsers ignore this for now.

I am so sick of all these different formats. Using browser detection and redirects at least I can bypass the format wars and serve IE the proper EOT files and other browsers raw fonts keeping my css down to a single rule. However it would be great if everyone came to one conclusion.

*tracking*

>Looks like a chicken and egg scenario.

In a way, yes. But as noted "if you build it they will come" didn't work out so well for EOT, even with IE having 90%+ market share.

>I am so sick of all these different formats.

According to Wikipedia something like 25% of web users are using IE6 and Windows XP. So unless the other browsers start supporting an EOT compatible format you'll need to continue to serve multiple formats for the foreseeable future. That doesn’t seem to be on the cards. In addition although we might see convergence around WOFF within the next decade, I doubt we'll see any convergence around font rendering across all the devices, displays, OSs and browsers. So to get the best results you'll likely need to serve multiple fonts, even if they're all WOFF.

Si: In a way, yes. But as noted “if you build it they will come” didn’t work out so well for EOT, even with IE having 90%+ market share.

I think a lot of font makers lost interest in web fonts around the time that IE went with EOT and Netscape went with TrueDoc. It seemed clear at that point that there wasn't going to be a unified font format, and the fact that IE subsequently ended up with such a huge share of the browser market didn't seem to affect the perception, repeated by just about every Net analyst and journalist, that web typography was something that would have to wait. Also, EOT, contra TrueDoc, was seen as a salvo in the browser war, and once the war was effectively won Microsoft's own enthusiasm for EOT seemed to largely disappear until early this year. Partly this is doubtless Microsoft's perennial problem of poor evangelisation (of which WPF is the latest victim), but it also looked like a lack of interest in the weapons once the battle was won.

EOT was also badly positioned in terms of providing or even suggesting to font vendors a viable business model. Microsoft rolled out a tool that enabled end users to make EOT fonts from existing TTFs, and I think a lot of font vendors were left scratching their heads wondering how to monetise this arrangement. It is telling that this time around a lot of the discussion among font vendors has been focused very much on how to monetise web fonts, and also telling that end user format conversion is very much not part of the emerging picture.

Further, EOT was not a publicly specified format until earlier this year, leaving a lot of questions among font makers about how or whether it might be implemented in other non-IE browsers, as well as how to build EOT into foundries' creation, QA and delivery workflows. These are both key factors in the shaping of the WOFF format.

Finally, as it turned out, Microsoft's own EOT implementation is buggy. It doesn't work with CFF OpenType fonts, and the IE @font-face implementation fails to support font family style linking correctly.

I think there are a lot of reasons why font makers didn't rush to embrace EOT. Once again, I'll point out that the crucial difference that EOT was a technology that Microsoft wanted to give to font makers, while WOFF is a technology that font makers want to give to Microsoft.

CWT needs to be taken seriously, by font vendors, web authors and browsers, because it does provide a broadly compatible interim web font format.

Where can we read more about CWT?

CWT -- Compatibility Web Type -- is the new name for the format put forward by Ascender Corp. as EOTL (EOT Lite). A new name was recommended by participants on the W3C font list in order to remove confusion about what browsers supporting the new format should do when encountering ‘classic’ EOT fonts.

The purpose of CWT is to provide a format that is compatible with existing EOT font support in Internet Explorer versions 6–8 (hence ‘compatibility’), while avoiding those aspects of EOT that were rejected by the non-IE browser makers. The CWT format does not use URL binding, which was the major objection to EOT from the browser makers, since this mechanism was viewed as a form of DRM.

I believe a formal spec for CWT is in development, based on discussions on the W3C list.

The obvious benefit of CWT is that it makes it possible to license and ship web fonts that work on the majority of browsers now in use, including the significant install base of IE6. However, due to bugs in the IE 6–8 EOT support on which CWT would rely in those browsers, there will likely be a distinction between the CWT format spec as it would be implemented by future browsers, and specific recommendations for making fonts that will work with IE 6–8 (e.g. TTF only). In other words, a CWT font built to be compatible with IE 6–8 would also work with new CWT implementations in future browsers, but a CWT font built to spec might not work in those older browsers. Make sense?

John, if you’re interested in the history of this subject I can certainly provide you with the actual series of events with accurate dates - for example the date on the current EOT specification is March 2008 (contradicting your "early this year" claim).

Today there are three browsers that support raw fonts, one that supports EOT and none that support WOFF. I would imagine IE is not alone in thinking about WOFF support and I don’t think it’s unreasonable for browser makers including IE to want to see if font makers are serious about supporting it.

http://www.w3.org/Submission/EOT/
http://www.ascendercorp.com/info/eot-lite-wrap-tool/

Sorry, yes I meant early in 2008, not 2009. Still more than a decade after EOT was first rolled out. My point is that, between the demise of Netscape and Opera's introduction of raw font linking, Microsoft's own interest in EOT seemed lukewarm. The fact that the actual implementation in IE has been buggy for all that time seems to say something about how seriously EOT was taken both inside about outside MS.

I would imagine IE is not alone in thinking about WOFF support...

Mozilla are past the thinking about it stage and have already committed to supporting WOFF in Firefox 3.6.

Let me state very clearly that I hope non-IE browsers will take the step of supporting CWT, and hence provide an at least partially backwards compatible interim solution to web fonts, as this will make things easier for web authors in the immediate future. But enthusiasm for this format among commercial font foundries is pretty limited: some of the bigger companies are interested, but most of the independents are not. So I think there is a genuine chicken and egg situation for CWT in that only increased browser support and a considerable user base will overcome the reluctance of many font makers to engage with that format.

Enthusiasm for WOFF is already pretty high among font makers, but as the experience of EOT shows, no web font format is going to take off without multi-browser support. Looking to font vendors to start actively licensing and shipping for a format before it is supported in more than one browser is putting the cart before the horse. Some of these people got burned by GX, remember, and they're wary about touching anything that isn't supported by at least two major entities. A commitment from MS to support WOFF in IE 9 would go a long way toward turning today's enthusiasm into shipping fonts. Otherwise we're still in the late ’90s and IE is supporting one format and Netscape's children are supporting another and the font makers are going to sit it out again. The ball really is in the browser makers court: the uncertainty isn't being generated by the font makers. We'll support the format(s) that a) do not involve giving away our font IP to every visitor to a website, and b) are supported on two or more major browsers (and, frankly, there are only three major browsers: IE, Firefox and Safari, with the latter having an artificially high significance relative to market share).

Ideally, I'd like to see MS and Mozilla mutually commit to support both CWT and WOFF, so that font makers and users know where we are going both now and in the years ahead.

>>Looks like a chicken and egg scenario.

Having sped on by this issue and assumed we will support whatever-the-frig-formats our customers need, I assure this is not 'the' chicken and egg situation. So with all due support for all but EOT, thanks to Simon for this superb review and for his courage and vigor as an OS developer to show up and discuss these issues in real face time.

We will be supporting all of these formats for the foreseeable future. I disagree with John that any burning occurred with GX (please cite examples), or will occur with web formats since support of them is no more than a simple translation. Further, I don't understand why John continues to cite IP as an issue with any font format on the web.

Good luck, and please be sure, in the end, that EOT is distinguished from CWT in the demands put on the font for document embedding bits. As Simon says, they must be two different formats, and if the improvement is still demanding us to lie, (i.e. need to set embedding bits in order to enable linking), we will reject it, as strongly as imaginable.

Cheers!

please cite examples

Go talk to Tom Caldwell or Bruno Steinert about Linotype's GX experience. I consider investing a lot of time and money in a product that you can't sell as being burned.

I didn't say that people would be burned by web fonts -- I agree with you that these are simple translation matters --, but was pointing out that there are historical reasons why font developers might be cautious about flying the flag for as-yet-unsupported font formats. They were similarly cautious about OpenType, and I think Adobe's involvement tipped the balance for a lot of people, because that meant it wouldn't be a Windows-only format. Similarly, font vendors are looking for multi-browser support for web font formats. And while you might think it foolish, the simple fact is that most font vendors do not like the idea of raw font linking because they consider it an unacceptable risk.

As Simon says, they must be two different formats...

Simon says that? Where? Funny, I thought I was the one saying that, the one writing analysis and reccomendations re. use of embedding bits in web fonts to ensure that your concerns are addressed, the one suggesting a change of name for EOTL to clearly differentiate it from EOT.

Cheers!

David: ...if the improvement is still demanding us to lie, (i.e. need to set embedding bits in order to enable linking), we will reject it, as strongly as imaginable.

See my comments above re. making CWT fonts that are actually compatible with existing EOT support in IE. No one has yet documented all the dependencies -- although Tal and Karsten have started --, and I'm not sure what it might be necessary to do with embedding bits in the CWT header in order to make fonts work with IE 6–8. In the formal CWT spec, I suspect these parts of the header will be treated as padding, i.e. new CWT browser support will ignore them, but existing IE implementations won't. So that is a potential problem.

And now MS are talking about possible raw font linking but with the requirement that embedding bits be set to installable.

So as far as ‘supporting whatever-the-frig-formats your customers need’ you may be looking at both backwards IE-compatible CWT and forwards IE-compatible raw font linking that require you to ‘lie (i.e. need to set embedding bits in order to enable linking)’.

WOFF looking good yet?

JH>"And why, for ten years, did EOT go nowhere? Primarily because it only worked on one browser."

[Forgive my interruption, I have no skin in the game, I know, but why start another thread...]
John, it's not so. There was a time when IE had 90%+ of the browser market. For all practical purposes there was no "other browser". This situation lasted for years. Bandwidth was the main problem. File size was a deal-killer. It was a dial-up world then. Also, there were so many other, and much bigger problems to solve with web technology that choice of fonts was looked upon as a nicety (and a complication)that could wait its turn.
Its turn has finally come, that's all. The planets have finally aligned.

JH>"Enthusiasm for WOFF is already pretty high among font makers, but as the experience of EOT shows, no web font format is going to take off without multi-browser support. Looking to font vendors to start actively licensing and shipping for a format before it is supported in more than one browser is putting the cart before the horse."

This is a wrong, wrong assumption, and it's being shown as wrong with each and every page using web fonts created as we speak.
Squaring the circle of different formats is something web devs do before morning coffee. In the overall scheme of things it presents little to no barriers. We enjoy the challenge, and this one isn't even that tough, believe me.
The old hands on the IE team, as web devs themselves, are absolutely aware of this. This argument won't fly because it just isn't true.

JH>"For free and open source fonts, format conversion is barely a hoop. The same sites that make the TTF files available can make the WOFF files available. In neither commercial web font licensing nor in distribution of free and open source fonts is anyone anticipating end-user format conversion. That really is something we’ve moved beyond."

Sorry to cherry pick. Also, IMHO, incorrect - and by end-user do you mean the web page creator?
Receiving pre-processed files is a nice convenience but designers and developers are very, very used to tweaking and optimizing. Sub-setting to further reduce file size being a good example.
A sizeable segment will insist on that freedom. If they don't have it they'll either take the liberty, or pass on buying the font if they think they will run any risk of a hassle by the vendor.

...by end-user do you mean the web page creator?

Yes. End-user of the font in the sense of the person making licensed use of the font (whether commercial or free license) to create something.

A sizeable segment will insist on that freedom. If they don’t have it they’ll either take the liberty, or pass on buying the font if they think they will run any risk of a hassle by the vendor.

Which is their prerogative. Professional designers needing specific fonts will obtain appropriate licenses with font vendors, either off-the-shelf licenses or, if they need something special, through negotiation. This is nothing very new to the professional font market. People who are not willing to purchase appropriate licenses at the market rate should use free fonts.

____

I am about to head off on a business trip, so I won't be contributing more to this thread. In any case, I'm at the point where I will probably start repeating myself. I have tried to express the perception of EOT and its gone-nowhere-ness from font makers, both myself and the colleagues with whom I've exchanged words on the subject of web fonts over the past ten years. I'm quite aware that there are other perceptions -- Microsoft's, or that of web developers -- and that we probably each consider the others' perspective to be flawed or, as you suggest ‘wrong, wrong’. David Berlow has a laser precise reason for rejecting EOT, and I suspect he is right that whatever the historical perceptions the equation of embedding with linking is an untenable one.

____

This made my day:

http://type101.fontbureau.com/archives/474

And I don't think there is really anything else to say.

WebFonts Working Group is approved by W3C!

The announcement went out yesterday to all W3C members, and the public announcement is coming soon to the News section of the W3C website. For detailed information about the group and how to join (if you are interested to participate) please see the announcement on www-font list.

Regards,
Vladimir