http://www.typophile.com/node/57934

yeah, I've seen this one. Just want to turn it into nice tabular form so that it's easy to find your way ;-)

@josefrichter

Ralff Herrmann keeps a list at www.webfonts.info/wiki/. You might want to connect with him. He's the only one I'm aware of who's been at all systematic about it.

Just a note of caution however - there are so many different flavors of licenses it's tough to know which foundries allow what.

I, for one, appreciate your efforts, though.

rich

Richard. Exactly because of various EULAs, I'd like to have a kind of definitive guide (althoug it will never be "definitive").

I've contacted some foundries with direct question whether I can use their typeface e.g. for Cufón and got direct yes/no answer - so just wanted to record their answers and share them with others. I can imagine people repeatedly ask foundries these questions, so this wiki could be a starting point.

Great idea, Josef. I went through Ralff's page few months ago and I found it to be quite light on information, so I ended up emailing a handful of foundries and individual type designers asking about Cufon licensing.

I don't remember the exact list, but Exljbris, Darden Studio, Process Type Foundry, Paragraph, H&FJ, Dalton-Maag, Linotype and Wilton Type Foundry were on it. Note that I was asking only what the licensing conditions for the Cufon use would be, and not with sIFR or other options.

Process and H&FJ were a no-go. Or rather like "La-la-la... we can't hear you... strictly forbidden, STRICTLY !".

Paragraph, Wilton were a no-go as well, but said they were "considering it".

Exljbris and Darden Studio are OK with no additional strings attached.

Dalton-Maag are OK, but you need to ask for it explicitly. Their existing license does not allow for Cufon, and there are additional requirements for high-traffic websites.

Linotype appears to be OK, but requires an additional paid license. I had a really odd conversation with their support, which is in fact still ongoing. In first reply they merely said "we offer web licenses which offer this usage", "this" referring to Cufon. That's it. And asked for a mailing (!) address to send me an invoice. No mention of the fees, restrictions, etc. I replied asking for a balpark estimate of fees, and they replied that they needed to know the exact typeface and asked for mailing address again... you guessed it... for an invoice. I really don't know what is wrong with them.

--

Another interesting list to build would be the typefaces seen used with sIFR/Cufon/FLIRin the wild, on high-profile and presumably properly licensed websites. I know I've seen Avenir, Gotham (!) and Akkurat.

--

Lastly, can I ask why you have FLIR listed as No in several lines in your table? How the heck can it be prohibited if the font use by the FLIR's server component falls squarely under a typical EULA?

>How the heck can it be prohibited if the font use by the FLIR's server component falls squarely under a typical EULA?

Not sure I fully understand what FLIR is. Looks like fonts are installed on a server. A Typical EULA allows 5 users. That seems a little limited if you view each Web page visitor a user. Most EULAs have been rev'd to limit this type of thing, and many vendors offer server licenses.

I’m not trying to hijack the thread, just jumping in because I keep ending up on lists of foundries that allow @font-face use. Dunwich Type Founders (aka me) no longer allows embedding/linking in the standard EULA. Instead I am moving entirely to service-based web fonts. My feelings about web fonts, formats, and standards have not changed. I just could not come up with a license/pricing scheme that I felt made sense and worked for fonts sold in standard 1-5 user packs through third party vendors.

>Not sure I fully understand what FLIR is. Looks like fonts are installed on a server. A Typical EULA allows 5 users. That seems a little limited if you view each Web page visitor a user.

You are forgetting that every image returned by FLIR server at client's request needs to be rendered only once and then it can be served from the server-side image cache. Under this arrangement even a 1 user limit is quite practical. The only requirement is to ensure that no more than 5 images are rendered at the same time, which is trivial to do and not limiting at all.

Sorry not convinced. I'm certain most EULAs have been rev'd to prohibit exploitation of this kind of server-side loophole. There are clauses about location, transfers etc, and they count total (including remote) users, not concurrent users.

Sorry, I don't follow.

To elaborate - I buy a one-seat license, I take the .otf and stick it on a server (assuming I have one, or I buy a five-seat license and copy .otf to five servers), then I start one process and make it service trivial FIFO queue of rendering requests from the web server. That's it. Unless there is a licensing clause that prohibits this specific setup, I am well within licensing requirements. The font file is never used by more than one CPU at any given moment.

Typodermic web embedding info. @font-face licenses available at FontSpring or through Typekit. Cufon & SIFR are fine with the regular EULA.

I take the .otf and stick it on a server ...
Unless there is a licensing clause that prohibits this specific setup …

Exactly. A remote "server" use is almost always prohibited.

I went through Ralff's page few months ago and I found it to be quite light on information

Anyone is invited to add content to the page. I just set it up to push webfonts in general. I have no personal or commercial interest to consider this "my page".

RE: FLIR

So, if I take the font and make a photoshop image and post that on a web server, that's OK.
But if I stick the font on a server and let PHP do what I would normally have to do manually in photoshop, that's not OK.

That it?

I imagine most EULAs either already prohibit FLIR, or will soon, as it amounts to creating an electronic device with the font embedded in it for the purpose of generating text dynamically, which is a quite a bit different than typesetting a images manually in Photoshop.

Web designers and programmers need to get it through their heads that if they want web fonts to work they need to actually work with font designers and pay for appropriate licenses instead of spending so much time looking for loopholes.

> Web designers and programmers need to get it through their heads that if they want web fonts to work they need to actually work with font designers and pay for appropriate licenses instead of spending so much time looking for loopholes.

Can you elaborate what you mean by "work with font designers" exactly and why existing fees are suddenly not "appropriate"?

Can you elaborate what you mean by "work with font designers" exactly…

That means developing and using technology that works with licensing that font designers find acceptable instead of cooking up hacks designed to exploit perceived loopholes in licensing.

…and why existing fees are suddenly not "appropriate"?

Because they are my fonts any I want more money.

Designers are not entitled to cheap fonts any more than they are to stock art, web hosting, software, etc.. Paying for the materials used in commercial work is not a new concept. Designers have literally been doing this for thousands of years. Your client is making money off their site. You are making money by creating the site. I should be able to make money when my work gets used in the site. There is no reason a professional web designer/developer charging a hefty hourly fee cannot license a font and pass that cost on to the client so that the designer who created the font can afford to eat. Instead of wasting your time trying to cook up the web font systems that do not require any spending just buy a license and charge it to the client with a markup or a time charge; just like you would do for every other aspect of your job.

Jeez, have you got one too many espresso shots this morning? This is not about "loopholes in licensing".

The state of affairs is that I pay $40 per weight, get the font, render an image in Photoshop and stick it on a website. I assume you do not have a problem with this.

FLIR does the exact same thing. It does not add any value to the website, it does not generate more money to the site's owner. All it does is it simplifies the life of a web designer. And not by much mind you, it saves may be... what?... 2 hours of work. If that.

The designer is not sitting there and thinking how to pay less. He is thinking how to do less. That's what FLIR & Co. are about.

I doubt many designers are cheap enough to be against web-only licensing. The biggest issue at the moment is that @font-face is not quite there yet. Its rendering quality varies too greatly between the browsers and OSes to be satisfactory. That's one. Hosted solutions like TypeKit are not a feasible option in many cases, because they create external dependencies. That's two. All this is going to be sorted out, but it will take time.

Meanwhile "hacks" are the practical option. They work, and they work well. If you feel like charging a fee to allow FLIR/Cufon/etc usage - do it then, but I personally feel it is unreasonable.

FLIR does the exact same thing. It does not add any value to the website, it does not generate more money to the site's owner. All it does is it simplifies the life of a web designer. And not by much mind you, it saves may be... what?... 2 hours of work. If that.

It’s not the same thing. It’s you building a machine that does the same thing, over and over, much faster than you could ever hope to. And if it saves you two hours of work, that’s two hours you’re using to work on something else. There’s money involved. And if my font is part of it, I want my cut.

Something else I want to point out here is the power of something like FLIR to be applied to numerous web sites. In the case of an individual user and a single site, you’re right in that it’s not really big deal. In fact, the way I license type as of today, I would make more money selling you that FLIR server license than I would selling you a single domain @font-face license.

But you aren’t the guy who makes it a problem. The problem is that at some point someone who hosts 1,000 web sites on one big server realizes that he can install my fonts, and FLIR or SiFR, and make it available to all 1,000 web sites at no additional charge. Suddenly I’m missing out on a lot of licensing fees no matter how it works out. And maybe it makes more sense for me to write a provision into my EULA that allows something like FLIR or SiFR when limited to single domains. But if I have to tweak my EULA for everything like this that come along, I end up with a big ugly hydra of a EULA. Or I have to just stop using resellers and make all these different options available in an online store. Right now I’m inclined to just keep things real simple and tell people to buy an @font-face license.

