I think the bigger question is how many browser developers would be supportive of the proposal?

I always rather liked .wtf as the format name (web typeface) as referenced in this article: http://talleming.com/2009/04/21/web-fonts/

There's been a number of font proposals for a third format, but none of them have really caught on and I think the browser manufactures have essentially ignored them — Microsoft has EOT already and is happy with it, Firefox & Safari are pushing @font-face without any security. So Darrel's comment is particularly pointed. Foundries are important, but without the browser developer's help, it isn't going anywhere. Even Linotype/Monotype/ITC's updated EULA to allow EOT embedding doesn't seem to have made Firefox or Safari reconsider — at least publicly.

Bill, after reading the proposal, my concern is about "obfuscating" each font by changing the table directory entry. I know very little about type technology, but could someone using FontLab or another type design program just revert the table directory entry to its original setting? If this is possible, then anyone with a type design program (or a demo, or a stolen copy) could download and reformat Web fonts to use on their computers.

This new format addresses the needs of web designers, ...

Web designer just want webfonts and by the end of this year they will be able to deliver them to the majority of users. The web designers don't want URL-binding, obfuscating, same-origin rescriction et cetera. They just don't care about that.

This new format would even mean more trouble for the web designers, because since current browser versions don't support it, web designers would have to link EOT, TT or OTF and(!) the new OTW fonts. Phew!

... the desires of the free font community

In which way?

the concerns of commercial font vendors

I'm not sure about that. It will probably take some years to be included in all the browsers, but since you would publicly announce how the fonts are obfuscated, removing this "protection" will be a piece of cake.

There are five aspects to the proposed web-specific font format:
-Same-origin restrictions

What's the connection between a same-origin restriction and the OTW proposal. This can be included for EOT and TT/OT as well (as done in Firefox). No need for a new format here. And it can also be enforced on the server side (e.g. with .htaccess files)

-Subsetting

EOT/TT/OTF can be subsetted. What's different with OTW?

I always rather liked .wtf
Which most people would probably understand as »What the f***«.

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

This sounds like EOT without encryption or Microsoft. It creates a format that might be more acceptable to the open-source geeks at the W3C who reject EOT on principle, at least until the paranoids at Slashdot decide Ascender is really Microsoft. But I agree with Ralf, nobody needs another font format. If a foundry really wants what is offered here it would make more sense to just get behind Berlow’s permission scheme should it become a reality (unless one is really hung up on subsets).

Which most people would probably understand as »What the f***«.

Exactly. I meant it jokingly since .wtf would be interpreted wrongly.

I'll support this. There's definitely a need for a new format. EOT was almost the one but it didn't catch on for reasons already pointed out in Bill's article.

I don't need a format that prevents the determined and skilled from getting at parts of my fonts. I just want to make sure they can't easily grab perfect copies of my fonts in their entirety directly from a URL. I've always liked EOT and found it to be secure enough. I've seen demonstrations of fonts ripped from EOT and they're okay but there's always something missing: complete kerning, copyright info, family naming, several glyphs. It's not the real font. It's like taping a song off the radio. Subsetting is very important to me.

I played around with EOT about a decade ago and I liked it but the early tools were buggy and there was no Netscape support. I was really disappointed when Safari did the @font-face thing. I want to sell fonts for web use but that was a big step backwards. Every few days I get an email from someone asking me if they can use my fonts for @font-face. I hate saying no, but . . . I don't think people realize that they're really asking, "can I post your fonts on the web with no EULA so anyone with the URL can download a perfect copy?"

I really hope the OTW format takes off. From the description it has exactly what I've been looking for in a new web format.

What about using subsetting? I mean: just like with PDF, embedding a subset font that contains only the glyphs that are actually used. That way, if you try to rip off the font, you hardly ever get a complete font.
The downside would be to know in advance what chars you're going to use, which is no problem for a static page, but might be complicated if your content is pulled from a database.

"If this is possible, then anyone with a type design program (or a demo, or a stolen copy) could download and reformat Web fonts to use on their computers."

"I just want to make sure they can’t easily grab perfect copies of my fonts in their entirety directly from a URL."

Anyone with an internet connection can Google the font and download it from any number of .ru web sites.

No matter how easy browsers may make it to grab an @font-face font file, it's still easier to just google/newsgroup/fileshare for the original full font file.

I think that's the one single hurdle that we need to get over. Fonts are shared already. @font-face may increase sharing. But the goal is to increase sales equally as well.

The problem with 'secure enough' 'protection' is that it's typically a matter of a short amount of time before a simple little app is released that makes it trivial to circumvent with a mouse click, so you are back to square one.

There's an article on ReadableWeb titled Apple and Microsoft In Talks On Web Font Protections that has some informative information about the whole web fonts issue.
Frankly, with all due respect to Bill Davis, I believe that the proposal may not really be a proposal at all, but more like a preview of a fait accompli between Apple and Microsoft.
Check it out.

And with no disrespect to Richard Fink, our proposal has nothing to do with the Microsoft web font collection. Sorry to burst your conspiracy theory bubble… :)

Ascender distributes these fonts under license and would be glad to license them to Apple if they wanted them – we have licensed them to a variety of software & hardware developers.

The Ascender proposal is focused on the vast collection of commercial fonts in the market that web designers cannot use with @font-face to design web sites. I am glad Richard noted Chris Wilson’s comments “A solution that only works for freeware fonts is not a solution. Is that too much to ask?” That clearly summarizes what we hope to achieve: a cross platform, cross browser solution that includes both freeware and commercial fonts.

As Typophile readers may know, Ascender is a supporter of EOT, but this proposal did not achieve the support of the W3C. So here we are today with a plethora of techniques to ‘embed’ fonts into web pages, none of which have achieved the broad support of the web design or font design communities.

Again, I will ask the question (that so far only Ray Larabie has answered):

Who in the commercial type design/font foundry community supports the idea of a .OTW web font format?

Thanks for the background Richard.
This is a complex issue to keep track of, and your article really helps.
I particularly found the minutes of the W3 meeting useful.

It's unfortunate that there is no official body representing the interests of independent foundries, because I am uneasy that all the "foundries" at such meetings represent my interests, as new fonts are not their primary revenue source, although in this instance they probably do.

Bill, a web-specific font format sounds like a no-brainer.
I'll support that!
It would certainly make my business less complicated and easier to manage, which is important when you have a small business with people doing a lot of multi-tasking. It would also make it easier to explain licensing and product availability and feature support to clients and customers.

What about using subsetting?

That might work for a foundry like Vllg or Process that have massive character sets of use to print designers typesetting complex stuff. But many web sites are going to need at least the basic math symbols and the complete alphabet with extended language support things like the names of content authors or users around the world, and for many typefaces that’s everything.

The biggest hurdles to introducing this will be getting the foundries and designers to support another new format, and perhaps biggest of all, the browsers too, which could take a while until the format is widely accepted and used. My gut is that time will be the biggest factor, and it isn't on the side of introducing something new. The next year will be very interesting for webfonts. While the new format might be superior and ideal, I think whatever happens with existing technologies will happen much faster, and if those take hold in a large way, I don't know that something new will have a place.

Speaking as a web designer, I don't care where my fonts come from, either hosted on my site or by a third party. All I want is for the designers and foundries to get paid well for their work and for it to be a sustainable setup. Then we can tackle the problem of most typefaces being bastardized by browser rendering engines at all but display sizes :)

Wait, if I understood correctly, the new format is to obfuscate a couple tables in an otherwise OTF font.
Then, the simplest way to implement that would be to have the system libraries de-obfuscate them, so all apps, browser or not, would support the new format.

