OTW sounds nice.
(and way better than third-party hosted javascript thingies.)

druun

"This new format addresses ... the desires of the free font community"? How so?

Dave Crossland

Right, do you know how long it would take for foundries AND browser makers to adopt another format. This is a waste of time. Web fonts are going to happen in a big way within the next 6 months or a year. Your proposal would take years. Which means your energy would be better spent finding ways to work with the technologies we have (as solutions like TypeKit are starting to do). An ideal solution would be great, but we're not going to have an ideal solution to this problem. A solution will be in place (which will give it more momentum than a new solution like yours) and we'll have to make due with that. Let's work on making that solution as good as it can be.

Larry

Although I was the person who first proposed that Microsoft should open up its previously-proprietary EOT solution and present it to the W3C as OpenSource, I have to say that I don't care what the eventual accepted Webfont solution turns out to be, as long as:

1. Font vendors are happy enough with the proposal that they agree to license fonts for Web use.
2. All the browsers support one single standard.

And that's really the acid test for this announcement : Will both font vendors and browsers support it?

This issue needs to get solved. I await the responses with bated breath...

Bill Hill

As someone who's looked into this topic more deeply than most, I support this proposal.
And I mostly agree with Bill Hill but I would reverse the order of his list:
1) All browsers should support one single standard - that's a good thing, period.
2) Some font vendors will be happy enough with this proposal. Others, foolishly - if they want increased sales, that is - will take a wait-and-see approach. Plus, it's very hard for font-vendors to assess this until there's a full-blown implementation. But it IS very similar to EOT. Is EOT OK? If EOT was OK, this is OK.
In the end there will have to be trust. And faith. And the willingness to take a chance and stop fighting a future that's going to happen with or without anyone's "support".

@ bill davis
[Note: I've updated my analysis on <a href="www.readableweb.com/.../">Readable Web</a> to reflect the information you provided on Typophile.]

Richard Fink

Please god, PLEASE, no more new font formats for specific uses! This is the LAST THING WE NEED. You're making life very, very, very difficult - and more expensive - for designers by doing this. Full support of font-face and the other new webfont technologies that have been introduced in the last month or two, and an overhaul of EULAs to allow web use, is all we need.

PLEASE don't make this more complicated than it needs to be. Design should be about simplification - not obfuscation. This serves nobody.

Sam Beninger

@font-face has been in CSS reccomendations for many years and font foundries had ample time to reach a consensus about web fonts years ago. People were patient but finally browser manufacturers and got tired of waiting and started implementing support for linking plain TTF fonts.

To meet the IP concerns of foundries OTW may be better solution than using third party font servers like Typekit (which among other things raise security and privacy issues) - but I'm not convinced we need another font format.

Until OTW support becomes ubiqutous, this would likely mean sites embedding fonts in three formats: EOT for IE; TTF for Safari, Opera, Firefox 3.5+, and the rest; and OTW for as yet unreleased browsers. (There is of course nothing wrong with doing this so long as you stick to fonts with a permissive license.)

I wish instead users could persuade Firefox et al and W3C to look at EOT again - it seems to fulfil most of the requirements of the foundries to protect fonts at least as well as this OTW proposal does; there are already tools to create EOT fonts; and we know that it works. EOT is also already supported by 50%+ of client browsers out there.

It should be easy enough to make the URL binding optional, not a requirement; and do EOT fonts *have* to use compression? (I'm not sure, but haven't EOT fonts been around longer than Microtype compression?)

Richard writes: All browsers should support one single standard - that's a good thing, period. - just when do you think MS can remove existing support for EOT and other browsers for TTF fonts without upsetting users? Quite a number of non-Latin script web sites in Asia rely heavily on EOT.

Chris F

@chrisf I wish instead users could persuade Firefox et al and W3C to look at EOT again

From Mozilla's point of view, the use of patented technology in EOT is a show-stopper. We cannot make use of any technology which is (known to be) covered by (actively enforced) patents that are not licensed under terms compatible with the GPL. We have expressed this requirement to the EOT patent holders, but they refuse to publish even a proposal for license terms, saying only that if the W3C adopts EOT as a standard, then they will issue a license compatible with the W3C's patent policy. Unfortunately, W3C-policy compliant patent licenses can still be incompatible with the GPL, so that's not good enough for us.

We are also of the opinion that fonts under free-as-in-speech licenses will become more common as time goes by, and we don't want to erect any artificial barriers to their use on the Web; thus we are very unlikely to withdraw support for "raw" TTF and OTF font files in @font-face.

Zack Weinberg

Foundries must just get over it! New format won't help.

People who want to use fonts honestly (or have high-profile sites that can't afford being accused of piracy) will license fonts themselves. For them TTF works and new format only complicates life of those *paying customers*.

MySpace crowd that will copy/hotlink fonts won't pay anyway. If forced to pay, they'll just use some horrible freeware font. New format won't force them into customers.

There's no DRM that stopped pirates. It doens't matter that you can't easily download font off the website, when it's even easier to download huge font packs from pirate bay. If you'll require new fancy format, these font packs will just come with DRM-stripping tool bundled. Extra click needed won't make any pirate paying customer.


So - get over it. You can't force people into paying you. DRM never worked, and only made life of paying customers worse.

asd

Zack, my understanding is that Mozilla will not adopt EOT even if the patented technology is removed (either from the format or if the field of use restriction were lifted). If that's the only problem, then let's get it fixed. I don't think it is.

The reality of this matter is that those who say "just use TTF" don't seem to have thought through what the workflow of this would be for web designers. What, I keep a big spreadsheet of the fonts on my system, and which ones I'm allowed to use?

Personally, I still think EOT should be shaped up (e.g. field-of-use restriction lifted) and used here, if only because 1) it works with fonts that are out there today, and 2) it's already support in IE, and given IE's slow adoption rate, any other solution that's suggested is going to take AT LEAST on the order of three to four years to drop to be adopted by 2/3rds of the web browsing public* (and therefore be usable in a blanket manner on web sites).