> It’s you building a machine that does the same thing, over and over, much faster than you could ever hope to.

It is not doing it over and over again. It renders every image exactly once, when it is first requested; and not once per client request.

> And if my font is part of it, I want my cut.

By all means. I just think that the expectation is that it should be included in a standard licensing fee.

--

Just try and understand where all these "hack" technologies came from. Think 6-9-12 months back from today.

Designer buys the font, it uses it to set a handful of headers on a website. Then he wants to use it more widely, say, for subheaders and blog entry titles or something like that. So he emails the foundry and asks what it would take to use their typeface in an online context. The standard reply is "NOOOOOOO", a more contemporary response is "we are thinking about it" as in "check back in a year".

Designer still wants to use the font, but he is also respectful of the type designers (remember how he actually bought it and he asked for a web license ?). He understands that foundries are afraid of the Internet and their fonts leaking onto it in their native formats. So he sits down and considers his options.

First is to render on the server (best option really, the font file stays private, the file usage is tightly controlled and falls under simultaneous usage restrictions), second is to render on the client, but with the font data obscured, stripped down or made unfit for copying in some other way. Former translates to FLIR, latter - to Cufon.

Note how the driving factor here is the conservatism and rigidness of the foundries and nothing else. There is exactly one type of license available to the designer and he is forced to get creative within its confines. It has very little to do with unwillingness to pay more money to the foundry, and far more with foundry's own lack of interest in collecting these money.

Where is the font typically stored for FLIR? Can someone poke around for whatever.com/fonts/fontname.ttf or is it in a folder people can't typically get at? I'm wondering if I have to specify that it's put in a protected folder in the EULA. Is the font's path visible in the page source or style sheet?

> I'm wondering if I have to specify that it's put in a protected folder in the EULA.

It won't hurt to specify that. Something like "ensure that font files are not accessible from the web" or "do not reside in a public web server tree". The font's path is not a part of the page or a style sheet, don't worry about it.

I read the quick start guide, watched the video. I can't figure out where the font ends up. Where does the font actually go? It it obfuscated or is it a desktop installable font? Even if someone could set it up so it's in a specific protected folder it's the default that matters. Where exactly does the font end up when the average FLIR users set this up with the default "quickstart" settings?

Hi everyone,

The final version of the table has moved to http://webfonts.info/wiki/index.php?title=Web_fonts_licensing_overview

Remeber it's a wiki - so please feel free to add the info about other foundries - but only if you are 100% sure about it, because e.g. it's explicitely stated on their web or in their EULA.

Also, if you are a foundry, it would be great if you could publish a statement on these technologies on your web, just like Type Together did over here http://www.type-together.com/index.php?action=portal/viewContent&cntId_c... I understand that the table is somewhat tricky, because it may tempt people to skip reading the EULA carefully, so this might be a solution.

Thanks everyone

Josef Richter

@apankrat: You seem to be taking the view that anything not explicitly forbidden by a license is permitted. Many EULAs I've read seem to be written that the licensor is permitted to only use the font in the specific ways enumerated in the license; that is, anything not explicitly permitted is forbidden.

Not that I'm a lawyer, of course.

But in any case, many EULAs will doubtless be revised within the next several years to deal with web fonts and other forms of server-based usage.

Cheers,

T

I've been looking into FLIR. It violates my EULA and probably most others.

"You may not provide the font or make it accessible to any other third parties."

FLIR, by default has fonts in a subfolder called "fonts". It wouldn't take much imagination to go to a site that used FLIR, figure out the font names and take a few guesses at the filename. If your first guess is whatever.com/fonts/fontname.ttf you've got a font. So, until by default, the fonts are protected from direct downloading, I'm recommending not allowing FLIR use. Perhaps users could use set up a protected folder or something but unless it's done by default in FLIR, I'll assume that few people will.

Another problem with FLIR is that it's easy to copy a line from the page source render the font to another site. Let's say you find a site that's using a font you like. You can have that site render headlines for your own site. It's not a nice thing to do and it's a drain on the host site's CPU and bandwidth but it can be done.

I'm saying no to FLIR unless they can fix both of these concerns. As it is now, it's just as insecure as bare @font-face linking.

The Nancy Reagan approach.

Nancy Reagan didn't solve anything with words.

And her husband did little with the military industrial complex.

Ultimately, both extremes are a bit silly. Just saying 'don't steal fonts' and assume no one will is as naive as believing there is some magic technology that prohibits the copying of data (which is pretty much what the web does by design).

We'll find a middle ground sooner or later.

What are you even talking about? New font embedding technologies need to make a little effort to try an protect the fonts from direct URL downloading. I'm supposed to get behind every half-baked font embedding scheme that gets slapped together?

Apankrat, we're not humming with our fingers in our ears, and we do hear you, but that still might not mean we can give you everything you want. H&FJ's currently position with respect to fonts online, and image-replacement technologies, is here:

http://www.typography.com/ask/faq.php?faqID=15#Faq_15

I should stress that this policy is under constant review, and that as you know this is an especially dynamic time with respect to fonts in browsers, so please continue to check back.

Ray, I'm not saying you can or should get behind any particular font embedding scheme. I'm just pointing out that none of the current schemes really will prevent font piracy.

There's a column on that chart for endorsing WOFF that is incomplete. Here's the mozilla press release with the list of foundries who have come out in support of WOFF:

http://blog.mozilla.com/blog/2009/10/20/mozilla-supports-web-open-font-f...

@hoefler: With all due respect, from the page you linked to:

If you are exploring other technologies that aren't covered here, please contact us at info@typography.com.

which is what I did and here is what I got back:

Dear Alex
Thank you for your inquiry regarding Cufon and H&FJ's fonts. This application is specifically prohibited from our licensing agreement at this time.

and a link pointing me back to the FAQ page. Barely three lines if that. This does not sound like you "hear me". Especially considering that I also asked another question in the same email that was just plainly ignored.

@typodermic

I'm supposed to get behind every half-baked font embedding scheme that gets slapped together?

Not saying that. (Actually I was just testing to see if you knew what Nancy Reagan's famous tagline was.) ;)

What I would like you and every font designer to do is try to see things from the point of view of the guy on the other side of the "Buy Now" button.
He's got a job to do. You can either let him do it without FUD or not.

For instance, the license on the new Fontspring site allows @font-face linking but not Cufón. This is nuts. In many instances, Cufón is a perfect fallback for platforms and user agents that don't support @font-face. It's particularly adept with headings and logotype.
The JavaScript data in the Cufón file with the font outlines is, if anything, far more secure than the linked font file. (In that it doesn't have its own URL, and reconstituting it back into anything resembling an installable font is beyond the capabilities of anyone but an expert. Certainly not worth the time.)

but anyway, that said, I find all this, right now, a little beside the point. I don't know how anybody looking to buy a font for web use can do so unless they're shown an in-browser specimen sheet that allows them to accurately assess the look and overall behavior of the font. (Tracking, kerning, etc, at each pixel size.)
I have yet to see that and Fontspring's in-browser specimens miss that mark, too.

rich

My embedding scheme requirements aren't that demanding, are they? I don't need fancy(pants) anti-piracy schemes. I know people can extract my fonts if they really want them or get them through other means. All I ask is that people aren't able to directly link to a perfect, installable copy of a font with no EULA.

So FLIR is out. How's WOFF for security? Can users directly download from an URL? If so what use is the font once they've snagged it? Can they use it on their own site?

Do you think there's anything else I need to cover on the Typodermic Fonts embedding page?

The JavaScript data in the Cufón file with the font outlines is, if anything, far more secure than the linked font file.

As far as I understand it from looking at the Fontspring website, the linked fonts are splitted or otherwise modified, so they can't be downloaded and installed on other computers.
I wouln't support Cufon either. Simply because @font-face is the future and Cufon just an awkward JavaScript hack.

How's WOFF for security?

It's got a different wrapper, so a WOFF font isn't directly usable as a desktop font without first being converted.

It also has some optional metadata fields so people can spell out what is okay to do with the font. But there's nothing that actually stops somebody else from just re-using the same WOFF font somewhere else; the spec specifically says no user agent is required to do anything differently baesd on metadata, it's purely informative. Informational, but not enforecement.

Regards,

T

Cufon is just an awkward JavaScript hack.

There may be cases where that's exactly what's needed; supporting older or low tech browsers . . . or a use you haven't thought of. Is your dislike of Cufon really a good reason to tell a customer "no you can't use my font for that"? There's a difference between not recommending Cufon and forbidding people from using it.

I'll let the users determine whether or not a particular embedding scheme should live or die. Cufon doesn't put my fonts at any more risk than EOT did so it stays.

As long as my "not directly linkable" requirement is met they can create a new web embedding scheme every week. Bring 'em on.

But the remote rendering aspect of FLIR concerns me. Even if someone doesn't take a copy of the font, they can have another server render the data and send it to their site. AS far as I know it's the only embedding scheme with that particular problem.

"I imagine most EULAs either already prohibit FLIR, or will soon, as it amounts to creating an electronic device with the font embedded in it for the purpose of generating text dynamically, which is a quite a bit different than typesetting a images manually in Photoshop."

This is why real-world designers and web developers couldn't care less what EULAs say. They don't have time for this kind of nitpicking type designers seem to be obsessed with.

As far as I understand it from looking at the Fontspring website, the linked fonts are splitted or otherwise modified, so they can't be downloaded and installed on other computers.

I talked with Ethan at Fontspring about their security last week. They cut the character set down to Mac Roman and then split them into two files. They also rename the fonts with random numbers.

. . . and strip the OT features.

@typodermic

A lot of Fontspring grew out of and was predicted by my article An Open Letter To Retail Font Vendors. Right down to the obfuscated specimen pages.
(I know this also because Ethan Dunham told me so, essentially. And I've actually gotten emails from others assuming I'm involved with the site!)
Fontspring is a first generation peek into the future of retail fonts on and for the web. I've got quibbles about presentation, but the raw materials are all there.

Some thoughts:

But the remote rendering aspect of FLIR concerns me.

On FLIR:

1) I believe it can be set up so the font file is *not* exposed. In fact, that's my impression of how it's usually done. The font file is protected from calls outside the server. Invisible to the outside. I'm a lot busy right now, but I'll look soon and get a definitive answer. It's all open source. Anybody else have that info?
2) FLIR looks too good to be true and so it mostly isn't. Text-as-images are almost always static content. There's no point in having the server thrash around creating text-as-images on the fly. It's too costly and, except in special circumstances, plain dumb. The technology's been around quite awhile now without a massive outbreak of sites designed with FLIR. And there won't be. But it *is* yet another fallback mechanism and there's too few tools available to summarily dismiss any of them.