Wait, if I understood correctly, the new format is to obfuscate a couple tables in an otherwise OTF font.
Then, the simplest way to implement that would be to have the system libraries de-obfuscate them, so all apps, browser or not, would support the new format.

The point is more that a font that is used online cannot be stolen and used for other purposes. If the system library was responsible for de-obfuscating them, it would essentially be like using raw TTF or OTF files and it defeats the purpose of the new format all together.

"and it defeats the purpose of the new format all together."

True. But it'd also likely be true that in short time there'd be a free app that does the exact same thing.

Indeed, and a fact that many seem to be ignoring. Who are these font pirates that an encrypted format will defeat? Are the various foundries and independent vendors unaware of the rampant bootlegging of fonts that already takes place on BitTorrent and elsewhere?

Well, it is essentially defense against the laziest person. Anyone motivated will get at anything without issue, but a lot of people won't bother to go looking for a decryption program or download the files via a torrent, they'll just shrug and drop the encrypted file in the trash.

It is like those sites that prevent you from directly taking images. If you're motivated enough to take a screenshot and cut it up yourself, you've got your image, but it will stop folk who try to just save image as or drag it from the browser.

In the internet age, DRM only exists as a challenge for someone to break. Someone will figure out a way to reverse-engineer any file format created and create a perfect copy of the original file, but a modicum of security makes foundries feel better that their fonts cannot be outright stolen and will prevent the lowest level users from just taking.

FWIW, here is some reassuring advice to insecure pirates. And have a look at the hundreds of satisfied customers I never knew I had.

@billdavis

I think the proposal is going to take a few days to sink in. I know it will with me. I've read it several times but I still need to sleep on it.
(Please clarify: are you are asking for an up-and-down, take-it-or-leave-it vote? Or will serious and constructive questions and suggestions be entertained?)

One thing that everyone who will be affected by this proposal needs to consider - and it's made pretty clear by the scenario in my post on Readable Web - is whether or not they want to have a little bit of influence on a solution that's likely to be imposed on them by "the big guys" no matter what, or have no influence at all by calling for changes that are unrealistic and haven't the chance of a snowball in hell of being adopted.

Bill, you didn't address the issue directly, but I do hope this is a sincere call for constructive input and not just an attempt to smooth things out over a decision that's already signed, sealed, and delivered.

>"And with no disrespect to Richard Fink, our proposal has nothing to do with the Microsoft web font collection. Sorry to burst your conspiracy theory bubble… :)"

You mean Si Daniels wasn't the second shooter on the grassy knoll? Aw, that's just because he wasn't born yet, probably.
I will note your denial. And personally, I believe you. But I can dream. The browsing public would be a lot better off if Apple did license the ClearType fonts for the Mac OS.

"Well, it is essentially defense against the laziest person"

Which is pointless, as those aren't the type of 'pirates' that are going to be taking any bite out of revenues.

@Paragraph: FWIW, the image you posted is an advertisement. Font piracy on BitTorrent is bad, but not that bad.

Peter, think again please. The screen dumps are from a website offering my fonts for download, today. I just obscured my font names and the website address. Let's not make it too easy, please.

>The browsing public would be a lot better off if Apple did license the ClearType fonts for the Mac OS.

Totally agree! Peter Lofting and co. know my number, as well as Bill's. We're waiting for their call. :-)

Although we've not positioned them as web-fonts.

Cheers, Si

"Anyone with an internet connection can Google the font and download it from any number of .ru web sites."

Don't compare @font-face open linking with those Russian pirate sites. That's what Russian pirate sites are all about . . . people go there to get pirated data. It's right there in the name. What I don't want is everyone's site to feature easy-to-grab, full version, directly downloadable fonts. Just pass the URL to your friends and they can get free fonts, straight off of a legal site. Do you need a tool? No, just this URL and you've got a free font. Let's leave the easy to pirate fonts to torrents, alt-binaries and Russian pirate sites. When you go to these places, you know very well what you're getting into. That's why I don't really care about those places.

I don't know about Russian sites and newsgroup binaries but I've seen the kind of trash available through torrents: old versions of some of my fonts, most of which were released on various magazine cover disks. Most of my fonts aren't available because those collections tend to be out of date. The Top 40 MyFonts collection torrent might seem like such a great deal but what's inside is not what's advertised. Old versions. Fonts converted from other formats. Those torrent font collections are mostly trash. It's not like you get to put exactly the fonts you want into a shopping cart and you'll get exactly what you want.

I'm the guy making the fonts so I'm the one who has to be okay with this. If it's the Safari font-face plan then you can't use any of my fonts on your site. I need obfuscation and subsetting or no go.

I want to support this proposal too, Bill. But I think it will really work only in the case of browser developers (Microsoft, Apple, Google, Mozila) are wanting to follow the same standard, giving support to this new webfont format.

My question is: Is this new webfont format going to be secure enough to prevent a conversion of OTW to OTF/TTF back again?

Whatever the format (EOT or OTW), more embedding bits in the original TTF/ OTF fonts would be nice so that when these web fonts are created - or fonts are embedded in files, whether or not the user actually read the license, they could get a clear indication of exactly what forms of embedding /linking are allowed, and just where this embedding / linking is permitted. The current set of embedding bits are too coarse and generic, being used to cover too many different scenarios.

For a start, separate sets of flags to indicate whether the font can be embedded e.g. in PDF files, in editable (word processor) documents, on web sites, in e-books, (...) - and at what level for each - would be useful.

Of course any browser enabled to download embedded/linked fonts needs to have some easy means of displaying the font the license & copyright fields - and any embedded links to license, designer and vendor in the original TTF / OTF font files -to the client downloading the fonts.

- C

==

"There are five aspects to the proposed web-specific font format:

* Subsetting: This is an important feature for Pan-European and non-Latin fonts which often have large character sets."

How does is this subsetting going to work for complex non-Latin scripts where several contextual glyph substitution lookups may need to be gone through to get from characters in the web pages to final glyphs displayed? Is the utility for creating OTW fonts going to go through & re-write the OpenType lookup tables when subsetting a font?

==

The Ascender OTW proposal doesn't seem to address compression, which EOT has - would it be worthwhile using gzip or some other patent free compression?

- C

"Is the utility for creating OTW fonts going to go through & re-write the OpenType lookup tables when subsetting a font?"

I was wondering about that too. Does EOT already do that?

Typodermic: What I don’t want is everyone’s site to feature easy-to-grab, full version, directly downloadable fonts.

And that's where those webfont services as Webkit come into play. They will deal with URL-obfuscating, hot-linking prevention and so on. So your fonts will be as "secure" as webfonts can be.
And if you don't like to pass your fonts on to those services, you can also setup your own, like foundries as Typotheque are doing it.

outrasfontes:Is this new webfont format going to be secure enough to prevent a conversion of OTW to OTF/TTF back again?

No.

Well, maybe that might work if it's easy to manage. It would have to be picked up by an existing marketplace or become a big enough marketplace in its own right. Right now, I prefer putting the font in the customer's hands because there's a system in place for doing that and it's really good at pulling in large numbers of customers. If fonts.com and myfonts.com made that service available, I don't see any reason I wouldn't jump on board.

Ralf: And that’s where those webfont services as Webkit come into play.

I think you mean TypeKit, not WebKit.

Peter: I misunderstood the situation, please ignore my remarks :)

>There’s an article on ReadableWeb titled Apple and Microsoft In Talks On Web Font Protections that has some informative information about the whole web fonts issue.

How does Apple lic. or MS CT fonts help web designers?

Cheers!

@dberlow