That aside, this proposal would seem to address the right set of scenarios - for freeware fonts, you could simply copy the file to your web server; still trying to understand how the same-origin restriction would work in practice, as I expect the generation of these is key for the real world usage scenario.

-Chris Wilson
* do the math - figure it's 2 years until the next version of IE comes out given current track record, and it takes 18 months for IE to convert 50% of its users to a new version (see adoption data from marketshare.hitslink.com). Even if you presume IE continues to drop share at 10% a year, AND IE puts support for the new (as-yet-not-defined) format into their next release, you're looking at 3.5 years to get support and get it deployed to the bulk of IE's market. (This presumes, of course, that other browsers implement it and get it deployed to 100% of their market in that time - then overall support would be 2/3 to 3/4 of the entire public.)

Chris Wilson

@chrisF Richard is right, of course - there's no need to remove support for EOT. They can coexist. But one of the major problems with TTF linking is that you simply can't use it for commercial fonts today, so fonts would be embedded with OTW and EOT, but not TTF (because you can't get the license permissions) - unless the font was proven to be a freely distributable one.

Chris Wilson

One of the sticking points with the EOT format was the root string
mechanism, that's especially clumsy for authoring. What's the same-site
origin mechanism you're proposing here? Roots strings? Or simply
cross-site origin restrictions in the browser?

Seems like if you are obfuscating tagnames in the table directory you
should also be obfuscating the sfnt version too but I guess that's an
implementation detail. Use xor with 0x50475342 maybe? ;)

John Daggett

Would the proposal handle subsetting any differently to how it can already be handled in TTF/OTF? http://fonts.philip.html5.org/ does subsetting by deleting glyphs from the TTF directly, with no need for any new features, and it seems to work fine.

Why do obfuscation by changing table names, rather than something simpler like adding a new 4-byte header? It seems much simpler to implement increment-pointer-by-4-before-passing-to-font-API, rather than having to parse the file and rename tables, and it will have the same effect of preventing use in software that doesn't support the new format.

Or you could add a somewhat larger header that duplicates information from elsewhere in the file, and then you'd have a subset of EOT which avoids the more irritating features (patented compression, stupid encryption, URL restrictions) and still works in IE. You'd still have the same arguments about it being a futile waste of time using this format rather than raw TTF/OTF, but you'd avoid file format proliferation, so it seems a better approach than this new format.

John Daggett: "One of the sticking points with the EOT format was the root string mechanism, that's especially clumsy for authoring." - you can just set the root string to the empty string, and then the font will be usable from any domain. It doesn't seem like a serious sticking point when it's entirely optional (unless I'm misunderstanding the argument!)

Philip Taylor

@Philip Taylor
You can do this for fonts that allow null root strings. For fonts that require an actual root string to be used it's a pain.

John Daggett

Philip, for various reasons we already parse and modify the font tables in memory when loading @font-face fonts, so at least for us implementing Ascender's deobfuscation would be trivial.

Robert O'Callahan

Pingback from awidernet.com

A Wider Net » Marketing Technology » » Blog Archive » Web Fonts – Part 2

awidernet.com

Pingback from thenewmediastudio.com

The hazy future of Web typography | The NewMediaStudio, Custom PHP and MySQL Applications

thenewmediastudio.com