Bottom line: I would permit FLIR under the condition that the font files are inaccessible. Or, as you put it, "not directly linkable". No URL to bring it to you on a silver platter. (Since they're installable TTFs and OTFs and that's the big bugaboo.)

I'll let the users determine whether or not a particular embedding scheme should live or die. Cufon doesn't put my fonts at any more risk than EOT did so it stays.

Absolutely. I understand Ralf's point but I don't think EULA's are about telling customers what's a good web design practice and what isn't.

Lastly, as John Hudson suggested on another thread, I would seriously consider re-naming fonts being offered for use with @font-face with a suffix of some kind. "Web" or "Screen" or somesuch to carve them out and away from those fonts designed and marketed for print. Good for consumers, good for type designers, too, I think.
Separate (yet related) products for separate purposes.

rich

1) I believe it can be set up so the font file is *not* exposed. In fact, that's my impression of how it's usually done. The font file is protected from calls outside the server. [snip] Anybody else have that info?

Of course it is doable. It is a one-line change even if there is no corresponding configuration setting. If FLIR requires fonts to sit in a website document tree, that's just sloppy implementation on their side, and not a fundamental FLIR requirement.

There's no point in having the server thrash around creating text-as-images on the fly. It's too costly and, except in special circumstances, plain dumb.

Caching, Richard. Server-side image caching :-) Do not re-generate what has been generated already, just serve it from the image cache.

Just a couple quick notes:

We allow most forms of embedding – if not with our "regular" fonts then certainly with our "WEB" versions. You can see a bit of info about this all here. We will be publishing more on this and our WEB fonts in just a couple weeks...

Also, since it hasn't been mentioned here yet, I will remind people of Tiffany's tumblr page of foundries supporting woff (it is more extensive than Mozilla's)

Cheers,
Rob

@apankrat, it's definitely not how it's usually done.

I checked out a bunch of sites in the FLIR forum's showcase section. I won't say exactly what I did but with many sites I was easily able to download the default fonts which are included with FLIR. At almost every site I was able to download the README.txt file from the fonts folder. That means I'd be able to download specific fonts if I could guess the correct filename.

What I still don't know is: is it possible to read the config-flir.php file to figure out the font file name? I tried my own test and I wasn't able to get at the contents of my own php file. I don't need to know how to do it, but is reading the contents of a php, if you know the path and filename from someone else's site a really involved thing or it is kind of hard core? I really have no idea.

What I'm probably going to do is allow the modified @font-face Fontspring versions to be used with FLIR. That way they'll at least have random filenames. But if the php file can be read, then it'd be easy to figure out the path to the font anyway.

Hello everyone. A friend pointed me to this thread because you are discussing FLIR pretty heavily here, and being the author of FLIR, I wanted to chime in.

First, @typodermic
I checked out a bunch of sites in the FLIR forum's showcase section. I won't say exactly what I did but with many sites I was easily able to download the default fonts which are included with FLIR.

The fonts can be placed anywhere on your server (including outside of the web root). This is a single line change in the config. The only reason you were able to download these fonts is because you already knew they existed (and knew the filenames). These fonts are *NOT* the fonts the user uploaded themselves with their folder. Just to clear this up, you were not able to get a directory listing of all the fonts that a user has uploaded unless the server was configured to ignore index.html.

To say this a different way, if I uploaded my-font289.otf to my fonts directory (in my web root), you would have to be able to guess that the file is named my-font289.otf in order to be able to download it.

Access to this folder can also be limited with .htaccess which I will be including in a future release for those that don't have the skill set to move the folder outside their web root or write their own.

===

@All the foundries and typeface designers out there, in this thread and beyond:

I apologize in advance. Some may consider this off-topic from the OP, but I figured this was as good a place as any to speak directly to you guys. If any mod as a problem, feel free to fork it onto a new thread. (Also, please ignore any ramblings or things that don't make sense, I've been up all night working on some random thing ;] )

With the development of font-face, I thought that we, as a community of web and typeface designers, were finally on our way to getting this whole mess of web fonts settled. After reading this thread, it is obvious that I was wrong, and that is what prompted me to write this.

So let's call this my personal plea to you.

I'm not a web browser manufacturer or anyone else all that important. I've only made a script that I found useful, and then gave it to other people to use. I'm really just someone who wants to be able to use your products. I need to use your products. I like your products. And I am willing purchase what you are selling, if only you would sell it to me.

Please, please get rid of these costly "font-face" and "embedding" licenses. I am on me hands and knees begging you to stop demanding all sorts of pointless encryption schemes that only serve to make using your artwork more difficult.

The web is not your enemy. It is an ENORMOUS new market for you to break into. Sure, your font will get downloaded by some college kid somewhere and used on their flyer, or maybe it would even be outright pirated by greedy people for personal gain. There is no way to prevent this from happening even now.

Just like the music, movie, stock photography, and book industries (and many others) have already found out:

The web is scary at first -- it is different -- it might even require a change to the way things are done. But, as these industries have already demonstrated, it can become very profitable once the fighting stops and the leap is finally made. The same mistake being made in the typeface industry has already been made by so many other industries -- looking at a pirated font file as a lost sale. This is not the case. That person who is stealing your font file probably wouldn't have paid for it in the first place and in trying to keep them from doing so is being done to the detriment of countless potential customers.