Right now, when you specify a font-family using CSS in a web page, you play a game of probabilities. The question being, how probable is it that a particular font-family exists on the user's machine?
In fact, on another thread here on Typophile named CSS Font Stacks Article, Frode Hellend (frode frank), has put together an excellent table that deals with these probabilities.
Today, web designers can comfortably rely on a handful of "Web Safe" fonts that approach 100% penetration on both Windows and Mac. They can specify these font-families with confidence that what they design will be pretty much what the user sees. These fonts also provide kind of a safety net of "fallback" choices in lengthier "font stacks". (There is much info on the web about this.)
Apple licenses the "web safe" fonts from Microsoft because having a baseline like this from which to work seems to work out as a good thing for all concerned. Apple's customers certainly benefit.
Licensing the ClearType fonts is just an extension of the idea. The CT fonts are excellent. Top quality. They are present in the majority of Windows machines and will inevitably approach 100% propagation among Winows installations as older Windows XP installations without Office 2007, are abandoned. (It's a waiting game of attrition. Like waiting for certain browser versions to disappear. Which is, among web designers, the universal professional pastime.)
With Apple on board, it wouldn't be long before the ClearType fonts could be counted on by web designers with the same degree of confidence as fonts like Georgia or Tahoma. Result: A more readable web.
I'm not alone in the opinion. The article also cites Joe Clark's post on the subject from four years ago. Joe had it right on the money from the start. IMHO.
Is it that costly for Apple to give us this, I wonder?
Or is support for @font-face in Safari an attempted end-run around it? (Stay tuned for part 2 of this saga at readableweb.com)
Ahh, the tangled web we weave!

cheers back,

rich

Richard, you need to translate the question from Berlowese to English...

"How does Apple lic. or MS CT fonts help web designers?"

"How does Apple lic. or MS CT fonts help me sell my fonts to web designers?

That's what Bill's proposal is all about... as I pull the discussion back on-topic.

PS - a separate thread on the C* fonts might help get Apple's attention.

A more readable web.

A handful of conservative designs in a narrow range of styles?
If I were a web designer, what I'd want right now would be slab serif faces, geometric sans faces, ultra thin faces, large x-height faces, &c.
And next year who knows what.
Opening things up commercially will make the web a more vibrant, more readable medium, so that foundries, web designers, and end users all benefit a lot, not just a little, which is what we get with the oligarchy nudging things along.

@nick
This time I agree with you. It is a handful of conservative designs in a narrow range of styles.
But typography on the web is in bad shape, and it will double the existing palette in very short order.
That's its main virtue. And the CT fonts are exceptionally good for body text at smaller sizes - and that seems to be the trickiest and costliest of things to make happen in a screen font.

@sii
>PS - a separate thread on the C* fonts might help get Apple’s attention.
Good idea. And you're right, bringing it up here is OT. I've signed up for an online course in Berlowese. I'll do better in the future.

To bring the debate back: How do font vendors feel about the proposal that is on the table from Ascender?

“How does Apple lic. or MS CT fonts help me sell (FB) fonts to web designers?
We will only be licensing, for the most part. You want to buy some?

"And next year who knows what."
Exactly. Once Adobe ask'd "Who needs more than the 200 fonts [then] in the Adobe Library?" It's the wrong question; clearly few users need more the 200 fonts, but 2 billion users clearly needed more than 200 as the history of dtp showed.

"...it will double the existing palette in very short order."
Far out. Are we to 70 then?

"The CT fonts are excellent. Top quality."
Maybe you're just talking, and not using, composing, rendering and reading these types?

I don't think the same old solution helps anymore and wonder how it got here, (but not to Linux).

To really take it back to topic, I don't think there is a lot of call for any more purely generated font formats.
But, we will support every single one that contains a permissions and recommendations table.

Cheers!

Richard: "CT fonts are exceptionally good for body text at smaller sizes - and that seems to be the trickiest and costliest of things to make happen in a screen font."

At small sizes, the number of possibilities for good original body text faces for the web that can be clearly distinguished from each other must be limited by screen resolution. Even with hi-resolution screens and clever things like CT instructions there must be a finite number of ways you can squeeze the letters of the Latin alphabet into pixels available on screen at small sizes and have them remain pleasing, clear, legible and easy to read -yet distinctive and consistent in style.

Sure you can always tweak round the edges, but to me there seems little point in trying to produce more and more of these "screen fonts" if they are all going to look pretty much the same at the sizes they are used as those we already have.

While there still may be some room left for a few more original and useful screen fonts, are we ever going to need (or be able to differentiate between) more than two or three times the number we already have?

I think you're wrong, but even if you were right about small text size, bear in mind that web fonts are scalable, and both web designers and readers may scale up the size of type to the point where a lot more individuality is apparent.

How do font vendors feel about the proposal that is on the table from Ascender?

I suspect that the lack of response is due to either bafflement with the complexities, or the feeling that whatever we say the issue is in the hands of the powers that be, a fait accompli. Anyone who was at TypeCon last year, and saw the arrogance with which Håkom Lie addressed an audience largely composed of the font industry might also have that impression.

It's all very well to say that the interests of font producers are represented by Microsoft, Apple, and Adobe, but ultimately they are not type foundries, although as you say they bin berry good to us.

Or perhaps not many type designers hanging out at Typophile. But the consensus in this thread seems to support Bill's proposal.

For font resellers, I wonder what Stephen Coles has to say on the position of FSI (both manufacturer and retailer)?

>Anyone who was at TypeCon

'twas at ATypI

OK, now I remember.
Thanks for organizing that panel, Si.

Hi. I'm Thomas Lord who is perhaps known to a few as the author of materials found on noeot.com - materials written when some of us feared that W3C was going to rush to standardize EOT with requirements that root strings (a form of DRM) be enforced by compliant clients.

I kinda like Bill Davis' proposal but I would like to see some improvements and generalizations before I can say that I really support it:

The proposal suggests that consensus might be formed around a standard "web font" file format that is (a) distinct from legacy formats used for restricted-license fonts; (b) supports subsets and patent-free compression; (c) conveys copyright, patent, and other licensing information in a way that client applications are encouraged to use to keep users fully informed about the content.

Stated abstractly like that: I agree with all of those goals.

The proposal further suggests that some non-free fonts might be licensed for web use under terms that require licensees to serve those fonts on the web only using existing "same-origin" restriction mechanisms. Some, in comments above, have questioned how the customers will feel about this. I think it is a fine idea in principle and a good enough idea if the customers in question are willing to work with that.

Here is where the proposal loses me a bit:

The proposal is for a new font format specifically. I think that is not quite right.

The same concerns motivating this proposal for a new font format are shared by makers of non-free image files, video files, audio files, text files, and so forth. That is the first key observation.

The second key observation is that a single solution for all media types is quite viable: a "wrapper file format" that can convey licensing information and, by virtue of changing the byte-stream - differ from legacy formats. That is, we can take existing font formats of all types and wrap them in a format that adds such things as licensing information. The wrapper would be slightly redundant with some features of existing font formats but not by much.

A wrapper format like that can in principle apply to any linked (or "embedded", if that is really a concept) resource. There is nothing "font specific" about it. Clients such as browsers can be modified to recognize and unpack such a wrapper in a generic way - not in font-specific code. And thus we solve similar problems for all media types, all at once.

I think that going that route is actually the best way to persuade not only restricted-license font vendors but also browser makers to adopt. The way to encourage that adoption is to reach out to people interested in other media types (such as music and video) and get them interested as well. For browser implementors, it is a small change to handle this new wrapper format around any media type and to begin to add features to, for example, give users convenient access to licensing information for "embedded" media.

It is difficult (probably impossible) for W3C to accept in one gulp the idea of a wrapper format across all media types - that's a big step for humankind, not a baby step. Yet it is practical to advertise the intent of getting to that point while initially promoting a generic wrapper as a solution specifically for the immediate problem of fonts.

A third key point is that the benefits of such wrappers are not unique to distributors of "non-free" media files. Those of us who produce libre content are also often concerned to see that such things as licensing meta-data is conveyed with the work and that users are informed of that meta-data. A generic wrapper format will help libre causes as much as it will help restricted-licensing interests. Thus, it seems a good centrist position, to me.

Regards,

-t

Excellent idea, Thomas.

@Thomas Lord (dasht)
I find your approach very constructive.
Garnering support has a lot to do with how the issues are framed.

Thomas, foundries and their clients have two distinct concerns with regard to web-linked fonts. The first is unlicensed use of fonts to display online text, which your wrapper proposal addresses. The second is web fonts becoming an open distribution mechanism for unlicensed fonts, i.e. people grabbing web-linked fonts off servers and making use of them in other media such as print design. While browser makers can make the wrapped fonts concept work by only displaying text in either a) linked wrapped fonts or b) fonts on the local system, i.e. not unwrapped linked fonts, do you think the wrapper mechanism can be made robust enough to prevent unwrapping of the font?

Thomas, can you explain to me the distinction you see between

root strings (a form of DRM)

and

“same-origin” restriction mechanisms .... a fine idea in principle

Thanks James, Richard, and John. And John, I owe you some answers! So here:

You ask the difference between "root strings" and "same-origin restrictions". The difference concerns who is enforcing what.

Root strings are the notion that a font file ought to contain meta-data which says "this font is intended only for use to display web pages from legit.example.com" - and the browser is expected to enforce this. In the case of a seemingly unauthorized use of the font, the browser has the font and has a page from illegit.example.com (or from the local disk). The browser is perfectly capable, technologically speaking, of rendering the page using the font - but the root string proposals are that to be conforming to standards, the browser must not render the page.

The problem with root strings is that a user who is already in possession of the page from illegit.example.com and already in possession of the font may be doing something perfectly legal, perhaps even life critical. If the browser refuses to permit this, it has a bug. A W3C recommendation should not require browsers to have bugs, especially bugs that can be harmful in a life-critical situation. I have a slightly longer form of this argument here: http://noeot.com/shoulda-woulda-coulda.html That other version focuses on the sometimes eye-splitting use of formal language in standards, though.

In contrast, the "same origin" restriction works this way: suppose that a properly functioning browser loads a page from illegit.example.com and that page links to a font from legit.example.com. When the browser requests the font for download, the request includes a declaration from the browser: "Hey, server, I would like font X because it is linked from a page on illegit.example.com". If the operator of legit.example.com has configured his server in a certain way, the server will say "I can't give you that font." (If the browser had said "I need this font for a page from legit.example.com" then the server would provide the font. The browser could lie to the server and perhaps get the font, but no standards-conforming browser would do so.)

In the "same origin" scheme, restricted font licenses would require those who use them on the web to configure their servers to enforce same-origin restrictions. "I'm allowed to put this font on the Web but only if I configure my server to not serve it up other than for requests based on links from authorized pages."

Same-origin restrictions are not a bug, in and of themselves. It is important for many reasons that the operators of servers be able to configure their servers to refuse requests for materials linked from certain other sites. There is the possibility that a particular use of same-origin restrictions could be an abuse of that feature and could cause life-critical problems and could be called a bug. Nevertheless, nothing about a recommendation to use same-origin restrictions for some fonts would force people into such abuses and so a W3C recommendation along those lines would not be "mandating a bug".

Your other question is "can wrapping be implemented so as to prevent unwrapping"? That is, can't someone download a wrapped font, unwrap it, and then (assuming the font is restrictively licensed) be in possession of an unauthorized yet fully functional copy of the font?

No, my proposal can not prevent unwrapping fonts that way. I don't think that that property is unique to my proposal, though: all web font proposals (including the original EOT strawman) share the same property.

I think this is as much as anyone can hope for: "unwrapping" a font in that way requires one of two things. On the one hand, "unwrapping" may happen because a user knows, or ought to know that they are circumventing copyright and licensing restrictions. On the other hand, "unwrapping" may happen because a user innocently uses a software feature that was designed to circumvent copyright protection. In the first case, culpability is easier to attribute to the user after the fact. In the second case, culpability can be attributed to the author of the program the innocent user used.

Unwrapping, origin restrictions, and so forth are always going to be "leaky" solutions. That is a fact of the nature of the technology.

I think that what font vendors interested in restricted licensing have to be aware of and thoughtful about is the "RIAA trap". If the vendors hope ultimately to track down and stop every violator of their licenses they will certainly wind up reaching levels of absurdity, bad behavior, and ill repute like those of some in the music publishing industry. The basic reality is that unauthorized use of fonts happens, will happen more in the future, and stopping it is not only impossible but damaging to those who work to hard at trying.

Rather, I think the vendors need to concentrate on mechanisms that help keep honest and lawful players lawful and honest.

The idea of a wrapper format for all media types helps to create a medium in which honest players conveniently and automatically receive, perceive, preserve, and propagate licensing information as they obtain, use, and further distribute fonts. The idea is to simply keep honest players fully informed and let them make their own choices, using a simple, effective, and simple technological solution.

-t

@Richard:Please clarify: are you are asking for an up-and-down, take-it-or-leave-it vote? Or will serious and constructive questions and suggestions be entertained?
We would prefer to hear a vote for and against - and for those who don't like it, why not? So yes, we would like comments/suggestions. This discussion has been going on for some time, and with raw TTF and OTF support being added by browsers, we believe this issue is quickly gaining urgency. Thus the time for discussion needs evolve into time for action.

And thanks for driving home the question poised to everyone in the font community reading this - what do you think of the proposal?

@Outrasfonts:My question is: Is this new webfont format going to be secure enough to prevent a conversion of OTW to OTF/TTF back again?
No. The best analogy is one others have use that OTW is a small fence to prevent people from walking into your property. It is not a tall barbed wire fence with security cameras. Because the OTW spec will be publicly available, and certainly tools and/or SDKs will be published to help developers implement OTW, someone could easily write a program for end-users to convert OTW fonts back to TTF/OTF.

But what OTW does accomplish is clearly communicate that the font is intended for web use, vs. TTF and OTF which have been licensed for years by commercial font vendors for desktop use only.

@cfynn: Is the utility for creating OTW fonts going to go through & re-write the OpenType lookup tables when subsetting a font?
The best way to answer this is to consider how EOT subsets fonts. WEFT does not change the order of glyph IDs when subsetting a font. The OpenType Layout tables are not re-written. But the data for the glyphs IDs that are not part of the subset are removed.

@Thomas Lord: Thanks for your comments and suggestions. As I stated above, my hope is that we can get some momentum building here around a solution for web fonts.

@John: This difference just came up today on the W3C www-style mailing list: Same-origin restrictions are not the same as root strings; the latter are a way to label the website(s) which the font has been licensed for, and require browsers to not render the font if the URL is not on the label. One effect of this is that other sites can not "cross link" to your site's fonts - a same-origin restriction. But a same origin restriction can be put in place without any information in the fonts; its just a standard feature of web servers and web browsers, useful for lots of different kinds of web assets, such as Javascript files (where http://en.wikipedia.org/wiki/Cross-site_scripting is a security issue.)

How do font vendors feel about the proposal that is on the table from Ascender?

My personal reaction to it is that it seems to address the significant issues that Adobe is concerned with. (But since Adobe and Monotype and many others were already in agreement about EOT, this will not be news to Bill.)