I want to keep this short (I've already failed), so just to summarize: Let us (web designers and developers), have easy access to buy and implement fonts -- at the same price as we would otherwise pay to purchase and Photoshop all the headers on our sites. Let us have this ability and we will use it. I promise you, we will in numbers that will make you -- and your industry -- very happy.

Please stop fighting us. We are not your enemy. We would like to be your customer.

I welcome any kind of comments to my email -- cory.mawhorter@ephective.com -- and would be happy to discuss the subject with any foundries or anyone else.

I’m not really sure what to make of this post. It’s kind of like writing a letter to the SciFi channel asking them not to cancel Battlestar Galactica. The war is over. The browser makers and the font makers have voted, and in five or six years we will hopefully see the majority of installed browsers supporting WOFF. Between now and then there will be interim solutions, best served by folks like Typekit who provide “fonts as a service” rather than the random, often hack-like, solutions currently being promoted. As to font pricing and web specific licenses, I don’t think any level of pleading from web designers (or the companies, large and small who will end up paying for the font licenses) will really make much difference – the market will decide.

"I don’t think any level of pleading from web designers (or the companies, large and small who will end up paying for the font licenses) will really make much difference – the market will decide."

Aren't the web designers 'the market'?

Yes. I guess I should have said "free market" = supply and demand, availability of open source/clone alternatives, that sort of thing.

The reason this and other posts like it show up here on Typophile, is because of the false impression given by the actual slow-foots, to the general public and including the web designing public, that it is "The Foundries" resisting this, that or the other thing regarding web fonts, and that, hilariously, this Foundry resistance, is why web fonts are taking so long to be perfect, plentiful and free. As things become rendered more clearly on this issue, I hope these posts go away.

Cheers!

..and free. As things become rendered more clearly on this issue, I hope these posts go away.

You lost me at "free".

Me too. In fact that sounds like legal forms embedded in a poem. It do not think that is so cool. But here you go.

We should not fight these people, but find a common ground.

Hey, I'm happy with you, even though you never took any of my fonts. And my fonts eat your earnings as well.

The only reason you were able to download these fonts is because you already knew they existed (and knew the filenames).

It didn't take a lot of figuring out. If someone can identify a font, they don't need to take a lot of guesses to figure out the filename. For example: I sell a font called Soap. Not surprisingly, it's either soap.otf or soap.ttf. Just about every site I checked kept their fonts in a rather obviously named subfolder. The quickstart guide doesn't recommend that the fonts be kept out the the HTML tree. Almost everyone called the main folder somethign very obvious . . . I did too when I was testing. Regardless, the parent to the fonder containing the fonts is plainly shown in the page source as well. As for the sub-subfolder, I could only find one site that didn't use the default folder name. Yes, someone could add their own security but most people do the default . . . apparently.

My embedding/linking requirement is that fonts can't easily be downloaded from a URL. It's not that crazy of a requirement. FLIR qualifies as "easily" because I tried it and it was very easy. I'm not technically adept . . . it took me an hour and a half just to install FLIR, but it only took seconds to figure out the folder path.

It's not just a matter of people taking the font for free. There are lots of ways to do that. It's having honest site owners, installing FLIR and unknowingly posting fonts which can be directly downloaded with an easily guessed URL.

All it really takes is a few spare minutes correct guess at a font file name. Not only do you get a free font but you also get an URL you can share or even remotely @font-face link to. All because the creator of said embedding scheme didn't consider adding any security whatsoever.

One of Fontspring's services is to generate @font-face ready typefaces which, among a few other things generates a random filename. I tested one of my fonts which had been run through Fontspring's @font-face system and it worked with FLIR: no problem. So there you go. My solution will be to require that the obfuscated font be used for FLIR. The price for use on a single domain is exactly the same price as a regular font license so it should be okay.

I like font hacks and admire anyone who tries to innovate. I wish that those who write font hacks had the foresight to make an attempt at keeping the fonts at least a little bit safer from direct downloading. At least safer than setting the default to an easily guessable subfolder of a folder which is shown in the page source.

>My solution will be to require that the obfuscated font be used for FLIR.

Renaming!
q4r-Tc81G.ttf
What a concept. Works for me, Ray. And if I was using FLIR, I wouldn't want anybody using up my server resources and bandwidth and taking fonts I've payed good money for and, in some cases, spent considerable time sub-setting and improving and converting.
No reasonable site owner or webmaster is going to argue with the logic of this - it goes beyond "protect my font from unlicensed distribution".
It's win/win and should be presented that way.

Just some thoughts regarding the change we're just beginning to go through for whatever bearing it might have on licensing:

For the past fifteen years web designers have been in prison, typographically speaking. Prison "Web Safe". Their meals have been cooked for them, their clothes cleaned for them, every aspect regulated. No thought required.
Soon, they'll have to deal with freedom. It *will* bring a change of consciousness about fonts. Fonts will be seen differently than they are today - as resources that you need to know something about to use effectively.
Today, fonts are this black-box thing you access by writing: "font-family: verdana, sans-serif;"
Today, the average web designer has no concept of "font-family". Font-family is synonymous with "the name of the font". The idea that italic and bold reside in different files doesn't even occur to anybody - why should it? It's been taken care of for them by the OS, out of view, for fifteen years. When it suddenly becomes their responsibility, it's completely different.
I could go on and on in this vein.
It's going to be very interesting to see how designers deal with the responsibility.
And when it *is* their responsibility, they won't treat those resources casually.

rich

>I could go on and on in this vein.

Please do: styling, sizing, scaling, rendering, treatments, leading, tracking...

But Prison? I'd say Childhood.

Cheers!

@dberlow

>But Prison? I'd say Childhood.

Spot on. The prison metaphor sucked but something more apt was eluding me. Childhood much better. Thought of it this morning then saw your comment.
David Berlow: Type Designer and Mentalist.

Of course, I *will* go on about styling, sizing, scaling, rendering, et al.
In the main, web designers don't know what they don't know about fonts.

But here we seem to be focusing on specific technologies and their relationship to EULAs.

rich

An update on Linotype. Previously on the show:

I had a really odd conversation with their support, which is in fact still ongoing. In first reply they merely said "we offer web licenses which offer this usage", "this" referring to Cufon. That's it. And asked for a mailing (!) address to send me an invoice. No mention of the fees, restrictions, etc. I replied asking for a balpark estimate of fees, and they replied that they needed to know the exact typeface and asked for mailing address again... you guessed it... for an invoice.

Only 9 days has passed and in response to my

I really don't need an invoice at the moment, just wanted to understand the pricing level and exact licensing terms. If you are set on sending me an invoice, please send it as a PDF to this email address.

now I have received a reply:

Dear Alex,
I can't - I still need your invoice address :-)
Best regards
Xxxx Xxxxxx
Linotype GmbH

Note the lovely smile. It is still like talking to a wall.

@sii

You don't know what to make of this post and I don't know what to make of your comment.

>It’s kind of like writing a letter to the SciFi channel asking them
>not to cancel Battlestar Galactica.

This means what? If it means that the people commenting here are out of touch, I find that offensive - although I don't believe you mean it to be - and, considering your position and who you work for, rather disturbing. Really.

>The war is over. The browser makers and the font makers have voted,
>and in five or six years we will hopefully see the majority of installed
>browsers supporting WOFF.

This vote took place when? Must have missed it. And what does the majority of browsers supporting WOFF have to do with anything? Please explain.

>Between now and then there will be interim solutions, best served by
>folks like Typekit who provide “fonts as a service” rather than the
>random, often hack-like, solutions currently being promoted.

Says you. If you really believe this, you're scaring me. Have you been watching Caprica?

>As to font pricing and web specific licenses, I don’t think any level
>of pleading from web designers (or the companies, large and small
>who will end up paying for the font licenses) will really make
>much difference – the market will decide.

There doesn't seem to any "pleading" necessary. If someone doesn't want to license to me under terms that I can live with, I just go elsewhere, that's all. Do you think I won't find what I need?
And Sii, it's "the companies, large and small who will end up paying for the font licenses" that comprise the "market" that you say "will decide". You're running around in circles. The browser makers and font makers have decided but the market will decide on their decision. Huh?

I'm glad you like Typekit. I like them, too. Both the guys behind it personally and as a service. But everything has its advantages and disadvantages. One disadvantage to Typekit is that it provides an avenue whereby font makers can say proudly that they are "licensing" for use on the web without really licensing for use on the web. As you can see from the comments here and a quick visit to Fontspring where, (at last count - it's more every day) Ethan Dunham has twenty one font makers who seem to be casting their votes some other way.
Therefore, as of right now, I am formally demanding a recount.
It seems Battlestar is back on.

The other downside to Typekit is that it postpones, among web designers, the learning about fonts and the way browsers utilize them, that must eventually take place.
There's no way around it. Web designers will have to learn some things they don't currently know about fonts. Ain't rocket science.

rich

Now, all Larabie Fonts are @font-face linkable. So, I think I'm covered for web embedding now apart from making a chart on my embedding page.

How do I get the ball rolling with WOFF?

>chart on my embedding page.
link stink? I get "Page not found"

> Ain't rocket science.

I'm torn — is it that [web typography] "Ain't rocket science"? or is it "Ain't [typography as] rocket science [fun!]?"

>The other downside to Typekit is that it postpones, among web designers, the learning about fonts

Downside? and perhaps the downside of low-iodine salt is that when normal people use it they don't get enough iodine?

Cheers!

Yup, link stink. Here it is: http://bit.ly/bbrUgM

@typodermic

WOFF - AFAIK, the quickest and easiest way to create a WOFF file is with the generator on Font Squirrel. However, the WOFF spec allows you to add some labeling data which the generator makes no provision for. There's source code for WOFF and the spec is published, but as yet, no comprehensive desktop tool I'm aware of for going from a fontfile->WOFF and then from WOFF->fontfile, and manipulating the discretionary data in between. I'm sure a few font designers have home-grown code for it.
However, WOFF is only supported in Firefox 3.6 which was just released and it will take some time for users to upgrade and 3.6 to propagate. (I still can't move to it and get all my add-ons to update to my satisfaction.)
That said, I know for a certainty that desktop tool(s) for working with WOFF are in the queue, it won't be long. Others might know about other options.
There's links here.

In a vein similar to WOFF, there's one other valuable tool I'd like you to be aware of, it's a couple of weeks away from release, but I can get you an advance copy and you can begin using it right away. (Dunham knows about it.)
It's something you and your customers can benefit from immediately.
I'll send an email to the gmail account listed on your site.

@dberlow

>Ain't rocket science
Manipulating font files ain't rocket science. Tables, some code, anything else?
Everything has a learning curve, but provided that decent educational materials exist, it usually doesn't take long for you to get the essentials clear enough in your head to, at least, make intelligent choices. To get to the place where you at least know what you don't know. Of course, as in any field, there are those with exceptional talent for it. But the basics are well within the grasp of the average web designer.

With creating fonts, there is an element reminiscent of ballistics involved. There is the "co-efficient" that still must be provided by the human eye.
Still no substitute.

rich

Thanks, Richard. I've updated my embedding page with that info. If you have time, please check it out and let know if it's accurate.

@typodermic

Will do. Looked quickly, looked OK, but I do have some comments and suggestions. You've been kind of like my first customer, so to speak, and my commercial neurons are now firing at warp speed after a long time on impulse power. Thrusters on full.
Much to do today. Will get back to you.

rich

In a vein similar to WOFF, there's one other valuable tool I'd like you to be aware of, it's a couple of weeks away from release, but I can get you an advance copy and you can begin using it right away. (Dunham knows about it.)
It's something you and your customers can benefit from immediately.

You're making me curious too.

The site is up and the product available for download: EOTFAST
EOTFAST is a utility for creating natively compressed EOT files for use with any domain. There are no root string restrictions, as with Microsoft WEFT.
Utilities like Microsoft WEFT, ttf2eot, the Font Squirrel EOT generator, and Ascender's tool for EOT "Lite" are now obsolete.
Savings in file size typically range from 45% to 70%.
For example, a first-rate screen font like Droid Serif starts out at 169kb as a TTF with the full character set but as an EOTFAST file it weighs in at only 80kb. With still the full character set. Compression is lossless.
Please stop by the site to check it out. Further announcements will appear in various forums in the coming days.
The documentation contains very useful information for font designers looking to prepare their fonts for use on the web.

The download package also contains a HTML "EOT File Integrity Test" page and a helpful "fallback" test font.

EOTFAST is a must-have for anyone looking to use @font-face web fonts today or for years to come - for as long as Internet Explorer has a substantial user-base.
Version 2.0 is already in work. I'm using a Beta of it right now. And as soon as certain technical issues are scoped out, conversion from TTF to EOT using EOTFAST will probably appear as an online service, as well.

EOTFAST works to deliver web fonts to half a billion IE users today - not in some distant the future.
I like the WOFF format but it has a bit of catching up to do now, with EOTFAST.

Rich

.

Rich, I commend your efforts, but IE is not the future of the web.

.

Richard wrote: ... Ascender's tool for EOT "Lite" are now obsolete.

This may be just marketing-speak, but in case it's not: Are you sure you understood the purpose of the EOT Lite proposal? It didn't leave out compression because it couldn't be implemented, but to allow other browser vendors to implement EOT support without any patent issues.

I like the WOFF format but it has a bit of catching up to do now, with EOTFAST.

Why? Tools for web font conversion have already existed for some time, for both WOFF and EOT.

In your blog post about EOTfast you wrote: EOTFAST is released as open-source under the Apache license. Where can I find the source code?

Jens

I'll believe it's a dessert wax and a floor topping when I've got my hands on it and tested the in and out puts. :)

Cheers!

>Rich, I commend your efforts, but IE is not the future of the web.

This is kind of like saying the future of transportation is not the internal combustion engine. You're probably right, but IE is going to be around for many, many years. IE6 still has more than 20% market share!?

Rich, it seems to me that what you have done is to produce an EOT-creation tool that is easier to use that WEFT. Now, for sure, the relative complexity of WEFT is one reason why EOT never took off in the decade in which it has existed as the @font-face implementation in IE, but it's hardly the most significant reason.

I don't understand why you have made a tool that avoids the (to other browsers) contentious URL-binding aspect of EOT while implementing the equally contentious patented compression. The latter, as well as your commentary, makes it clear that EOTFAST targets IE only, since only IE supports this compression. But IE also supports URL binding, so why have you disabled that?

You're right, Si. I should clarify: the future of the web will be seen on many browsers. Support for only IE won't cut it.

>You're right, Si. I should clarify: the future of the web will be seen on many browsers. Support for only IE won't cut it.

Agree. Also on many different devices with many different types of display and rendering styles.

First, more technical news:
Garrick Van Buren has converted Kernest's entire font library using EOTFAST plus - and this one has *me* amazed and astounded - he reports having found an answer to the problems of reliable gzip delivery for fonts of any kind.
More Gzipper Than Ever
Problems with gzip discussed here:
Who's Not Getting Gzip

@jens
>This may be just marketing-speak
No. I'll write sales puffery like anybody else, of course, but something quite that bold, no.
They're obsolete.
>to allow other browser vendors to implement EOT support without any patent issues
Correct as regards EOT Lite. But frankly, EOT Lite seems dead in the water as part of a W3C standard. It's mentioned as an aside in the current web fonts charter proposal.
EOT is the old soldier that we'll have to care for until quietly fading away.
I do not know exactly what is planned for IE9 other than continued support for EOT as a backwards-compatibility legacy thing.
"Don't break the web", meaning, as far as possible, continuing to provide support for existing web pages is an article of faith for the IE devs. People can bitch about conditional comments and versioning strings as much as they want but there'd be a lot more bitching if IE didn't have them. If Firefox pushes out an upgrade and there's a regression in the code, what's the problem? Not a lot. If it was IE, you might not be able to make a withdrawal from your bank. There's a huge disparity in the level of responsibility required which, unfortunately, a lot of people in the web community don't get. I'm interested in seeing if there's any unwanted side effects in the European market in the short term. Interesting.
>Where can I find the source code?
It will be posted but I can't tell you exactly when. On Github or Sourceforge or somewhere. The source for Version 2 will hold much more opportunity for collaboration and I'd rather wait until then. I do feel a responsibility to make sure that the basics are solid, first. I don't know of anybody who's done as much hard research as me and there's a lot more to do, too.
There will be an announcement and a mailing when that happens.
In the meantime, the executable is there for the asking. You're welcome. Will you be using WEFT again in the near future?
>Why? Tools for web font conversion have already existed for some time,
>for both WOFF and EOT.
Implementations, man, implementations. Half a billion or more users can benefit from EOT in IE now, today. FF 3.6 was just released so the pool of users who can benefit today from WOFF is indeed small.

@johnhudson
>one reason why EOT never took off in the decade in which it has existed as the @font->face implementation in IE, but it's hardly the most significant reason.
Oh geez, you've got me singing the song "Turn, Turn, Turn" in my head, now. (Go ahead, all together, now - I'll give you minute...)
Bandwidth, bandwidth, bandwidth. At the time of what I call "Pax IE" when IE6 ruled the roost with no competition whatsoever, it was still largely a dial-up world. Let's not forget how much has happened in the last five years. In this case IE was ahead of the curve. It happens. Even in Redmond. I know it sounds simplistic, but it was just a case of other web development techniques having a greater priority.
As far as URL binding etc.... you're leaving me wondering what on earth we were all gnashing our teeth about last year. Was it a dream? ;) Your questions are reasonable, but let me get back to them.

@stephencoles
>the future of the web will be seen on many browsers. Support for only IE won't cut it.
It sure won't. And you can't cut it without IE, either.
Bottom line: Both EOT and WOFF offer a way to wrap a font file without the encumbrance of root strings and with highly effective compression. In effect, there isn't a whole lot of difference now between the two.
I have gotten the distinct impression that a case was being made that IE's @font-face implementation was in some way fatally flawed, and that the font design community therefore had no choice but to wait until IE caught up before offering licenses under WOFF while avoiding EOT and the huge user-base that can benefit from it.
Now, in light of EOTFAST, what's the diff?
There will be convenient, easy to use tools for both formats.