for now, I am following the discussion with interest. Bill, thanks for keeping this issue on the front burner.

@Chris: since Adobe and Monotype and many others were already in agreement about EOT, this will not be news - But since EOT is starkly different to Ascender's proposal, this is indeed somewhat news (although clearly just your personal view.)

But since EOT is starkly different to Ascender’s proposal ...

I would not characterize the differences as "stark", but I know what you mean.

@billdavis and all...

Compression And Reduction Of File Sizes
I am confused/concerned about this only. As will be many web developers. Sub-setting, of course, can reduce the file size drastically. However, I've yet to get a definitive answer about compression. I have it from Thomas Phinney that OTF CFF provides a high degree of compression on it's own. But can it be improved? Also, TTF's are going to be around for a long while. One of the virtues of EOT is that it does quite well at compressing TTF's down to conscionable levels.
Even when sub-setted, calling a font-family's regular, italic, and bold faces takes three separate calls to the server. That, plus the size of each OTF can easily make web authors very, very leery. Every extra second of download time can cost you visitors.
Yes, it's possible a standard compression mechanism like gzip can be brought into play. But that's very much a "server side" thing that many authors have no familiarity with. Plus, many if not most, don't have access to the server configuration files required to make that happen.
Much better the OTW file itself be as small as possible.

I don't have any skin in this game right now except as an informed commentator on Readable Web where I'll be following closely the successes and failures as font-linking is actually deployed. (Wink: Might be worth an RSS feed.)

I vote yes, go for it, and don't let go. In my humble opinion, developers aren't going to be too happy 24 months from now. Bloated pages with little to show for it.

This is going to be a long show. There will be an intermission AND a 2nd act. But at least, finally, the curtain is going up.

Thanks for the detailed explanation of the difference between root strings and same origin restrictions, Thomas. While I think the case against root strings is overstated and ignores the variety of fallback mechanisms that can kick in if a font cannot legitimately be served, I agree that the same origin restriction mechanism looks more appealing.

Unwrapping, origin restrictions, and so forth are always going to be “leaky” solutions.

I guess this to be the case, but wanted to see it plainly stated in the context of this discussion. Thanks.

I think that what font vendors interested in restricted licensing have to be aware of....

For me, this isn't so much a matter of being a font vendor interested in restricted licensing, but of being a maker of custom fonts whose clients are interested in protecting their investment. They want to use their custom typefaces on their websites, but not compromise the exclusivity that is a core value of the investment.

Whatever the merits of EOT, its time has come and gone.
Several formats once seemed promising, e.g. Multiple Master, GX.
So OTW stands a better chance now.
Although it does seem a bit close to the suffix ".otf"--that might be confusing.

I have a hard time understanding all the technicalities about "embedding bits" etc.
I would like to be able to make ".otw" fonts for web licensing, with FontLab.
If OTW could be added to the short list of font formats in the Fontlab "Generate font" dialog, that would open up the market for foundries.
And similarly, it would appear as an option at font reseller sites.

We really do need a specific format with suffix, otherwise customers will be wondering whether the .otf or .ttf fonts they have licensed may be used on the web or not, and they are not going to go looking in the EULA.

So I can see myself licensing an enterprise font solution to a corporation, that contains both .otf and .otw versions of the same font, so they are covered for both web and print use.

Richard, this blurb from an Adobe type FAQ helps a little:

All OpenType fonts with PostScript outlines (.otf) use Compact Font Format (CFF, or Type 2) for considerable size reduction. Although CFF is not strictly compression, since the outlines do not have to be decompressed to be rendered, the result is still more compact than Type 1. Adobe’s OpenType fonts also use subroutinization for additional size reduction. OpenType fonts with TrueType outlines (.ttf) have the option of using compression technology licensed by Microsoft.

It seems we might have specific numbers somewhere, but I'll have to look around. Can it be improved? I don't really know the answer, but my gut feeling is that -- like other lossless compression like TIFF or FLAC -- it's probably about as compressed as it's going to get. As Thomas pointed out, there is some benefit to compressing the layout tables, especially when they're large, but you'll probably find that ZIP-ing CFF-OTFs doesn't do too much.

For me, this isn’t so much a matter of being a font vendor interested in restricted licensing, but of being a maker of custom fonts whose clients are interested in protecting their investment. They want to use their custom typefaces on their websites, but not compromise the exclusivity that is a core value of the investment.

John, that's a great point! Thanks for mentioning it.

(I think Bill's proposal is reasonable enough, but the question is what the people representing font vendors and browser makers think.)

Nick Shinn wrote: Thanks for organizing that panel, Si.

That was me, actually. I was happy to get Håkon Lie (Opera, CSS, driving force behind @font-face popularization) and Bert Bos (W3C) on the panel for the discussion at ATypI. I think it was effective at exposing underlying philosophical differences between Lie and the type community, of which there are several.

Rich wrote: Is it that costly for Apple to give us this, I wonder?
Or is support for @font-face in Safari an attempted end-run around it?

Neither. The fundamental thing is that Apple already offers lots of fonts, and doing something that makes the Mac more like Windows, costs money, and doesn't really do anything dramatic for the Web is not likely of interest to Apple.

(Contrary to what you say, I don't think that adding just another half dozen typefaces in four styles each to the "web safe" set would be such a huge improvement. Nice to have, but not huge. If I were Apple, I wouldn't be beating down Microsoft or Ascender's door, either.)

Cheers,

T

Sorry Thomas, thank you!

philosophical

Political, more like.
This is philosophy: Stakeholders are "consulted", and then the powers that be go ahead and do what they were going to do anyway.

Thanks for the clear answer, Bill.

I agree that having a different format for web use seems to be easier for the font user/purchaser to understand wich one is good for desktop use and wich one is suitable for web purposes. This seems to be a user friendly thought.

@Richard re: Compression and reduction of file sizes

… OTF CFF provides a high degree of compression on it’s own. But can it be improved?

CFF outlines are much more compact than PostScript Type 1; however the differences in size between TTF and OTF are primarily due to the way how outlines are encoded. TTF employs a drastically different hinting mechanism; TTF fonts that are optimized for screen use can easily be twice the size of the same font in OTF format because of the amount of additional hinting code that went into it to make it optimized for screen use – the difference isn’t just due to compression.

Can OTF size be improved?
Yes, it can. I ran a quick and simple experiment with one of the Monotype fonts – same typeface that is represented in TTF font format uses 66 KB of data, and the OTF font file size is 30 KB (again, mostly due to differences in outline representation and hinting). Compressed OTF (using WinZIP) brought the file size down to 18 KB. I also tried Adobe MinionPro (regular) – OTF size=201 KB, WinZIP=130 KB.

One of the virtues of EOT is that it does quite well at compressing TTF’s down to conscionable levels.

Yes, it does. MTX compression (which is part of EOT, http://www.w3.org/Submission/2008/SUBM-MTX-20080305/) is a two-step process – first stage converts TTF file to minimize/eliminate the redundancy in font data and to subdivide it in separate data blocks that are likely to have similar (repetitive) data patterns; these are likely to produce better compression results when entropy coding is applied at the second stage. The decompressor reverses the process and re-creates TTF font from the compressed dataset. I ran a quick and simple test using WinZIP (at maximum compression level), WEFT and Windows fonts Times NR, Arial, Georgia and Verdana with no subsetting. Here are the results (in KB):
[font] [uncompressed] [WinZIP] [WEFT]
Times NR 316 181 142
Arial 267 148 113
Georgia 140 90 67
Verdana 137 81 59

As can be seen, ZIP file size is on average ~30% larger than EOT size. Please note that OTF fonts share the same table structure as TTF fonts – the only difference between them are TTF and CFF outline tables. Therefore, MTX compression can be easily modified to be applied for OTF fonts - separately compress CFF table and apply the same optimization and compression algorithm for all other tables in a font. I am confident that the OTF compression results will be better with MTX than with generic ZIP.

… Much better the OTW file itself be as small as possible
Yes, I agree. Ascender proposal addresses only a light-weight obfuscation part of the overall solution – but if combined with the same-origin restrictions (e.g. CORS) and efficient compression it would become a viable alternative to EOT solution.

Vlad

Great additions thanks!

>A W3C recommendation should not require browsers to have bugs, especially bugs that can be harmful in a life-critical situation

Since permissions and their conditions are up to this industry, and we are not actually making life-critical typographic decisions, I see both “root strings” and “same-origin restrictions” should be part of any comprehensive font permissions solution. What, users, developers, user agents and recommendations bodies do about these permissions and conditions, including root string and same-origin restriction permissions in the fonts, is up to them.

> what OTW does accomplish is clearly communicate that the font is intended for web use

...though not so fast. ;)

Cheers!

John (Mr. Hudson), you wrote: "They want to use their custom typefaces on their websites, but not compromise the exclusivity that is a core value of the investment."

I agree with Christopher Slye that that's an excellent point. The web does a very good job of messing up the traditional boundaries between "performance" of a work and "distribution" of the work. From what little I'm beginning to understand about font maker history this isn't exactly new (e.g, Zapf copies) but the web raises the stakes to a whole new level.

Hopefully without being too discursive I would note that other media are facing similar problems. Newspaper content migrates to blogs and search engines which become the primary means of consumption, often depriving the makers of revenue. Music recordings suffer similarly. Video content has the same problems. All of those other industries have been thrashing, for years, in search of a solution to the loss of traditional money-making models. The battles have reached absurd extremes - for example, the "net neutrality" debate in legislatures and regulatory offices around the world are fueled, in no small extent, by motivations and suspicions of motivations about various parties trying claw back a more traditional notion of walled-garden "performance" of works on the web as distinct from distribution. The very concept of "DRM" comes from the same efforts.

Font makers have a rough road ahead. I guess that's another thing everyone knows but that is worth saying out loud - putting it plainly and frankly on the table. The problem is that digital fonts are "naturally" (that is, technologically) non-rival. Copies inevitably propagate. Mediation in the form of regulation and law enforcement is not absolutely pointless but, to a first approximation, is quite pointless. (That's "pointless" in the sense of "not going to work".)

What does work, I think, is concentrating on the commercial world - on commercial uses of fonts as contrasted with private or personal use. The law still functions, almost even slightly efficiently in that area. For example:

Suppose that we have a font whose public licensing information states "no commercial use without consent". Well, even if a million random bloggers use the font on their non-commercial pages, still, Amazon won't use it on Kindle absent consent (or if they do they can be called to account and they'll settle quickly). You won't see the font on Google's home page unless an arrangement has been made. And if you spot it on some paid advertisement from an unauthorized third party - it's easy enough to bring an action against the advertiser, even it's a dinky "Joe's Bait, Tackle, and Beer Shoppe". Where there are legal revenue streams attached to the use of a font, there is still the chance of enforcing restrictions.

The commercial world, with its formalities, is the place where exclusivity can still reign. And I say that as a big proponent of libre fonts!

Now there are some challenges for the font industry - challenges the video and audio industries have been wrestling with for a few years. Key among these is "private policing".

"Private policing" is the activity of privately paying up front for snoops to go and find, on the big Internet, instances of unauthorized commercial use of copyrighted material. To give you some sense of how far that game is advanced in audio and video recordings: there is a substantial market for software programs that do things like study all of the videos on YouTube to "listen" for cases of soundtracks that make unauthorized use of restricted-license song recordings. So if, say, the group Metallica complains that one of their songs is being used in impermissible ways on YouTube, one of these programs can go and automagically find all the videos that seem to use that song and flag them for review and/or removal.

I think that fonts are going to have to go a similar direction. The already wide-spread unauthorized use of restricted-license fonts will grow but there is still opportunity to constrain commercial use of fonts. That opportunity, however, requires a private investment in policing and that investment requires careful thought about costs and benefits.

To bring this full circle (and thanks for reading this far, if you have): the "wrapper format" refinement or counter-proposal or however you wish to describe it... the essence is to foreclose the purely innocent but unauthorized conveyance of fonts by creating a uniform and ubiquitous mechanism for, by default, always conveying licensing information along with fonts. Whether you are in the legal game to protect the status of your libre font or in the game to protect your restricted license you have a hook to hang your hat on if you find a use of your font that either lacks the wrapped licensing information or is a use in violation of that licensing information.

I think that that's as much as you can hope for in the digital wonderland / Internet age but I also think it's not such a bad arrangement. My hope is to see it come to pass for fonts quickly, simply, and agreeably to all stakeholders.

One last thing:

I think that there is hope beyond "exclusivity" in this way:

"Design" taken in a very broad sense is inherently rival, even on the web. The design of a web presentation is a situated thing, not a file that can be copied. Fonts are an element of design. Thus, I foresee a future in which there is a much larger emphasis on bespoke font design as an element of larger design projects. The downside here is loss of royalties - loss of premium fees. There will be talented font makers who agree to work, basically, for an hourly rate to create non-rival or less-rival fonts and they will come to dominate the market. The "font publisher" industry will dry up but individual font-makers can still make a living. A few real super-stars can make a handsome living. At least by analogy, that's the pattern taking place in the software development world and I don't see any essential difference between that and the font world that would prevent the pattern from repeating itself. So perhaps the thing to do is embrace that and work on preparing for it....

-t

“They want to use their custom typefaces on their websites, but not compromise the exclusivity that is a core value of the investment.”

Yes obviously — we started with this idea more than a couple of years ago, but it's got legs limited by a small number interested in proprietary font exclusivity (founders and custom font IP owners).

More broadly, we think 'they' want to use 'their' combinations of faces, proprietary or not, that (along with other more and less unique elements like logo and colors) give them a unique visual ID. This is the core value, the entity ID, not the font(s).

This brings the numbers of potentially interested parties up into the 100's of millions, but also brings the need for rigorous policing of extensively detailed permissions on the part of all kinds of font IP owners.

And it's hard to imagine, just another wrapper, alone, fixing visual identity theft. ;)

Cheers!

@Vlad
Thank you for the analysis on compression.
I can't remember where I saw it, but someone commented that MTX compression is under Patent and either can't be freed up or won't be freed up by Monotype in a manner suitable to the W3C guidelines so as to be included in a spec, should it come to that.
True? Is that commenter correct? What's the story?

@Thomas Phinney
>"(Contrary to what you say, I don’t think that adding just another half dozen typefaces in four styles each to the “web safe” set would be such a huge improvement. Nice to have, but not huge. If I were Apple, I wouldn’t be beating down Microsoft or Ascender’s door, either.)"

There is only one "web safe" serif font that looks any good for body text: Georgia. You're looking at it right now. That's it. One. (If anybody wants to argue for Times New Roman as a good screen font, go ahead, please.)
Grilled cheese for lunch again, day after day after day.
Cambria or Constantia would be a nice change, yes. Even if only on Wednesdays.

Anyway, my mantra....

How do font makers feel about Ascender's proposal?

As a talentless hack who will never release any font of note, I think the idea is a good one. The discussion here demonstrates that there really isn't any workable solution which will make everyone happy. Such is reality in a Web 2.0 era. End users expect all sorts of customizations. Wasn't everyone much happier with gopher and lynx?