@stephen

>Rich, I commend your efforts, but IE is not the future of the web.

I won't go near the claptrappery of a phrase like "future of the web".
But there's this:
Oil is not the future of humanity's need for sources of energy.
I guess you'll be keeping your car in the driveway until that happens, eh?

;)

My point is: you need both — EOT and WOFF — for the greatest compatibility right now. That’s why the Web FontFonts released today come in both formats.

No, the two formats you need right now are EOT and desktop fonts. You don't need WOFF for compatibility at all. Web FontFonts are in EOT and WOFF because nobody wants to license desktop fonts to end users for direct web use.

Don't get me wrong: I'm convinced that WOFF will be the format of choice in a few years. But right now it's only supported by Firefox 3.6, so it has a long way to go still.

Cheers,

T

> Nobody wants to license desktop fonts to end users for direct web use.

Right. Making that point kind of moot, no?

Not moot... it explains why services like TypeKit are relevant; licensing for EOT+WOFF without desktop fonts misses ~23% of browser users who are on Firefox 3.5 or Safari 3.1-4.0. (Admittedly, that percentage is doubtless decreasing rapidly as Firefox users migrate upwards, with a floor of about 4% Safari users.)

Of course, there's also another ~8% using browsers that don't support any version of @font-face, basically Chrome plus assorted mobile browsers.

Cheers,

T

Chrome does support @font-face.

It sure does.

Rich, what does EOTFast do when it meets a font with an embedding bit IE does not like?

Cheers!

hmmm?

@dberlow

>Rich, what does EOTFast do when it meets a font with an embedding bit IE does not like?
In version 1.0, it converts the font into an EOT and then that EOT does not work in IE because IE itself declines to load it. This will happen if the embedding is set to "restricted". Whether the EOT is working can be immediately confirmed using the EOT Test page that's a part of the package. Although the test page will not tell you what the nature of the problem is.
In version 2.0 (in Beta), there are user alerts as the conversions take place, telling you exactly what potential problem(s) there might be and restricted embedding is one of them. This is a stop error. No conversion. No point in allowing it to go forward - IE won't load the file.
I considered the idea of checking for a vendor ID of "FBI" and then changing the permissions to allow for embedding but decided against it. Instead there's just a pop up saying, "Google: 'Fonts NBC'". (Just teasing, David.)

EOTFAST is about assisting in the creation of working EOT files. No more, no less.

That answer your question?

rich

Ah, true enough, Chrome 4 supports @font-face at last, been about three weeks now. Anybody know if that's only TTF/OTF, or does it also include WOFF?

T

@stephencoles

>That’s why the Web FontFonts released today come in both formats.

IMHO - that's what must be standard practice for the foreseeable future.
And I'm really glad to hear it.
Yes, it's more work on the back end - conversions and so forth - but show me a way around it. There just isn't any.
"Waiting For WOFF" isn't a viable strategy. What if the rest of the world decides not to wait around with you?
WOFF is just a transport wrapper that adds nothing to intrinsic value of the font. And it will take years for it to take hold.

@tp
>No, the two formats you need right now are EOT and desktop fonts. You don't need WOFF
>for compatibility at all. Web FontFonts are in EOT and WOFF because nobody wants to
>license desktop fonts to end users for direct web use.
Completely accurate. Although I'm not following the "desktop fonts" and relevancy of Typekit thing in your other comment.

Font services will make sense for a lot of users as long as integration into the page is an easy thing and the fonts look good. Somebody with a freebie Wordpress blog doesn't want to fuss with fonts. Just add some spice to the page.
As far as the fonts looking good - whole other discussion.

Based on this thread I am changing my EULA to be more permissive about some of this stuff. What do people think of the following:

You may not make the font available via the internet either by linking or embedding except as specified below. “Embedding“ and “linking” include, but are not limited to, Typeface.JS, Cufón, sIFR, and directly linking to the font for use with the CSS @Font-Face tag.
II. You may embed the font into an electronic document, such as a PDF file, provided that document allows no editing using the font.
II. You may embed the font into a web site using Flash only if the text contained within the Flash file is static and users are not able to create content featuring the font.
III. You may use the font with software that automatically generates bitmap or vector images, such as Typeface.JS, Cufón, sIFR, and FLIR, provided that you purchase a license for each computer running the software.

It's like you shouldn't put a hard-and-fast dated EULA in a font package (which will be "on the shelf" at distributors for years, and they won't want to be constantly updating), but rather a link to a EULA that's current at the time of purchase of the font. Versioned EULAs.

>In version 1.0, it converts the (any) font into an EOT...

any font then? regardless of what the foundry set the embedding bit to?
(why did you have to release 1.0 first? what's the rush that's put your speeding tricycle in front of the train?)

>EOTFAST is about assisting in the creation of working EOT files. No more, no less.
... just as a handgun is about chemically assisting matter to supersonic speed. No more, no less.

Cheers!

Chrome 4 supports @font-face at last, been about three weeks now. Anybody know if that's only TTF/OTF, or does it also include WOFF?

No WOFF, it's working just as Webkit/Safari.
http://www.webfonts.info/wiki/index.php?title=@font-face_browser_support

Apart from Mozilla, no other browser maker seems to be very interested in WOFF at the moment.

@all

Re: Fontshop's Web FontFonts initiative which I was just looking over.

http://www.fontshop.com/blog/?p=1763

They are saying that EOT Lite and WOFF will reach 90% of web users.
This number is incorrect. It is therefore misleading.
Plus, the introductory sales copy ignores that Safari users and Chrome users will not get the fonts since neither EOT or WOFF are supported in either browser. I find this a step beyond putting a good face on things.

Their technical document:
http://www.fontshop.com/blog/newsletters/pdf/webfontfontuserguide.pdf
also has critically flawed information regarding best-practice CSS syntax and very, very incorrect information regarding Internet Explorer's @font-face implementation.
Flat-out wrong.
Misinformation dispensed from a major font site doesn't do web users, font designers, or anybody any good.
I find this very disheartening.

I urge them to either remove that documentation entirely or mark it plainly as being severely incorrect in parts and under revision.

rich

@thomas phinney

Aha! Sometimes I'm slow. "Desktop Font" = euphemism for TTF or OTF delivered raw, naked, and steamy - but chopped up. The way the Russians like to eat 'em.

As for Chrome - reported on Dec 12, 2009:
http://readableweb.com/font-face-works-automatically-in-new-google-chrom...

TTF/OTF support has been a part of the current version for quite awhile now.

No WOFF.

"They are saying that EOT Lite and WOFF will reach 90% of web users."

No they say that IE + FireFox = 90% of Web visitors which is close to being correct. Of course this avoids the fact that there are versions of FF that don't support WOFF.

>Re: Fontshop's Web FontFonts initiative which I was just looking over.

Yes Rich, but it's all legal handling of their IP. You have a problem with that, which should be solved before you start tossing tummy chuck on other efforts.

>I urge them to either remove that documentation entirely or mark it plainly as being severely incorrect in parts and under revision.

And I urge you to remove your infantile software, or mark it plainly as being dangerous to the legal status of its users. :-)

Cheers!

@Richard: Yes, that's what I meant. Glad you figured it out, because I didn't understand what it was you didn't understand. (Heh, how's that for a twisted sentence?)

@Si: Hmmm. Good point. That would be marketing!

Cheers,

T

@thomasphinney

In keeping with your observations - what Fontshop is doing with the Web FontFonts initiative is called a "bait and switch".
I've studied the advertising styles of the early to mid 20th century closely and in so doing developed a soft spot for hucksterism like this.
(It is today, however, generally illegal. If the customer is "baited" to sign on using false claims and then "switched" to something that's going to cost more. I'd have to look closer to see if that's the case here. But I really don't care.)

Works like this:

1) First, you suck the customer in with what seems like a perfectly reasonable, even juicy offer. 90% of browsers supported! Specially optimized fonts! (Not sure if there's anywhere to actually preview what they look like in the browser on Fontshop - I couldn't find it.) Anyway, at first, everything looks great.

2) Turns out there's a catch that was not immediately apparent - in this case its that fonts formatted in EOT and WOFF won't show up in Safari or Chrome. (You mean I can't post the TTF?) Of course, no web designer is going to want that and so the customer is steered to the "free" Typekit hosting option as a solution. (A solution to a problem that was created by the nature of the sales offering in the first place, of course. Wink. Wink.)

The Typekit hosting service is what's being sold.
The "Web FontFonts" is just a way to steer the customers to it.
(Check close and think about it. Unless I've missed something fundamental, you'll see I'm right.)

Of course, the more trustworthy the source of the offer - Fontshop! - the less likely the customer will be on the lookout for gotchas, so the better it works.

Slick! If Bryan Mason thought of this - Bryan my hat is off.
I thought this kind of marketing went out with the aluminimum siding salesmen characterized in Barry Levinson's classic 1987 comedy "Tin Men" but I guess there's a revival going on.

I'm really starting to like the font business a lot.

Rich

Rich: Unless I've missed something fundamental, you'll see I'm right.

I know that you're wrong, so you must have missed something fundamental. Actually, I'm having a hard time keeping track of how many fundamental things you missed. How about this for starters: we're at a transitional moment in which new licensing businesses are coming along in the midst of inconsistent format support. There is absolutely no obligation on any vendor to provide their fonts in all supported formats in all browsers, and if, in light of the inconsistent support, companies try to provide temporary alternatives to customers who feel they need to implement their designs across more browsers than support the formats offered by those vendors -- any my own customers have indicated that they feel no such need --, that shouldn't be grounds for suggesting that such companies are affecting a con. Frankly, if I were FontShop, I'd be asking my lawyers to review your last post for a possible libel suit, since you have accused them of something that you acknowledge is ‘generally illegal’.

Not long ago, you were jumping up and down demanding that font vendors start licensing fonts for the web and to make clear in what formats they intended to do so, despite the fact that I, for one, thought ‘What's the rush? The browser support isn't where it needs to be yet.’ Now, one of the most respected and successful font vendors is doing just what you demanded, and you are accusing them of doing something both else and nefarious.

This seems to me a grossly unfair detraction.

@Richard: It may have been a simple mistake as well. I agree it's misleading, but it could be easily corrected.

Like John, I don't assume that offering Web FontFont licensing directly (from which FontShop gets all the revenue, and owns the customer relationship) is intended by FontShop as a bait-and-switch to get customers to sign up in a paying relationship with TypeKit (in which FontShop gets some smaller cut of revenue, and somebody else owns the customer relationship).

The direct Web licensing of fonts, with a one-time fee and a sliding scale of that fee based on volume, is simply a different model than web font service rental. The web font biz is in a wild west frontier mode right now, where people are trying to set up new settlements all over the place, and we don't know which ones will attract settlers. In 50 internet years (7 real years), will it be Deadwood, Los Angeles or San Francisco that becomes the thriving metropolis? Quite probably multiple things will succeed, and almost certainly not all of them will.

Cheers,

T

@typodermic
> My solution will be to require that the obfuscated font be used for FLIR.

Before you do that, let me release an updated version that prevents direct access to the fonts folder with an .htaccess file. This will mean that no file will be able to be downloaded from anything in that folder (even if you can guess the filename). The user will receive a "Forbidden" message when trying. Let me know if this is not satisfactory, because I'd be happy to change to make it so.

I'm not sure why a randomly generated filename for font-face is a better solution. I can just parse the stylesheet and find out the exact filename? Unless I'm missing something?

> The price for use on a single domain is exactly the same price as a regular font license so it should be okay.

I applaud this. Thank you.

===

What is the point of WOFF? It really seems like a joke from where I'm standing. It looks like a fancy gzip compression library with a bit of easily breakable DRM thrown in to make you guys feel good.

WOFF is to the web font world, what taking your shoes off while passing through airport security does for making flights more secure here in the states. It makes for good theater and gives you a warm feeling inside, but it doesn't actually do anything.

Anyone who is determined enough to get a font will be able to break WOFF, just like they'd be able to break any other method. The problem is that at some point, the font has to return to a font to be used by the OS, and it is at this point that it can be grabbed, saved, and reused -- whether it be from a cache file, RAM, or specially crafted software.

If typeface designers are looking to WOFF, EOT or any other of these technologies as being the holy grail for getting their fonts embedded in a safe way on the web, then they are sadly mistaken.

If history has taught us anything, DRM is pointless. Someone is going to break it, and then release a program to make it easy for others to do the same. The only thing DRM does is make it more difficult for legit users to use your product. This is the inherent problem with DRM. In order for the enduser to use it, some bit of software has to turn it from DRM'd file -> Regular file, and if one program can do it, some other program can and save the data locally in the process. Even the movie industries with all their might cannot release a DVD with DRM that isn't easily broken.

I am going to say with a certainty -- right now, and forever -- that there is absolutely no way to protect your IP from theft. Period. The only thing you are doing by pursuing these technologies is making it more difficult for legit users to implement your fonts. And the more difficult it is, the less likely it is that I am going to do it -- and I'm happy to not buy your fonts, and make my life easier.

Cory, the key benefit of WOFF (or any wrapper format for web fonts) is that it makes a distinction at the licensing and deliverable level between a desktop font and a web font.

...with a bit of easily breakable DRM thrown in to make you guys feel good.

If you'd followed the W3C font list discussion, you'd know that there is explicitly no DRM at all in WOFF, so talking about WOFF in terms of DRM makes no sense at all. What there is in WOFF is optional metadata. There is no obligation on browser agents to do anything with this data; hence, it doesn't constitute anything like DRM. You would also know that none of the font makers who support WOFF have ever imagined that this wrapper protected their IP against deliberate theft and unlicensed exploitation. Rather, the wrapper protects against casual misuse of web fonts as desktop fonts and provides mechanisms, including use of metadata, to help font vendors and their customers who do want to respect licenses.

@johnhudson
I know that you're wrong, so you must have missed something fundamental.
How do you know I'm wrong. You have not refuted a single fact I put forth. Representatives of the Fontshop are perfectly free to post here and bolster their sales claims. Where are they?
They can come here and explain how many web designers of sound mind they expect to license their WOFF and EOT files when it means the fonts will not show up in Safari, Chrome, Opera, or Firefox 3.5.
I'd love to hear it. And since you are standing up as proxy for them, perhaps you can explain it.
Please explain it.

Regards,

Rich

Rich, you accused FontShop with Typekit of a deliberate bait-and-switch marketing scheme, as if somehow FontShop's refusal to license their unwrapped desktop fonts for web serving were some kind of ploy to push customers to using a service like Typekit's. As Tom pointed out, that doesn't make a shred of financial sense for FontShop, since they would make more money from licensing the naked fonts direct to customers than they would from having those same customers go to Typekit.

They can come here and explain how many web designers of sound mind they expect to license their WOFF and EOT files when it means the fonts will not show up in Safari, Chrome, Opera, or Firefox 3.5.

And your solution to this is that FontShop should give in and license naked desktop fonts to be served on the web? Should font makers bow to as yet non-existent customer pressure rather than continuing to exert their own, so-far-so-successful pressure on the non-IE browser makers to support a mutually acceptable wrapper format? Sorry, Rich, but to me it looks like a no-brainer. You don't surrender when you've already won the first battle and the next opposing army hasn't actually arrived on the field yet.

>Should font makers bow to as yet non-existent customer pressure...

Is "as yet non-existent pressure", a double negative? or entertainment?

Cheers!

@john hudson

And your solution to this is that FontShop should give in and license naked desktop fonts to be served on the web?

No, that is not my solution. Don't put words in my mouth, please. My solution is straighforwardness and honesty of approach. Tell it like it really is. Tell your customers what you're really selling. Tell them that they won't be able to reach 90% of browser users that it's more like 75% max. Tell them they won't reach Safari, Chrome and Firefox 3.5 users. And thell them the reason they can't is because they won't be provided with the TTF needed to do so. And so therefore, they must turn to Typekit. Like I said, it's OK by me. (I'll keep saying it, but it doesn't seem to be sinking in.)

I am absolutely stunned by your answer. You haven't denied that the situation is exactly as I've described it. But you've said that it's OK because as long as it involves IP, less than straightforward marketing is perfectly justified. Fontshop belongs to a privileged class that justifies low ethical standards in its business practices.

I really wish you hadn't made that argument, John. It's very, very twisted.
To borrow a line from a Marx Bros. movie - How much do you charge to *not* come to someone's defense?

Regards,

Rich

Rich, maybe I missed some place where FontShop were claiming that their webfonts supported 90% of browsers. Isn't that a typical advertising over-estimation, kind of like claiming that your EOTfast tool renders all others obsolete?

Seriously, I don't think FontShop are being deliberately misleading and I don't think they're setting a low ethical standard. I think they are introducing a new product into an emerging market with no precedence, and will probably make some mistakes in the process. If you disagreed with the information that they presented, did you write to them and suggest how it might be improved or clarified? Or did you just jump straight in with the public accusations that they are being unethical and performing a perverse bait-and-switch operation?

If you are genuinely interested in straightforwardness and honesty, enough with the ‘absolutely stunned’ and ‘very, very twisted’ hyperbole. We're having a conversation, and your over-excitability is making it very difficult.

> How much do you charge to *not* come to someone's defense?

...an interesting question from someone publishing a DMCA-violating "product".

How much you got? Or should we wait to go after your "clients"?

Heads I win, tails you lose?

Cheers!

From 24 October, 2009:

http://typophile.com/node/63451.

Not sure if there is any place/person here that keeps a running list of this as it grows. Interesting times to say the least.

Ahh, just for the fun of it:

@davidberlow
...an interesting question from someone publishing a DMCA-violating "product".

You must have me confused with the Mozilla Foundation, or Apple, or Google. Can't you keep us titans of the industry straight?

@johnhudson

Here's the sales copy from Fontshop - anybody tuning in can use their own built-in BS detector and judge for themselves:

They work on most major browsers. Web FontFonts are delivered in EOT Lite and WOFF, the two formats supported by the most commonly used browsers: Internet Explorer® and Firefox®, covering more than 90% of all web visitors. We expect other browsers to join in implementing WOFF soon. A free Typekit hosting option extends compatibility to Safari® and Chrome® users.

Nice weasels. Couldn't do better myself. Now, if this isn't meant to create the impression that Fontshop is providing, with those two files, a solution that covers 90% of all web visitors, well I'll be darned. Caveat emptor.

As has been noted already - even at a stretch - one in four "web visitors" will not get the fonts using those two files. If their copy read "most web visitors", I would have nothing to say. But they know 90% is innacurate. And that the true number is unacceptable to prospective customers. This leaves Typekit as the product. (Unless they're hoping to do a Berlow and waiting to see if the customer will convert the WOFF into a TTF and then put the screws to them.)

The notion that those two formats are a complete solution is bolstered by the following on the 'how it works' page:
Both formats are delivered with every Web FontFont purchase and can be used without relying on any third-party service.

Is it a bait and switch? Absolutely.

In the final analysis, there's no getting around one thing: they're selling a product - meaning the EOT and WOFF files - that don't meet any ordinary customer's expectations.

If you want to parse sentences and make excuses, go ahead.

There's more I could point out, but I'm past the point where it's interesting.
Besides, some of it is technical, and I'll deal with that elsewhere.

Rich, I'm surprised you are not clear on this.

Your product's sole purpose is DMCA violation. Your user's use is copyright and TM violation.
Users who convert from web to desktop format, we'll get to a in a bit.

Cheers!

Rich: …the true number is unacceptable to prospective customers.

Is it? You reckon its 75% at best; I reckon it is currently likely to be quite a lot less than that, since FireFox users will need to be running the latest version. Yes, FontShop's ‘more than 90% of all web visitors’ (which, note, is not quite the same thing as 90% of browsers) is well premature. [Again, did you think to contact them about this, or did you jump straight in with the public accusations of unethical and possibly illegal behaviour?] Whatever the actual current percentage, I question your assertion that the true number is unacceptable to prospective customers. x% (easily more than 50% and most likely increasing) is surely better than 0%, and if web designers aren't aware and capable of the need for and provision of reasonable font fallback in browsers that do not support the licensed formats, well, they aren't web designers.

Related to WOFF market share - Mozz will be pushing 3.6 on users.

http://www.geek.com/articles/news/mozilla-pushing-firefox-3-6-to-acceler...

Also just announced IE9 Developer preview...

http://blogs.msdn.com/ie/archive/2010/03/16/html5-hardware-accelerated-f...

For those interested in how IE9 will render type.

Cheers, Si

Yes, please take a look at IE9 developer preview. I promised screenshots some time ago, but when I came around to prepare some it was too close to mix to steal the show from Dean. Tell us what you think.

Thanks,
Sergey

Side by side of an unhinted font in IE8 and the preview of IE9...

From this old EOT demo I made 12 years ago... http://www.microsoft.com/typography/web/embedding/demos/9/demo9.htm

Si, do you have any demos that show black text on a white background?

It would also be nice to see a comparison of CFF rendering in IE8 and IE9.

Not CFF - but a couple of other examples...

This is Garamond Pro, D2D vs. GDI:

This is really impressive.

If it only were a Firefox renderer... :)

Firefox announced that they would likely be moving to DWrite just ahead of ATypI last year, and I think its implemented in recent minefield builds.

Cheers, Si

Thanks, Si and Sergey.

Si, in your ‘Daring Direball’ example, is that still GDI on the left and DW on the right? If so, that's the first example I've seen where the DW rendering is considerably worse than the GDI: very fuzzy and lots of colour artefacts. Of course, some of this can be attributed to differences between how the screenshot appears on my screen vs. looking at the live rendering, but I wonder what other factors might be involved re. the particular font, choice of background colour, etc?

Let's hope sergeym's got it right with DW2 on the left, and getting darker. The way John showed it on his specimens looked a lot like the refrain from a famous Procol Harum song.

Cheers!

a whiter shade of pale, indeed.

>Si, in your ‘Daring Direball’ example, is that still GDI on the left and DW on the right?

Yes all my samples are GDI (IE8) on the left and DWrite (IE9) on the right. We're certainly aware of places like this where text/background color combinations are producing interesting results, and the CT team are looking into this.

@ R.Fink
Representatives of the Fontshop are perfectly free to post here and bolster their sales claims. Where are they?

So we have to follow all discussions about our products in the web? Will you pay the staff? Sometimes we are following the threads on Typophile, sometimes not. If you want to make sure you will get an answer, please ask us directly (in one of our blogs for instance, as you already did when you wanted to know why we don’t use EOTFAST …)

They can come here and explain how many web designers of sound mind they expect to license their WOFF and EOT files when it means the fonts will not show up in Safari, Chrome, Opera, or Firefox 3.5. I'd love to hear it.

We expect quite a few. We offer a solution that will work for most web site visitors at the latest in a couple of months hopefully (WOFF/EOT). We also offer a solution that works now for most web site visitors (TK). I think this is great. And quite a few customers already thought so too.

>...a whiter shade of pale, indeed.
You know that it was written for a girl named Claire Schrift?

And I was wrong, Sii is right, serif fonts are getting lighter, sans are getting bold.

I have this theory, that someone is so sick of type,
it'll just getting lighter and lighter until one day pffffffzzzzzt!
not quite that loud, but all the Windows serif type under 12 point will be gone.
then a few years later, the sans. They'll keep Comic Sans and that
De Vinci thing just to taunt aging readers. ;)

Cheers!

God! Then even Squeeze and Boulder will become wimps :-(

Note that Si's and Sergey's illustrations are inconsistent: Si has the GDI on the left and the DW on the right; Sergey has it the other way around.

CFF fonts will almost always get heavier with DW rendering, as Sergey shows, since GDI CFF rendering is notoriously skinny.

So Procol Harum is bumped from the top of the charts by the old union song "Which Are You On" ;)

But what's the point of CFF? I note that none of the examples, except for the "Daring Fireball", are intended for reading on screen, being either too big or the type selection is too weird. Is someone out to improve wysiwyg performance?

The readable "Daring Fireball" is most assuredly not a comparison of CFF being rendered, is it? The left is way too good for CFF, it looks like a live web site. The right is 1/2 way from the left side towards Quartz, (i.e. wilderness training for readers).

Is there a place in the machine I can kick the side and get it a little darker?

Also, not just rendering changes are hap'nin, in John's blowups of Sergey's, there is a huge difference between the forms of m in the regular on either side. Different fonts. Is this the same data, the same size and untampered? Also note, the left's word "dolore" the conflict between l.c. o's vs. between the two o's on the right. This signals the need for a White Paper on it's hinting interpretation, or is it just y hints now?

It's probably waaaaaay too late for scientific testing, but if you want to see what it'll look like, you've got a browser, are willing to set de browser to Actual Size, forsaking html scaling for my neat little buttons — you can always bounce it off perfection in all possible weights to the 1/2 pixel ;)

Cheers!

>I note that none of the examples, except for the "Daring Fireball", are intended for reading on screen, being either too big or the type selection is too weird. Is someone out to improve wysiwyg performance?

First example was the only one I had handy to show an unhinted font - second two were in response to John's request (which i initially read as white on black, hence the DF grab) - I could have just said "download IE9 and look for yourself" but I'm not that rude.

Thanks for all you help Sii, I thought this was still in the incubator.

Cheers!

No problem, download link here...

http://ie.microsoft.com/testdrive/info/ThankYou/Default.html

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