@Richard
... someone commented that MTX compression is under Patent and either can’t be freed up or won’t be freed up by Monotype in a manner suitable to the W3C guidelines so as to be included in a spec, should it come to that.
True? Is that commenter correct?

Nothing can be further from the truth!
MTX is a patented technology, however, Monotype Imaging has disclosed this fact and, as a member of W3C, made a commitment to make the IP availbale under W3C Royalty-free policy. These statements are included as part of the original EOT submission: http://www.w3.org/Submission/2008/01/

Mozilla complained that the W3C patent policy has a provision known as a "field of use restriction" that makes it incompatible with some open-source licenses. This issue has also been recently clarified, see http://lists.w3.org/Archives/Public/www-style/2009Jun/0228.html

Regards,
Vlad

@Vlad

Thanks for clearing this up. Sounds like another roadblock cleared. (I hope.)
I have been asked to write an article about Ascender's proposal and the status of web-fonts in general for Web Directions which has a wide following in the web design community. Especially among designers who are standards-aware. I'll incorporate this into the article.
I'm very curious to see who else thinks a web-font file format should be intrinsically compressed, independent of any additional processing. Compression as a second step is inherently less efficient, for most, probably inconvenient, and is, in many cases, simply beyond the author's authority to implement on the web server.

rich

>http://lists.w3.org/Archives/Public/www-style/2009Jun/0228.html
>The problem can easily be solved by deploying a font wrapper like EOT that simply reduces the risk of font piracy.

Vlad, can you please list the main steps from where we are, to where EOT is deployed to all? e.g. "step X = all user environments are upgraded to include EOT unpacking software" Or provide a link to same?

Also, can you list exactly the risk reduction afforded by this technology? When is the "raw" font more vulnerable to piracy than an EOT font? When is an EOT font more protected from piracy than a "raw" font?

Cheers!

@dberlow

>Also, can you list exactly the risk reduction afforded by
>this technology? When is the “raw” font more vulnerable to
>piracy than an EOT font? When is an EOT font more
>protected from piracy than a “raw” font?

Oh, come on, man. When I crack an egg, drop it into the frying pan and begin to stir, at what point, precisely, does it actually become "scrambled"?

My problem is, David, I can't tell whether you're being facetious or not. My class in Berlowese doesn't start until the fall semester.

Either way:

Go ahead, don't make decisions. Play around. End up with nothing. Not even the satisfaction of having done the best you could with the hand you were dealt.

The rise of the Internet is the greatest technological and societal change any of us has ever seen or will ever see in our lifetime. Contribute to it, deal with it, or get trampled. Those are your choices.

So, how do font-makers feel about Ascender's new web-fonts proposal?

The rise of the Internet is the greatest technological and societal change any of us has ever seen or will ever see in our lifetime. Contribute to it, deal with it, or get trampled. Those are your choices.

That's bullshit, not least because no one can know the future.
It's hard to raise a response from foundries, because we are generally go-it-alone entrepreneurs used to playing the cards we're dealt, and not having any say in how the game is played. I'm trusting Microsoft to look after my interests, that's their m.o. and dey bin berry good to me, as you recently pointed out. Bullying with hyperbolic ultimatums is a turn-off.

So, how do font-makers feel about Ascender’s new web-fonts proposal?

As I said, I support it 100%, for the reasons that Ray explained.
For a larger poll, let's see how this plays out at TypeCon.

@Richard
Compression as a second step is inherently less efficient, for most, probably inconvenient, and is, in many cases, simply beyond the author’s authority to implement on the web server.

And from your earlier post:
... plus the size of each OTF can easily make web authors very, very leery. Every extra second of download time can cost you visitors.

Compression as a second step to what?

If you are referring to compression that is applied after a simple obfuscation proposed by Ascender, then its compression efficiency is going to be exactly the same as if you applied compression to an original (un-obfuscated) TTF or OTF font.

If you refer to compression as a second obfuscation step - then the overall obfuscation results will be a lot more efficient as well - the simple obfuscation proposed by Ascender can be easily reversed by hand using any available binary file editor. Using compression as obfuscation is not bulletproof - I am sure there will be an application available on the net that people can download and use to decompress the font file, but there are certain risks involved in doing this and I doubt that many people will actually do it.

The bottom line - targeted font compression will benefit both authors and web users, and can also benefit font vendors as an additional step in obfuscation mechanism. More so, there are quite a few people who are against applying any sort of obfuscation for fonts but they do agree that font compression is valuable.

Regarding the author's ability to implement it on a web server – correct me if I am wrong but in this particular case I think we should be considering these possible options:
1) authors use raw fonts – they create the content and the CSS file that references the fonts and font files to be hosted by a server;
2) authors create the content and the CSS file that references the fonts and font files but use fonts obfuscated according to the algorithm Ascender has proposed (assuming using readily available tools or web-based service that does it for the author), then they provide obfuscated fonts to be hosted on a server;
3) same as option 2, but the fonts are also compressed (either by the same tool that obfuscates them or by the same web-based service (e.g. similar to what Ascender offers today for EOT conversion)
4) same as option 3, but you only compress the fonts before placing them on a server.

What’s the difference between these options that could possibly affect the author’s authority to implement either one of them on the web server?
I do agree with you on your second statement I quoted when you say that every second will cost you visitors (and I should also add that every second spent downloading a font will also cost you money – you pay for the bandwidth). This opinion is also shared by many on the CSS list, here are some of them:

“Yup, good compression/subsetting is a valuable feature in any web-font format, because many of the world's non-European descended languages have very large character sets that overlap little to not at all with English characters.”
(from http://lists.w3.org/Archives/Public/www-style/2009Jun/0236.html)

“Indeed, and there are some attractive technical benefits to EOT, or something similar to it. If you can definitely confirm Monotype's commitment to offer a fully GPL-compatible patent license, ideally with at least draft text of such a potential license (so that others can independently evaluate the issue of license compatibility), then I think the chance of persuading non-MS browser developers to consider adding EOT support will be considerably improved.

> The solution that is *only* suitable for free fonts is not a good solution.

Certainly. And even for free fonts, the compression possibilities of EOT could still be very worthwhile.”
(from http://lists.w3.org/Archives/Public/www-style/2009Jun/0309.html)

Regards,
Vlad

@Vlad

It's probably my fault in not explaining myself more clearly - but I think we actually agree. Sill, I'd like to get what you're saying absolutely straight in my mind. It's late here. Let me re-read your post sometime tomorrow and make sure I understand what you're saying, compare it to what I thought I was saying, and get back to you.

@nick

Bullying is the farthest thing from my mind. More like pointing out that there's a freight train coming at you and, as it happens, you're standing on the tracks. That's all. The train's coming through, whether you stand there or not.
But you're right, that style of rhetoric doesn't help. And the situation isn't that dire. Web fonts won't bring certain death. I screwed up in wording it that way.
I agree that the opinions of "the little guys" are probably not going to make a difference in the outcome. But please don't proceed on that assumption and stay silent. (And, wisely, you have not.) Words count. Bill Davis is asking this for a reason. I don't think it's window dressing. IMHO. I've corresponded with browser developers who do care about whether or not a new file format will influence the quality and variety of fonts available for use in web pages.
And yes, I agree that you do owe Microsoft major thanks for holding the line. The motivation might be mostly self-serving, but who cares?

Duh. The lack of step-by-step descriptions of each proposal are hampering understanding.
I asked, someone who's lost me barfed at my request. So... we listen to more nonsense without a clue.

Cheers!

@dberlow

Now we agree! (I think.)
A step-by-step description of the process or - I think easier to understand - a list of changes made to the OTF that turns it into an OTW file.
Maybe that can clear up the fogginess. I'll be working on it, as I understand the proposal(s) now to be.
A simple explanation free of jargon - for myself and others who aren't familiar with (and, mostly, couldn't care less about) the intricacies of OpenType or MTX.
An explanation of how this new file format differs from a regular OTF.
Once that's done it's a lot easier to discuss what problems it solves, the pros and cons, and how it can be deployed.

Later,

rich

@rich: The rise of the Internet is the greatest technological and societal change any of us has ever seen or will ever see in our lifetime - um, what about peak oil?

@dberlow
Vlad, can you please list the main steps from where we are, to where EOT is deployed to all?

David, sorry for a delay in answering your questions, I’ve been swamped.

The proposal that is currently being considered by W3C has evolved from the original EOT solution and includes the following aspects:
- same-origin restriction (which can be lifted by access control headers on a server side), and
- simple obfuscation + targeted font compression.

Same-origin restriction and access control are intended to restrict other websites from using fonts on your server (and would work very similar to what Ralf Hermann described in one of his posts).

Aside from this, there are two steps that would be required to implement:
- on authoring side: an original font will be processed by a tool that obfuscates a font according to the algorithm proposed by Ascender, compresses the data and stores it in a web font wrapper format on a server (something like what WEFT used to do, only easier to use and author-friendly). Authors will then be able to reference this file from CSS stylesheet, and there will be no need for authors to implement special handling of fonts for different browsers.
- on browser side: a browser unwraps downloaded font file (which would include decompression and de-obfuscation) and processes it the same way raw fonts would be processed.

The benefits of this solution:
- Simple and unified workflow for web authors, universally supported by all browsers (at least, this is the goal);
- Font files that are placed on a server are wrapped in a web-specific format. The font data is compressed which will reduce the download time.
- Simple pre-processing on browser side, compatibility with the existing and already implemented raw TrueType workflow.

Wrapped fonts cannot be downloaded and installed as a system font, one would have to use a software tool to unwrap and decompress a font first. I am sure someone will come up with such tool, and it’s impossible to completely prevent font piracy, but such actions would mean willful act of piracy and I doubt many people would want to do it.
To the contrary, having raw fonts on a server means that anybody can download and install a font as is, and people may likely to consider this as appropriate action (simply because font is on a server, unprotected and easy to grab).

I cannot give you any exact estimate of risk reduction afforded by the font wrapper solution, but, as an analogy, I see this solution like a small padlock on the door – something that is easy to put in place, will not stop a burglar but will deliver a clear message: “do not enter”.

Regards,
Vlad

@vlad
>"Aside from this, there are two steps that would be required to implement:
- on authoring side: an original font will be processed by a tool that obfuscates a font according to the algorithm proposed by Ascender, compresses the data and stores it in a web font wrapper format on a server (something like what WEFT used to do, only easier to use and author-friendly). Authors will then be able to reference this file from CSS stylesheet, and there will be no need for authors to implement special handling of fonts for different browsers.
- on browser side: a browser unwraps downloaded font file (which would include decompression and de-obfuscation) and processes it the same way raw fonts would be processed."

This is very clear and simple. Thanks. We ARE talking about the same thing.

The only concern I have is with this phrase:
"compresses the data and stores it in a web font wrapper format on a server"
This seems to me to skip a step and possibly create the wrong impression.
It makes it sound like the web author who uses the tool to create an OTW file somehow doesn't control the file in the same way he or she controls a gif or a jpg or the OTF of a free font. As if there's some weird requirement that the file exist only on a server from the moment of its creation.
To clear this up: As a web author, I would use a Weft-like tool to create an OTW file. I would then place it on my web server. I would then use the font by linking to it via @font-face rules in the CSS.
Correct?

Further: Regarding the same-domain restriction, I am concerned about pages that are saved by users to their local hard drives. Will the fonts be available?
I'm also very, very concerned about HTML pages that are a part of E-books created along the lines of the E-Pub specification.
In those instances, there is no http domain to speak of.
Now, the Weft tool allows you to specify drive letters like C:, D:, E:, etc... for this purpose. You can also specify sub-folders like C:\mybooks, D:\mybooks\janeaustin, etc...
Therefore, I don't foresee any objections to "off-line" usage of this kind.
The OTW file is still uninstallable as it is. It is no less or more protected than if I had peeked at the CSS and specifically downloaded the OTW on it's own.

However, I think this very much needs to be clarified. I don't want the browser to balk just because the OTW is being called from the local hard drive and not a web server. If a visitor to my site decides to save a page and then, when they open it up for re-reading, my formatting blows up because the font is no longer available to that page, I've got a big problem. That's a bad scenario.
(And by the way, it's not unusual for a web designer or developer to work with a page this way - displayed off a local drive, independent of a locally running http server like Apache or IIS.)

Within E-Books, it's even more critical that formatting be preserved.*

Thoughts from anyone about this?

*When all this font-embedding business finally gets worked out, it will take a few years but there actually will be such a thing as font-based web design. Just like, uh, books and magazines. Remember them? Talk about potential.

"San Francisco, Calif. — June 24, 2009 — Small Batch Inc. announced today that they have secured a round of equity funding from a group of investors led by San Francisco-based True Ventures. Small Batch is developing Typekit, a service enabling designers to build sites with web-native typography.

“This funding is the next step in our plan for bringing real typography to the web,” said Bryan Mason, Small Batch co-founder and President . “We want to build a nimble, safe tool that makes it easier for web designers to do amazing design online, and a lot of people believe in that goal. We’re excited and humbled by the team of investors supporting us.”

Link.

@Richard
To clear this up: As a web author, I would use a Weft-like tool to create an OTW file. I would then place it on my web server. I would then use the font by linking to it via @font-face rules in the CSS.
Correct?

Yes, I thought it would be self-evident and skipped it for brevity. And by "a web font wrapper format" I meant OTW or whatever format/extension we might adopt in the future.

Further: Regarding the same-domain restriction, I am concerned about pages that are saved by users to their local hard drives. Will the fonts be available?

I would like to make what I believe is an important distinction: "same-domain" vs. "same-origin" restriction. I mentioned the latter, which should work just fine with saved or cached content - since the fonts do come from the same origin. The same should be true for any content on your local drive, E-book, etc.

Cheers,
Vlad

@vlad

Understood. Thanks for the clarification.
Have also started following more closely the back-and-forth at w3.org.

Stay cheerful,

rich

I just posted an update to our previous web fonts proposal. It can be found here: http://typophile.com/node/59489

Hmm, I'm a bit late to this discussion, but anyway:

@billdavis: "WEFT does not change the order of glyph IDs when subsetting a font. The OpenType Layout tables are not re-written. But the data for the glyphs IDs that are not part of the subset are removed."

If I'm understanding correctly that it doesn't modify those tables at all, then that doesn't seem like an ideal solution - many fonts have tens or hundreds of kilobytes of data in their GSUB/GPOS tables, almost all of which can be deleted if you're not using all the glyphs, giving a significant space saving.

It's quite possible to rewrite those tables, and to automatically keep just the extra glyphs that result from substitutions of glyphs in the subset - the (open source) code behind http://fonts.philip.html5.org/ does that. (It's kind of complex, and it's certainly not bug-free, but it's worked in all the fonts I've tested so far.)

Relevant ongoing discussion over here (comments from the pack are esp illuminating):

http://ilovetypography.com/2009/07/20/web-fonts-—-where-are-we/

. . .
Bert Vanderveen BNO