I wanted to chime in with a few important points in response to the comments on Bill Hill’s post over on the IEBlog.
There are a few people who are fundamentally missing the point: for example, user kL who comments: “Please, don’t push this crappy format. XORing of files is not a legal solution.” Actually, kL, EOT is a legal solution – the EOT format was specifically on the table when the “embedding” bit in OpenType was designed, and font foundries know what it does and how. And by-and-large, they’re happy with it, or they turn off the embedding bit, and then EOT will not work for that font.
kL goes on to say “We can already break law/leech bandwidth by (hot)linking copyrighted images, copyrighted MP3s, etc. Fonts are no different and DRM won’t help here a bit.” You’re quite right, kL, that this will not prevent lawbreaking. However, it DOES give a way to LEGALLY use commercial fonts (those that allow embedding, anyway); directly posting the .TTF or .OTF file on your web server will violate your license for commercial fonts (okay, perhaps there are some fonts out there somewhere that allow this in their EULA, but I’ve never found one.) Linking to raw .TTF/.OTF files WILL, in fact, encourage font piracy, as vastly more commercial fonts will be placed (unadorned) online, where they can be easily pilfered.
Perhaps I should ask Apple how happy they are if I post their fonts on a web server?
[A side note to the inimitable Joe Clark: I’m not actually the head of the browser team. Just some guy with a perverse passion for doing this. And it wasn’t just “clean this up and make this validate” – it was more like “Bill, you can’t ship this crap that Publisher spit out. Let me show you how you’re SUPPOSED to code…” followed by one late night, and then I had to drop it to focus on something else. I’m still hoping to finish the clean recode this week.]
By the way, I don’t particularly care that Acid3 uses direct linking to TTF files; that just goes to show that it is duplicitous to make a “standards test” that tests things that are only Working Drafts of low priority to the working group (as per the CSS WG’s table of priorities). Trying to circumvent the standards process by throwing whatever test you want into a so-called standards test won’t make us implement anything faster.
I’ve been clear on this to the CSS WG, so I suppose I should be here too – we (Microsoft) should NOT support direct TTF/OTF embedding, unless 1) there is some check that the font intended that use to be allowed, which I don’t think there currently is (as it needs to refer to the license agreement), AND 2) other browsers also implement a system that actually ENABLES commercial fonts – those that are allowed to be embedded, but cannot be legally placed directly on a server – to be used.As I also stated to the WG – I don’t personally even care that much if that system is EOT as it is today; I’d be okay with building a new system if the details of EOT were a sticking point. But I want to use commercial fonts on my web pages, I want that to work interoperably across browsers, and I want to not have to violate my license for the fonts I use (and get sued for it) in order to make that happen. A solution that only works for freeware fonts is not a solution.
Is that too much to ask?
in progress 
Point blank — when I purchase the Linotype foundry for ten grand, I will use their fonts in any communication medium that I deem necessary. To hell with their EULA. The foundries et al had better get their act together, recognize changing market forces or suffer, for example, the problems and hits that the recording industry and RIAA have faced.
I get it (almost).
What I don’t get, is how this is happening. This looks like an “oh crap, just like the RIAA/MPAA Folks, we need to lock down media (our fonts) with DRM!!!, please help us Microsoft so that we don’t need to adjust our faulty business model!”
I fail to see how this is something that should be handled by the browsers? They should simple get and serve content. Plain and Simple.
Thus TTF fonts (that hmmm, we’ve all been using for like… forever) seem the logical choice.
Now, if company “A” decides to host, and serve up an unlicensed version of “SuperFontX”, then the true owners of “SuperFontX” can go send C&D orders to the site, sue / settle with them, or take whatever action they want.
I’ve yet to find anyone (outside of the financial pockets of MSFT, and their partners) that feels that DRM of any kind is a good thing.
I will *NEVER* encode/buy any of my music in a DRM based format (locked or otherwise), thus why would I want to “buy into” yet another DRM Locked format for fonts?
If you are the manufacturer of old-fashion typewriters, I’m sorry, but times have changed, you can’t complain (to anyone) that computers are your businesses downfall. The times have changed, the market has shifted, you’re just plain out of luck. Bite the bullet, chalk up the experience to a learned lesson, and move on.
“2) other browsers also implement a system that actually ENABLES commercial fonts”
I think you killed Bill’s project right there.
I don’t think you guys are protecting a business model as much as you’re trying to create one.
I agree with you that we do need a system that “actually ENABLES commercial fonts”. What I don’t get is why you think it’s necessary that a check be in place for embedding fonts otherwise. You don’t check for copyrights on images in IE, do you? You don’t check to make sure that web page content hasn’t been scraped and illegally pasted onto another web page. This is the author’s responsibility, not the user agent’s.
@thacker I wish you all the best. Have fun getting sued. People who sell things for $10k tend to care about what you do with it.
@Jeff saying “why is this necessary, since this similar thing is already broken” isn’t a good excuse. If I could get high-res image previews of art online before I purchase, rather than crappy low-res versions, I would think that would be a good thing; but vendors can’t put those high-res versions online, because they would be pirated. Same with audio; if I could get a full song preview online, rather than a ten-second preview, I would think that would be good; but I can’t, because Amazon isn’t gonna give me that for free (even though I can buy a non-DRM version.
The easiest way to pilfer fonts is to download thousands of them at once. Sorry.
@Jerome, @Timothy – please go think for a moment about how fonts are created, and how costly an endeavor this can be for a really good font. Now go consider what happens to that market when if every font they make can be freely linked to from another location. I don’t even need to copy the file onto my server; I can just link to it. *I* am not doing anything “wrong” – but the person who bought a license, and wanted to use it on their site, *IS* in fact violating their license.
Here’s the thing I don’t understand: The EOT file has the font data embedded in it in an unencrypted form. EOT seems like a very mild obfuscation instead of DRM. Just like WEFT converts TTF files to EOT files, somebody can and will create a tool that converts EOT files to TTF files, or converts an EOT with one set of root strings into another EOT with different root strings, or one with a different set of embedding permissions. EOT isn’t an effective piracy prevention mechanism.
People are so focused on the (ineffective) DRM aspects of EOT that they are overlooking its technological benefits. In particular, the EOT file can contain a very small subset of the original TTF, making the download much faster. Cambria’s TTF is over 1MB and Asian-language font files are frequently over 5MB (often 10MB+) each. If you need a font for a headline with a few Asian characters, or if you want just the digits from some typeface, then the EOT file with those characters is going to be much smaller than the original TTF. On the other hand, I think there are already tools to extract characters from a TTF into another TTF, so maybe EOT isn’t necessary for subsetting.
If the true point of EOT is just to make font piracy slightly inconvenient then maybe a low-tech solution is sufficient: have IE refuse to download fonts that end in .ttf/.fon extensions (in the URL and in Content-Disposition). Then, when people upload their fonts they will have to change the extension. If a person tries to casually download the file then they will have to manually rename the file before they can install the font, instead of being prompted to install the font as soon as they click on a link to it.
…hmm.. I actually have no idea how many (hundreds of?) thousands of fonts I have in just 1 of my fontdawg isos…it’s so many it’s just a daunting idea to look through them. But if people suddenly started using any font the wished on their site (EOT, ttf, otf, whatever) I could actually see these fonts used in context and then be influenced to use that font myself and I could just look in the css to see what the font’s named and enable it in my font manager… nice.
Another note: Just how would the licensing work? Do I buy a license to use per site? per # of viewers?
If your site gets Dugg, are you all of a sudden in financial peril?
This business model for fonts seems like a Titanic disaster waiting to happen.
@Timothy the licensing model is already set – font foundries enable or disable the viewing/printing embedding, separate from “installable” embedding. Full stop. No per-copy license.
@Anne Bonny – that just sounds to me like “hey, it’d be good if we let site authors use lots of custom fonts.” Yes, please.
Lets assume no commercial font comes with a license that allows it to be used on a webserver/embedded via url. So anyone wanting to use that font on their site, even if they already owned it, would have to pay another small fee to the font creators.
How about the font cretors themselves host the web version of the fonts (or font subsets) and people who want to you them get an account with them and register the domains we want to use the font on for a small fee. (Let google or yahoo handle all the technical stuff for them so we have a reliable place to link to (and the caching benefits) )
A special font is as important to the design as a special photo. We often pay istockphoto/getty/etc for that 1 perfect stock photo to solidify our designs. Why not treat fonts the same?
Lol, my idea is so flawed.
I’m bored. I’m hungry. I want pizza.
yes, I’m going for pizza. bye-bye internet.
see you tomorrow
!*smooches*!
@Anne Bonny – the flaw in your reasoning is that most commercial fonts today explicitly allow embedding via EOT. So you don’t need to update your fonts or pay any fee. The cross-hosting feature you mention would be costly in infrastructure, though it would work.
Save some pizza for me.
a potential additional revenue source for foundries might be to allow custom fonts to be generated that only contains a subset. They could charge an extra fee for this while also creating some incentive for others to just download and place on their own sites since there’s a likelihood that it’s missing outlines that you might need. I can see both sides of the argument but I think foundries have ways to take advantage of the situation.
@Jonathan Snook – commercial font foundries are unlikely to ever move to licenses that enable the placement of their TTF/OTF files directly on web servers. Subsetting is nice, but in a world where content is frequently dynamic (vs. the static content of a decade ago), it’s less useful in the “you might be missing a few letters of the alphabet” sense.
Subsetting is fantastically useful for Far East fonts, of course.
How long before some firefox add-on allows you to rip embedded fonts in websites… like that youtube video grabber…
Many fonts sold today are over 50 years old… some are over 100… Under United States law, typeface designs are not subject to copyright…
The reason they can sell you the font is because they give you a computer file that embodies it… it is sold to you as a computer program. If I were to just “rip” the font and re-encode it in a new EOT, that would be perfectly legal.
I’m not saying there’s no room for font foundries that actually create new fonts to sell them just that the font business has major issues, that the sale of fonts for the web is not currently a business model. That is what I mean when I say that you are not protecting a business model as much as creating a new one, in conjuncture with Ascender Corporation. I’m sure before it actually becomes a standard there’s going to be many people from that industry with something to say on the topic… I just hope we’re not going down a certain path just because of US dysfunctional copyright laws on that front. I also hope it makes room for the small guys and not just the font resellers.
Wilson–
One thing that Microsoft should consider before aggressively promoting EOT on behalf of foundries is to get their WEFT tool functional, usable and crash resistant. Again, if foundries do not want their fonts linked, they had better recognize the demand for font embedding within Internet communication and provide a reasonable method for embedding that does not pose a risk of theft. Until then, their fonts will be used regardless of EULAs.
Time relative to font development and costs associated with it is a poor argument. I know of no good Web designer/developer who does not put in the same amount of time and money to develop a good product. What do browsers or standards do to protect the developer’s investment, e.g. Microsoft’s IE.
Using copyright infringement as an argument to exclude other methods is also a poor argument. If a browser with a 75% share of market wanted to bring parties to the table to seriously resolve the issue, perhaps that browser should support font linking.
@Point blank
10 grand!!! wow I think I hate the Font Foundries more than the RIAA now.
I dabbled at creating fonts myself… I’m a graphic artist though, not a professional typographer.
Ten grand seems incredibly abusive. I’d have a hard time looking at a client in the face and telling him that 5 number figures don’t buy him the intellectual property (even if there was such a thing for fonts), nor the rights to redistribute, not even the exclusivity… let along the concept of limited use.
I do realize the time that goes into creating a font. I also realize that it’s pretty inexpensive to “resell” fonts. It’s not like they have these massive promotional events featuring the artist signing autographs and pay publications to feature their product.
Unlike the music industry… fonts don’t really “get old”. Even if you could properly copyright a font… it seems to me we’d reach a point where we’d pretty much have all the fonts we need reaching the end of their copyright term. Would we have these century old companies milking this for eons to come?
Some US established so called “Font Foundries” only resale fonts and do not really focus their business on the creation of fonts. In fact they sell copies of fonts that are properly copyright in other countries such as Germany and Great Britain.
I just don’t see the point of facilitating this practice and extending it’s “business model” over the use of fonts on hypertext. By nature, all font distribution “business models” are flawed in that those designs are basically public domain… you cannot own the letter “a” anymore than you can own the sound of a note. Sure you can buy sound packs for synthesizers but cannot own this particular combination of pitch frequency etc…
Now I’m no legal expert but my understand is that by US law…If I re-encode a font file, unless I re-use the trademarked name of the font file or produce a font copy that has the exact same point patterns in the bezier curve… making it a new file (which I’m forced to do to make my EOT) … it makes the file mine. Unless I’m misusing the tool I used in that process… but then I could just use another tool that is not as limiting… unless there’s only one tool, but that’s only likely to remain true if the file format is completely closed and protected. OpenType is a proprietary file type so maybe that could happen. But then that’d be quite the misnomer!
First, a disclaimer – I am not a lawyer. Use this as legal advice at your own peril.
Font outlines are not copyrightable, as @Jerome says. What *IS* copyrightable, though, is the computer code in the hinting of TrueType/OpenType fonts. As it turns out, that is the hard and expensive bit anyway (though not the most creative bit, one might argue).
(As an aside, yes, you can TRADEMARK (not copyright) a name for a font. Not really that relevant to this discussion.)
As for a few other points – @Jerome, if people want to steal, it is very hard to prevent them. But you can, in fact, at least let them know that they shouldn’t be stealing, while not making it hard to share if that’s what you want.
As for $10k for a font – well, that’s a bit steep, yeah. But on the other hand, if that’s what they want to sell their font for, it’s their font. Pick another one if you don’t want to pay it. And I know that fonts can cost a lot to produce – one of Microsoft’s fonts cost more than a million dollars to produce. (Granted, that was a Far East font, but still – great hinting for onscreen readability is not cheap.)
@thacker – I fail to see your reasoning on saying we should support font linking to show we’re serious. Can you explain?
Point taken on WEFT stability and usability. It should suck less.
My feeling is that many of the people looking into this solution will also have websites with dynamic text. In the end they will probably want the full set of characters and will include it in the EOT unless they are legally bound not to. They are not the ones who’s interest is in limiting the use of the font. So it’s not going to be very different than just linking to a file.
I do not fully understand how it works. My info on WEFT comes from http://www.microsoft.com/typography/web/embedding/weft3/tutorial.aspx and it doesn’t even talk about Windows XP or IE6. Wikipedia took me to http://www.microsoft.com/typography/WEFT.mspx.
As I could gather you create a file specifically for a root. In the interest of caching that file I might want to be running only one EOT file for my entire website, hence another reason for me to want to include all the basic characters in that font file.
As for limiting font face sizes… I really feel like at this point I’d limit accessibility if I started doing stuff like this.
Let’s say I wanted users everywhere to be able to see my dynamic text in different sizes in Century Gothic, Bookman Old Style or Klinzhai or Quenya font. Let’s say I don’t trust Apple or Linux systems to have proper equivalents and I want to provide the font and I want to style everything with CSS. Would it be feasible? Would this involve very large files?
Wilson–
Support for font linking demonstrates several things.
1. Foundries, W3C, other browsers, etc. — you have to come to the table to get this issue resolved, now. It is not the function of any browser to legislate nor police. The browser has simply adopted a recognized W3C standard. I would also go as far as to state that failure to adopt a standard is the other side of the ‘don’t break the Web’ mantra. Both sides of that sword break the Web. Font linking would, obviously, be temporarily supported by all browsers.
2. It says that Microsoft is using its market share proactively for the end-user rather than its more traditional appearance of getting in bed with a business partner. Chris, Microsoft is short on trust. The manner and logic that has been presented to advance what I believe sincerely to be a good and functional technology has been overshadowed by the logic/arguments presented. It is not promoting or re-establishing trust.
3. It brings stability and equality to EULAs for font use. The growth of Internet communication should not be hindered by out-dated and ill conceived license agreements. For example when Linotype charges Ten Thousand Dollars [US] for their complete foundry, there exists no reason why Internet communication use should be prohibited or limited. The technology exists however implementation across user agents is not present.
The threat of theft is relatively limited to foundries when placed in the context that 75% of Web content excludes a DTD let alone those developers who have even considered font embedding. Logic says to me that font embedding will never become mainstream, thank God. ImAGiNe tYPe liKe ThIs iN aSsOrTeD FoNtS.
Personally, font embedding should be used primarily to support reinforcement of brand identification and brand communication. Realistic use in those parameters would include only one commercial serif font and one commercial sans serif font, in my view.
I hope it doesnt turn out to be a repost, my inital post would not go through for some reason, probably because it had a URL in it.
Having websites with dynamic text I would probably want the full set of characters and will include it in the EOT unless I am legally bound not to. I am not the ones who’s interest is in limiting the use of the font. So in the end it’s not going to be very different than just linking to a file.
I do not fully understand how it works. My info on WEFT comes from I got from wikipedia and it doesn’t even talk about Windows XP or IE6 but only IE4, IE5.5 and Windows 2000 (it’s a microsoft site, I wont put the URL because I suspect it’s the reson my original post was blocked)
As I could gather you create a file specifically for a root. In the interest of caching that file I might want to be running only one EOT file for my entire website, hence another reason for me to want to include all the basic characters in that font file.
As for limiting font face sizes… I really feel like at this point I’d limit accessibility if I started doing stuff like this.
Let’s say I wanted users everywhere to be able to see my dynamic text in different sizes in Century Gothic, Bookman Old Style or Klinzhai or Quenya font. Let’s say I don’t trust Apple or Linux systems to have proper equivalents and I want to provide the font and I want to style everything with CSS. Would it be feasible? Would this involve very large files?
As I’ve commented several times on www-style, as far as I can tell, Vista’s EULA actually allows embedding TTFs of the Vista fonts directly into HTML files using data: URLs and explicitly disallows serving EOT files on my Web server. So Microsoft’s own licenses seem to disagree with your argument.
http://lists.w3.org/Archives/Public/www-style/2008Apr/0383.html
Chris, thanks for your reply!
IANAL, but it seems unlikely to me that font license will allow its redistribution in a weak DRM wrapper and not without it.
If EOT is a loophole and font producers don’t want their fonts on the web, they’ll change their licenses to forbit EOT too or follow RIAA’s footsteps.
AFAIK there’s nothing stopping copyright-ignorant people from getting TTFs via torrents and then wrapping them in EOT.
The spec is open and encryption seems absolutely trivial:
http://www.w3.org/Submission/2008/SUBM-EOT-20080305/#Implementation
Isn’t it too trivial even for DMCA? It requires “a technological measure effectively controls access to a work”, and DRM in open specification cannot work effectively.
Probably the first non-Microsoft EOT implementation will be a DRM remover that makes it as easy to violate copyrights with EOT as TTF.
That will be end of anti-piracy story, but we’ll be left with quirky format that makes pirating equally annoying as legal publishing.
Wow – Thats certainly a lot of I want, I want, I want!
There is little give from the IE team these days, but I see plenty of take. It is sad that you cannot lay the first stone and maybe implement a standard before making your demands on everyone else and forcing your half-baked standards through (even you do not seem to have much faith in it).
Implementing canvas, SVG or any of the other standards we have been asking for would go a long way to helping you get what you want. You forget that your browser share is dropping and people do not have to listen when you shout orders. Times change, maybe you should too?
@Billybob: go troll somewhere else. The next one gets deleted.
@kL – the font industry already DOES allow redistribution in EOT format, knowing that it is not strong crypto. Or, they disable the font embedding bit. EOT is, in your words, a loophole – on purpose – and the font foundries knowingly enable it. And yes, it is always possible to put TTF/OTFs on a torrent.
@Jerome – response to you later today, I’m not ignoring you.
Seems like it’s gonna take years to iron this stuff out. In the meantime, is it possible that browser makers Snow WhItE and the three dwarfs could get together on a royalty-free font package of, say, twenty five or so fonts to ship with the install of each browser? Is such a thing doable?
“Logic says to me that font embedding will never become mainstream”
Thacker, are you insane? Have you never seen a myspace or blackpanet user page?
Little girls will ABUSE every dingbat font they can get their hands on. Poets will have every line in a different script font. Designers will use divs contaning 1 fancy letter and overflow:hidden to crop it down to only show the swirly cool descender’s decorative elements and position:absolute that div into the lower right corner of the content area as a decorative element.
Bonny–
To answer your question, yes, ma’am, I am and I can provide direct certification from a foreign facility for the criminally insane but lets not go there. MySpace, Facebook, etc are places on the Web that I never venture. If my logic is misplaced, I will stand corrected.
Chris, I still don’t understand why foundries think EOT is an improvement over font linking. Are they thinking that they will only let us use EOT files that they approve? Are they planning on specifying the exact details of allowable EOT files (rootstrings, subsets, etc.) in their licensing agreements? In particular, I don’t know of any licensing agreements that forbid me from creating EOT files with null rootstrings, which would allow anybody to hot-link or copy my EOT file unchanged for use on their own website, AFAICT.
It seems to me that if the embedding bit is enabled, then I can create and use an EOT file that has a null rootstring and which contains the entire font without problems with current licensing restrictions. Then somebody could create a browser extension that automatically discovers EOT files, and converts them to TTF files and installs them on demand. Or, somebody could download the EOT and do the conversion themselves with their own tools.
Anyway, I am not advocating piracy or making it easier for people to violate licensing agreements. It just seems like EOT doesn’t do anything that can’t already be done with standard OTF font files. What is the technological advantage?
@chris: Sorry, my last comment was rushed.
You’re right that foundries may be happy with EOT now, but this won’t last – with help of a simple tool EOT can be copied as easily as TTF.
I appeciate fantastic work that goes into designing typeface and hinting it, but you just can’t have copyright protection in open standard – it’s just technically impossible. At best you can make copying inconvenient and offer false sense of security.
Once foundries realize that, they’ll start threating EOT just like TTF and business you’re trying to create will collapse.
EOT replacement won’t solve that unless you make it a proprietary EmbedsForSure, but then everyone will be using TTFs and just threat font embedding in IE as yet another thing that’s broken.
There’s no real protection there and once foundries realize that, they will put EOT in the same evil basket as TTF, and we’ll be back at square one, possibly with new, proprietary DRM in the works 😦
I’d like to address a few of the issues raised here. Excuse me for going on at some length, but some detail might help people with open minds understand why we’re doing this.
It’s not that EOT is particularly exciting technology. What is exciting about it is that the industry which produces commercial fonts supports it.
EOT languished for years because we kept it proprietary. No-one had even looked at it for years. But all the great designers I know have kept pounding on me to fix the problem of “only a few fonts you can use on the Web, so all sites look the same”.
People are right about the WEFT tool; it hasn’t been updated for years – again because no-one was using it. As soon as people start using EOT embedding we can begin collecting requirements to make it better. I’ve already suggested the company needs to put some resource on it. But it’s hard to justify until you have customers asking for fixes and features.
The 10K figure quoted for Linotype fonts is being deliberately misinterpreted to readers of this blog. 10K buys you, AFAIK, not just one font, but THE ENTIRE LINOTYPE LIBRARY of fonts. That’s pretty much the company’s entire package of IP, built up over more than a hundred years.
Even fonts which were first drawn hundreds of years ago are not a case of foundries “getting rich on outdated IP”. First, as Chris points out elsewhere, there’s the hinting. It’s absolutely required to make a font that works well at screen resolution. It’s long and tedious work, but it also requires huge expertise and the creative eye of a typographer to do it right. Then there are probably many, many new characters to be drawn.
Let me give a concrete example. When we created Palatino Linotype (which first shipped in Windows NT 3.5 or 4), we began with Herman Zapf’s original smallish character set. Since we ship Windows in so many languages, and because we also wanted to exercise OpenType features in the fonts, we ended up creating a font with about 1300 characters, including lots of ligatures, true small caps, polytonic Greek, Cyrillic etc. Well, actually, we made four complete fonts of 1300 characters each, since there are four true weights – regular, bold, italic and bold italic – each drawn and hinted differently.
We had four people from Monotype working permanently at Redmond (two of them, Mike Duggan and Geraldine Wade, subsequently became full-time Microsoft employees and still work for us). One worked on each of the four weights of the font. Geraldine, for instance, drew all of the italics, which are beautiful (italics have true shapes all their own – they’re not just machine-skewed regular faces, which look like complete rubbish…). Mike focused on the regular weight.
They created paper drawings of all the new characters. These were all shipped over as hard copy to Herman Zapf in Germany, who made suggestions and corrections, signed off on every character we drew, etc. We wanted to be certain every single character conformed to the spirit of the original great design.
Then all the new outlines were built into TrueType fonts with all the right tables, and then extensively hinted and tested.
Four people at Redmond worked pretty much fulltime on the project for more than 18 months. Others, like testers, for instance, spent part of their time. External contractors were also used for some of the work.
Don’t even get me started on what it took to develop Meiryo, the ClearType-optimized Japanese font that shipped with Vista and Office 2007. Besides the 22,000-odd characters (in two weights, so a total of more than 44,000) it included developing a whole new hint-based technology for stroke reduction at screen resolution in all East Asian fonts…
I had to personally win an argument for the budget for that project with Bill Gates (I happened to be in his org. at the time). He said no once. I pushed back. He said no again. I pushed back again. He said we’d have to have a full BillG review of our projects. That’s a scary thing, but we ran the gauntlet and got the money.
18 months later, BTW, he told us enthusiastically what a great job we’d done “I didn’t think it was possible to do what you proposed. It was a lot of money – but it was worth it”.
We worked with Japanese designers, Matthew Carter, and many other external contractors.
I really wish some of the people who talk blithely about the font industry as if it was a set of “big fat corporations getting rich on old IP” could see for themselves what this process entails. Good luck to anyone creating “free fonts” that meet these kinds of standard. Expect to spend about ten years learning how to do it right. And expect to have to support them for the rest of your life and beyond, as language support is extended on computers and new characters are needed. (The Euro symbol was one famous example).
Font piracy has ALWAYS been a serious issue for the folks who make them, ever since the first decent fonts appeared on computers. People casually copy font files and pass them on to others. The industry does do some policing – but you can only ever really catch the big fish, like companies using a single-user set of fonts like a site license for every PC in the organization.
The industry’s had to learn to live with a lot of casual copying. But the Internet has the potential to increase this by many orders of magnitude, its anonymity makes it much harder to police, and it could almost certainly turn a problem they can just about live with into one which could kill them.
Working with the industry to develop EOT by modifying the former TrueType format with new embedding bits was a major triumph back in the days when the Word team first did it. Extending that to the Internet and managing to carry the font industry with us was really important – because we need a solution that lets people legally use commercial fonts.
Raw font files on servers are too easy to casually copy.
I know there are many in the OpenSource world who don’t believe in IP at all. But I know exactly what it costs to create great fonts, and I’d personally fight tooth and nail to prevent Internet Explorer from ever implementing support for raw fonts on servers. I’m far from alone in this in the team and elsewhere in the company.
Someone else suggested there’s no IP protection for font character shapes. That may be true in the USA, but it’s not the case in Europe, where Germany, for example, has good protection.
Other folks say “Why doesn’t Microsoft just release another Webfont pack?”
We did this once, in 1996, and kept it up, free to anyone, for years. Then we found that manufacturers of competing Open Source operating systems were using it as a way to avoid making any investment in creating their own OS fonts.
The end-user license agreement prevented them from just shipping our fonts. So they started to include – in their initial setup files – a link which the user could click to download and install our core fonts!
Faced with this barefaced circumvention of our EULA, we took the Webfonts package down.
It was a shame; the OpenSource OS manufacturers spoiled it for everyone. We invest millions of dollars every year in fonts to add value to Windows and our other products like Office.
That’s one issue, and we can take care of ourselves. But it’s quite another when you personally know people who love type so much they make it their career for their entire lives, and hope to make a living from it. The one- and two-man operations who can’t create many fonts and depend for their living on getting some return on the huge investment they have to make to create just a few fonts. It’s easy to pretend this is all about big, faceless corporations. But I can put names and faces to many of the fonts I love, and I know who I’d be hurting.
People who take a casual attitude to making font piracy easier are either painfully ignorant of what’s really involved, or just don’t care.
@billhill
Your post taught me a lot. I had no idea what kind of effort went into creating a font. And, indeed, why should competing companies be handed that work for free. (Webfonts)
A quandary it is.
Hill–
Your reference that cost of the Linotype foundry is being/has been intentionally misrepresented is in and of itself a misrepresentation. Having reviewed every post, I have found no ambiguity nor reference to a single font with such a cost, except for a reply by Wilson. The initial reference was made for the sole purpose to show cost for a complete foundry and restrictive outdated EULAs that accompany such a purchase.
I suppose I could go into a litany of examples of projects and people who have committed tremendous resources and hours to develop Internet communication and have never received support from a browser manufacturer to achieve that goal. Nor, how certain browsers have impeded such efforts. Or, people who have committed their careers to standards development, free of charge. However, I won’t. It is their job, their passion and their choice.
I would very much like to see an argument wherein font embedding is a significant source for font piracy or would be. Prior reference to little kids trading Microsoft Publisher fonts and using them on social networks does not suffice. Commercial fonts such as JohnSans and Frutiger Next sure wouldn’t exactly illicit squeals of delight from the ‘ClownFace’ font kiddie crowd.
@Jerome yes that would be feasible. WEFT (and certainly EOT) doesn’t HAVE to subset. You do have to pair the font with a web domain with which it can be used (or set of domains).
@thacker I don’t think anyone ever said a single font had that cost, in today’s market, to the purchaser. The cost for Linotype to develop even a single font might well outweigh $10k, though.
You can go into whatever litany you like. On your own blog.
I have, in fact, pretty much dedicated my career to open standards, thank you very much. Perhaps not entirely free of charge, but certainly at a financial cost to myself.
Wilson—
Where or how did I infer, state or make any attempt to denigrate anyone who has committed his/herself to advancement of standards even yourself?
Only a fool or a foolish company touts the value of their product or that of another on the basis of how much money and time was spent to develop the same. Products/services are only valued based upon what benefits are derived by their customer(s) from that product/service, e.g. Windows Vista, foundry EULAs, etc.
Again, provide some logical argument that font linking within CSS and professional Web content would pose a significant risk to foundries and an increase in piracy. Please, also, explain how a browser with a 75% share of market could not force all players to the table by temporarily supporting font linking. Explain, also, why this problem has been lingering since 1996 and gone unresolved. I will forego asking for a reasonable explanation about presentation, the basis of the argument. timing of the proposal and total lack of preparation when the current proposal was made on the IE blog a few days ago and done so by people who know better or should.
Thank you very much.
@Ian Hickson – I disagree with your interpretation of the Vista EULA, which refers to (via your quote): “You may only…embed fonts in content as permitted by the embedding restrictions in the fonts…”
You seem to disregard over a decade’s definition of “embedding restrictions in the fonts”, by multiple shipping pieces of software, as well as by the OpenType specification itself: http://www.microsoft.com/typography/otspec/os2.htm#fst. (The TrueType spec, which was input into OpenType, obviously, actually explicitly describes T2Embed as the allowed and expected vehicle for embedding.)
One might, I suppose, argue that only EOT files that are embedded via Data URLs are allowed, but EOT is most definitely in that definition, as per the OpenType specification.
So let’s say the Opera, Firefox and Safari all respond that they don’t mind implementing your EOT font embedding but that like font linking and are going to have it too.
What then?
@Jerome that would be grand. No, we don’t intend to implement font linking to arbitrary TTF/OTF files.
If you are hell bent on this, would you please consider the following:
1. Redesign the WEFT tool. With font management applications and with only system core fonts residing in the Windows Font directory, specifying a separate folder within WEFT causes the app to crash. Perhaps, also, consider including an advanced function that bypasses all of the wizards, CSS output, etc.
2. Allow for support of EOT, if not already available, within Silverlight and work with Adobe for support in embedding EOT into Flash (Adobe Air). File size for use of EOT within both versus direct embedding of the raw font is beneficial.
3. Publish a list of commercial fonts that will render effectively by the browsers’ font rendering engine at the more traditional Web font sizes. Work with the foundries to not allow EOT for those fonts that technically are not designed nor do not render clearly within a browser or at least identify/warn of such fonts when WEFT is used to create the EOT.
4. Make sure that foundries clearly specify support of EOT within their EULAs. Ascender, for example, who sells the Microsoft fonts and claims support for EOT, makes no mention of EOT within their EULA and clearly forbids use on servers unless a separate server license is purchased.
5. Work with plug-in developers and other browsers to be able to include the t2embed dll so that EOT support is available, e.g. even as an optional plug-in for Firefox until full implementation by Firefox would occur.
6. When this rolls out, provide a Microsoft Press publication, free of charge in digital format, on Web typography, proper use and best practices. This will get done to some degree on MSDN — just leverage the asset into a functional, concise and clear digital format, e.g. Web Typography and EOT for Beginners and Advanced Users.
7. If necessary for acceptance, open source EOT.
@thacker
1) yup, trying to figure out how to get this accomplished.
2) I’ve been pushing that (with Silverlight) for a while.
3) that sounds like a creative decision? We don’t want to limit the author’s choice of fonts.
4) Working on that, too.
5) that’s what we’ve been doing from the CSS WG perspective – trying to work to make EOT usable, cross-platform, even when t2embed.dll isn’t available.
6) that’s a great idea. Bill’s looking at it.
7) what’s the delta to you between publishing all details, perhaps offering sample source code, and “open sourcing”?
Wilson–
Point 3 is a creative decision that is dependent upon the creative knowledge of the designer. For example, there are rendering issues within certain fonts of Microsoft’s Web Core Fonts that many designers are not aware. It is, however, a best practices decision in helping guide and educate designers on the complexity and problems with Web typography and solutions to the same. It is also a foundry’s quality of product decision. A designer decides to use a font that is not suitable for the Web. The foundry takes the hit for a ‘supposed’ poor product. In addition, such an embedded classification of several quality Web categories within a font that can be identified by the WEFT tool can create a value added product extension to a foundry’s font collection, e.g. Functional and practical Web Font bundles.
7. Personally, I don’t care whether something is open source or not. I only care if it works and has value for the money/time spent. However, it seems that someone always attempts to impede a technology based upon whether or not it is ‘open source’. If creating EOT as open source minimizes issues or length of time of acceptance it may be a worthwhile trade off. It might, also, minimize security issues/concerns of use of an EOT as a threat vector.
Point 2: Adobe and Flash. I would have felt a lot more comfortable with this suggestion if it was a joint suggestion by both Microsoft and Adobe rather than as it currently stands — for a lot of reasons.
Personally I’d never heard of EOT or really given much thought to web fonts before all this. After reading all these blogs and font sites, I’m still a little unclear on exactly how EOT prevents piracy. Can somebody possibly give a straightforward explanation? The impression I get is that people buy TTFs from foundries, convert them into EOTs using a Microsoft tool called WEFT, which requires them to specify which web sites they’ll be used on. They then host the EOTs somewhere, and apply CSS font-face rules to use them. User agents are then supposed to check the host list of each font they download, and ensure than the site using them is within the allowed list. Am I correct here?
If the above is the case, my questions are: What is to stop someone writing a tool to extract TTFs from EOTs? Or to modify the allowed table directly?
Jon–
The WEFT tool creates an EOT based upon the document rights that are embedded into every font. If a font, for example, contains the ‘No Embedding’ document rights, the WEFT tool will not create an EOT of that font. A more detailed explanation of embedded document rights is available at http://www.adobe.com/type/browser/info/embedding.html.
I would think that you are correct in that a tool could be developed to extract the glyp or subset from the EOT and create a ttf or otf font file from that. There is also concern that a tool could be used to create an EOT that could be used as an attack vector. I guess it falls back onto the adage that if it is extremely sensitive and of high value, do not publish — whether it be fonts, an image, document or an invention.
It has been reported that when using the WEFT tool that a null reference can be inputted rather than a specific Web site or URL within the site. If such is the case and I haven’t tested it, that answers your second question. With a null reference the EOT could be used on any Web site, possibly.
However, in my view, the advantage of EOT is the ability to create a subset of a font for use within Internet communication that includes RIAs. They are smaller and only the needed glyps are included within the EOT.
Font embedding in the context of HTML documents is a misnomer. Fonts cannot be embedded into an HTML document. They are however referenced by use of the CSS @font-face rule. The font-family CSS rule references device fonts installed on the client while the @font-face rule references fonts via the src url .. and requires, in this application, the font to be stored on the server.
It should be noted that no major font foundry’s standard EULA, that I have uncovered, clearly supports the placement and subsequent reference thereof of a font or subset of a font on an external server. The exception to that is Microsoft’s font EULA in use of EOT. Adobe, for example, clearly excludes such use. Linotype, for example, is somewhat ambiguous. Ascender, a Microsoft partner who sells Microsoft fonts, clearly excludes such use and, strangely, makes no reference for such use within the Microsoft fonts it sells. Third party foundries who re-sell fonts often have their own EULAs that govern the use of the font and often will have different document rights embedded into them than that of the originating foundry/creator.
Just in EULA restructure alone, there is one hell of a lot work to be done before EOT can become a practical specification.
I’ll catchup hopefully tomorrow. Busy day.
Well I’m less and less apprehensive to this approach, although I’m still thinking it does very little more than it did before in terms of protection. The subset feature will be practically unused… the font size limitations is also likely to be disregarded. The only real protection left will be the domain to which the font is tied.
Sure people will be more aware that they are doing something illegal when they rip the font that is about it.
I have another question for you Chris. I thinking there might be more chances of bugs or problems with this system than directly linking on a file… I’m guessing straight up that the site can not longer be referenced by IP…? What about mirrors? ports? intranets?
Also if I made the font myself… like it’s my handwriting or something. Can I just make the EOT not dependent on a domain? Let’s say I want to license it under some open license like creative commons…
Another thing I’m unclear on… is the domain the EOT attached to the domain the EOT file needs to be hosted on or the domain the HTML files need to be hosted on?
@thacker: I agree, not all fonts are suitable for all situations, and designer education would be a great thing there. I don’t think limiting ability would be the right thing to do, though.
I agree with your take on open source and EOT. On Adobe, I do hope they will weigh in – though Flash’s font embedding is a different scenario from font linking, since it actually does at least embed the fonts inside a container rather than just ramming them up on a web server. I still believe EOT respects license much better, of course, but at least Flash doesn’t make it trivial to link to fonts on someone else’s system.
@Jon – I’ll try to write up another post on how EOT does or does not help with piracy. @thacker’s take is pretty accurate.
@JeromeLapointe – yes, you need to insert the domains by which the EOTs would be referenced into the EOT – so the designer can put the IP address in, but if they don’t, it won’t work. This is standard SOP-style or zone testing. As for making the font yourself, “free” license like CC, don’t care if anyone reuses it – (Note that no Creative Commons license covers font linking style use, as it does not Attribute) no, I don’t think this is currently covered, but it certainly could be. The hard part is connecting that license automatically – currently, TTF/OTF doesn’t have a “this is a freely redistributable font” bit.
In this case, of course, I’d expect you to have an EOT if you want to use it on your site, but offer a link to the TTF for people to download.
And the domain(s) attached to the EOT is the domain(a) the HTML files need to be hosted on, not the domain of the EOT file.
JeromeLapointe said: “Sure people will be more aware that they are doing something illegal when they rip the font that is about it.”
I don’t think so. In order to obtain a font that is directly linked, they’d have to read the CSS file associated with the Web page, find the URL for the specific font, then enter the URL into their address bar. Someone with that level of technical prowess is likely already familiar with the copyright implications of downloading the font file and using it without permission.
It would be different if you could right-click on some text and select “Download Font”, but that wouldn’t be the case without a plug-in. In the case of a plug-in, I don’t see a difference, from the user’s perspective, between one that downloads a font file listed in the CSS and one that downloads an EOT listed in the CSS and converts it to a TTF behind-the-scenes.
Also, the CSS is likely to contain the actual name of the font, which can then be used to find the font on a file sharing system. Thus, even if you assume that the user can’t break into the EOT, they can just do a file search for the font name. (It would be trivial to write a plug-in to search for fonts in this manner as well.)
So, in a nutshell, if someone really wants a font and they don’t care about copyright, EOT won’t make any difference. In order to truly protect these fonts, you’d have to have a DRM scheme built into the operating system, so that people couldn’t just zip up the font files put them up on a file sharing system. Then you’d have to have DRM-protected files on the Web site that can only be downloaded using the same DRM protection. Anything short of that is just rearranging the deck chairs on the copyright Titanic.
Side Thought: Shouldn’t the license for a file (or the respective URL thereof) be one of its file system attributes?
@Matthew Raymond actually, there I would point out that this is EXPLICITLY not the case. For example, go read Håkon’s article on font linking – . He explicitly points out how you can collect a whole bunch of @font-faces together, and even points to a file they offer on Prince’s site that then font-links all of Ray Larabie’s fonts:
@import url(http://www.princexml.com/fonts/larabie/index.css) all;
h1 { font-family: Goodfish, serif }
I expect THIS is how people would use font-linking – grabbing someone else’s library, and then just using font names. They don’t need to put the file on their system, even – they just @import “Bob’s big book o’ fonts.css” and use the fonts it defines, never even minding that the fonts it references (which may, of course, be spread across the web) may be commercial fonts that the designer (and their output) doesn’t have a license to use. Since the files can be on different domains (indeed, the original host might even have had a license to use the font, though likely not to post it on a web server), Bob doesn’t even need to copy them himself – he could just troll the web looking for .TTF files, and then reference them in his CSS that everyone @imports. Although this spreading out of blame may make people feel better, it doesn’t make the loss to the font designer any less egregious.
Look, if people want to steal, I don’t intend to spend my career building better mousetraps to prevent them. EOT isn’t intended to be that. It’s intended to make it easy to use commercial fonts – already mostly approved by many commercial font licenses – to use fonts in web design, and simultaneously making that use NOT be the last copy of the font the original font designer ever sells. Yes, you can write plugins that will steal fonts, even with EOT (presuming that the font is not subsetted – and keep in mind that subsetting by character family is actually SMART, even for dynamic content).
On your side comment – it would be nice if the license for a file were captured in a machine-interpretable way, yes. But anything short of “You can use this font in any way you see fit, and I don’t even care if you attribute it to me” would be unfit for the current font-linking proposal. That’s why even Ray Larabie, who makes tons of very nice fonts that can be downloaded for free, has said he doesn’t really support font-linking; there’s no attribution (let alone scoping of the font for those who DO want to sell licenses in some scenarios).
Whoops, forgot the link to Håkon’s article: http://www.alistapart.com/articles/cssatten/.
Chris, I think that is a pretty convincing argument, but only if font foundries’ licenses are written to facilitate EOT.
Microsoft’s fonts are the ones that are the most optimized for on-screen use, and the ones I am most eager to embed. Yet, Microsoft’s fonts are also the most confusing from a licensing standpoint. The licensing terms for those fonts state that I am allowed “Embed fonts in content as permitted by the embedding restrictions in the fonts” but also said that I “may not copy, install or use the fonts on other devices.” It is hard to see how I interpret those to statements together to mean that I can upload EOT versions of the fonts to a server, but I cannot upload the TTF versions.
I think if the font vendors came out with new licensing agreements that clearly spelled out that they were going to grant us special rights for using EOT (at extra charge or otherwise), then that would make the case for EOT much stronger, because then designers may start demanding EOT support from browsers. But, the licensing agreements have to be updated first; otherwise, in most cases EOT will be forbidden just as much as TTF is.
Chris, Jermone, Brian, Thacker, Anne et. al – great discussion here. It took me a while to read through this and thought it was time for someone from the font community to chime in. I am with Ascender and helped create the fontembedding.com website. We developed this to put forth the multitude of issues surrounding what you typically can and cannot do with commercial fonts. While it mostly represents our opinions we are working with other type designers and font foundries to bring in other voices.
The key point to reinforce is that almost all commercial fonts are prohibited from being posted to web servers, whether as an EOT or as a native TTF or OTF file. Yes, our current EULA prohibits even EOT files from being posted. We do offer extended licenses for EOT fonts, and also for Flash, Silverlight, and other technologies.
We believe EOT is the best solution for commercial fonts because of the features it offers over raw font linking. I won’t repeat everything stated on this above. Rather I think the key point is that type designers and font foundries will support EOT, and they won’t support raw font linking of TTF and OTF fonts. As mentioned above, even Ray Larabie does not support raw font linking. He does support EOT.
Yes, I think many type designers and foundries are paranoid about how their fonts might be abused by being posted or shared illegally. Raw font linking offers nothing but headaches thinking about the potential misuse and lost revenue. At least EOT offers a set of features that benefits everyone involved: authors, readers, type designers and the browser/software developers.
Thacker’s list, and Chris’s comments were right on – there is still a lot of work ahead to make this all work. My hope is that by engaging more type designers & foundries into discussions like this can help make forward progress in a timely manner. At a recent type conference in Buffalo, NY we had some excellent discussions on web font embedding and EOT. A lot of type designers & foundries are still trying to figure this all out, just as some of the readers here are as well.
And as Brian mentioned above, one of the first things we need to do is improve our font license agreements and better communicate the rights which are granted in the EULA.
Davis–
Thank you very much for your insight. I have just a couple of points to add and then I am going to shut the hell up about this topic.
1. EULAs — A third party foundry could create a value-added product extension, a Web-HTML font bundle. The bundle is composed of fonts best suited for HTML documents and thus rendering/resolution issues of browsers and their font rendering engines. The EULA of the bundle clearly states EOT support and the appropriate document rights are embedded into the fonts within the bundle.
2. In addition to document rights, several embedded catergories be added exclusively for HTML use. They would not be document rights per se but ‘warnings’ of clarity of the fonts when they are used for HTML documents.
3. Adjust the font preview, font management, EOT creation tools and other tools so that these new classifications will be visible when previewing fonts.
Item 2 and 3 are implemented soley as redundant information to inform the Web designer the quality of rendering of the font within a browser. One of my biggest concerns about EOT use and CSS font linking/referencing is to limit visual rendering issues within HTML content from misuse or poor font selection within the document.
Is it possible to gzip those EOTs for distribution or would that create problems with the “DRM”?
you can gzip (and un-gzip) pretty much anything – it’s lossless. Or did I misunderstand the question?
Hmm maybe I didn’t formulate my question as well as I could have.
I’m no expert on serving compressed files to user agents either.
Unlike images which are already compressed, there is a benefit in compressing font files especially since your regular TTF can go anywhere between 25k to 150k, sometimes more.
When it comes to CSS and JS Some browsers let you do stuff like
…Or link on the regular file and just compressed it as you send it.
So my questions is could we compress an EOT on the FLY or do something like:
@font-face{font-family:”MyFont”;src:url(myfont.gz)}
(Direct link to a compressed version of the file)
That’s what I meant when I said would it create problems with the domain check.
@JeromeLapointe Ah. EOTs are already compressed, actually, which helps tremendously – EOT adds compression and subsetting. Aside from that, gzip compression is usually just handled in the transport layer. But no, you can’t point an @font-face to a gzip’ed EOT file today.
@Thacker – yes good points. Internally we have talked about trying to create a nice set of fonts specifically targeting web publishers. To be successful these would need to utilize fonts that are designed to render as best possible with the various rendering systems employed by the different platforms and browsers. This would obviously be marketed with a EULA to give web publishers the rights they need, and would most likely be in the EOT format. We have discussed this with a few web designers to get their input on the kinds of text and display fonts that would offer a visual and typographic benefit over the exisitng web fonts, and hope to have something to announce in the coming months. So stay tuned. NOTE: my apologies if this comes off as a shameless advertisement, which was not intended – I would have added our URL if I wanted to be shameless 🙂
“G” – you fail. Don’t troll on my blog.
@Bill Davis, and all – Having created a few EOT’s to play around with on the fontembedding.com site, a word about licensing based on domain name:
One marketing barrier that needs to be taken into account is the “test” or “staging” server which will be accessed using a different domain name BEFORE the design using the EOT ever makes it to it’s “final” destination under the licensed domain name.
(I am deeply involved with a product that licenses based on domain name and I’ve had to deal with this)
It’s a matter of practicalities – you can’t expect wide adoption if the product resists testing under another domain name. One working copy of the EOT for use with the “public” domain is simply insufficient.
I use MS Internet Information Server on my XP laptop to do an initial test of most every design, and so the EOT I got at embeddedfont.com was for http://localhost/ which would be useless on the public domain names I use.
Thinking aloud – one workaround would be to install the full font file on my local machine and writing the CSS to default to it if the EOT is unavailable but then the discrepancy between the subset contained in the EOT and the full TTF (or whatever) could easily lead to trouble and, of course, this presupposes that the full-blown font set isn’t cost prohibitive, etc..
It’s an important issue that needs to be addressed.
This issue aside, I, too, consider compression a big plus in favor of EOT. I had read Håkon’s article on Alistapart when it was published but didn’t look closely. Going back and checking out the source behind the actual samples provided with the article has proved revealing. Each of those pages is using about (don’t shoot me on the math) an average of 75 to 100 kb of bandwidth just to get the TTF font-sets required. And they are not even full sets.
Big, big barrier, if you ask me. The EOT’s from embeddedfont are 7kb and 14kb respectively and, I assume but haven’t checked, IE will cache them.
Chris Wilson:
I don’t buy your argument at all. The scenario you describe has many flaws:
1) It involves a single point of failure. One DMCA takedown would remove the fonts from a very large number of pages, and once that happens enough times, people would simply stop linking to CSS-based font libraries on other sites.
2) The linked CSS file would have to be specifically designed for linking to avoid conflicts with existing page styles. (Hence, the webmaster of the hosting server would have to be “in on it”.)
3) The browser fetching the CSS file would have to intelligently fetch and cache the font files to avoid long delays in the page loading or large file caches.
4) The problem could easily be averted by limiting font linking to the current domain.
5) A site could experience a “SlashDot” effect if enough people link to the font.
6) If the fonts are openly and freely licensed for the Internet, then predefined libraries are actually a positive thing.
So, not only is widespread piracy of fonts not practical using cross-site linking, but it could also prevent the proliferation of legitimate free font services.
@Matthew Raymond
1) not really, just re-hosting; and the DCMA can’t take down any server on the net, only ones within its jurisdiction. And there is no RIAA group – it would have to be done independently, by each font foundry. It’s much more of an asymetric war even than audio.
2) umm, when all the stylesheet does is define font-families, that seems like it’s not a challenge. Or, of course, the web author could always just point to specific .TTFs.
3) that’s generically true of font-linking, yes. Or EOTs, for that matter, except EOTs would probably usually be on the same domain.
4) …which the implementers of font linking have been hard set against, Håkon Lie in particular.
5) always a possibility, yes, although server scalability is a lot better today, and we’re talking about web developers.
6) if fonts are openly and freely licensed for a non-attributed repackaging and use on the Internet, then I’m okay with their being sued in this way. There is no way to determine that today, however. And more than anything, I want to be able to use commercial fonts – like those developed specifically for reading on-screen at reasonably small font sizes – which font-linking does not enable, and likely never will (due to license problems).
@Chris
Freud lives! – I think you meant to write “then I’m okay with their being used this way.” but wrote “their being SUED this way”.
Which, actually, segues nicely into Safari’s indiscriminate support for linking to TTFs with @font-face.
Very, very surprising if Apple isn’t in court over this and soon. IANAL but I can’t see how this is not a case of what’s called “vicarious” or “contributory” infringement. A Napster for fonts kind of thing.
And despite Håkon Lie’s evangelical zeal, Opera as yet hasn’t implemented @font-face in this manner although some assume they have:
http://www.opera.com/docs/specs/opera9/css/
I would have thought they would be the first.
Also, the WEFT tool stinks. Complicated and outmoded. What’s needed is a web based system – upload your TTF, pick your sub-set or whatever, and if the EULA info looks legit, download your licensed EOT’s.
If it isn’t easy and even a little bit fun, folks will stick with photoshop text and say the hell with it.
@Richard Fink heh. Yeah, Freudian slip.
Wilson–
Does IE8 Beta 1 support EOT? Issues or bug reports filed in regards to it?
Thanks
@thacker yes. IE has supported EOT since IE4.
I am not able to get EOT fonts to render within IE8 Beta. However they do render within the Emulate IE7 mode. Font-face rules are specified within an external CSS style sheet via a conditional comment for all IE browsers. Have also attempted to use a Page Load event handler to load the CSS file for IE browsers and have very intermittent success with EOT for IE8 but no problems with emulate IE7. Have read blog posts on MSDN’s Channel Nine and issues have been reported but without specifics. http://boinkinchipmunks.com/web/articles/white.aspx
@thacker – parts of IE8 when running in IE8 mode are missing. Many feel Beta 1 was more of an alpha release. I suggest waiting for Beta2 before delving further. I’m expecting a lot of problems to simply go away.
Richard Fink–
Thanks. This was the first issue with IE8 Beta 1 that I did delve into something deeply simply because of inference, more than once, that all IE browsers support EOT. IE8 Beta 1 does not support EOT to screen in my experience but does support EOT print while IE versions 5.01, 5.5, 6.0 and 7.0 support both. IE 4 was not tested.
@thacker remember, we created a whole new layout/text engine for IE8. I expect you’d find EOT worked in Quirks mode, but not in standards mode. 🙂
1) Rehosting requires changing all links pointed to a specific URL. While, in theory, you could have the CSS file linked to point to fonts on a separate server, then just edit the one CSS file, that would still leave a lag time between the time the site is taken down and the time the content was rehosted (and the CSS file was updated), and there is only so many times you can rehost gigabytes of illegal content.
As for jurisdictional concerns, what you describe isn’t much different, legally, from just making the font directly available for download. If, for instance, I can just put a Microsoft font up for download on my Web site in Country X (and just use the font family name without @font-face hosted) and there are no real legal consequences, then denying font linking and using EOT is little more than DRM through marginal inconvenience.
2) You’re missing the point. The CSS file would have to be part of a concerted effort to infringe, and a significant number of people would need to know about it. While there are some nuts out there who see copyright as evil and might want to help to “free the information”, I don’t really see the self interest in hosting illegal fonts and CSS in this way. You can’t do advertisements through a font file (at least not yet), and you can’t charge people for access because the entire Internet would need access to the fonts from people to use them in the first place. It would make more financial sense to sell a tool that can modify EOT files to work on your site.
4) I don’t think you can really stop implementers from introducing features in their own browsers that work under the same principals already used for other file formats. If there was a legal issue with font linking in general that could result in a lawsuit against a browser vendor, then it would have already happened with content like images, CSS and Javascript.
Thus, clearly, we’re talking about restrictions Microsoft can place in it’s own browser, because anybody can download the source code to Mozilla, fork it, and produce a browser with direct font linking capability for any file format they want.
5) Server capability goes out the window when you start talking about frequent rehosting. There are only so many servers that can host large numbers of fonts being linked to by millions of web pages frequented by hundreds of millions of viewers. Sooner or later you’d either have fewer people linking because you change hosts so often, or you end up with moving to a host that can’t handle the traffic.
6) Minor inconvenience is not going to prevent exploitation of commercial efforts. The EOT-only font-face scheme really doesn’t protect anything at all. Using the file descriptions for TTF and EOT, I can create an ASP.NET program that converts a font file anywhere on the Internet into an EOT and serves it up as if it where from my server. It’s not significantly difficult from a program I once put together to generate thumbnails for images at specific URLs:
@font-face {
font-family: “Commercial Font”;
src: url(“fontconverter.aspx?CommercialFont.ttf”);
}
In the example above, “fontconverter.aspx” would return an EOT file with an EOT MIME type. This accomplishes essentially the same thing as font linking, and it can be cached to reduce load on a central font server. It can even produce EOT files that are language-specific. In fact, there are so many benefits from this, I wouldn’t be surprised if people used this for openly licensed fonts.
@Matthew Raymond
1) you’re right, it’s not much different than just making the font directly available for download. (in fact, it’s exactly like that.) That doesn’t happen a ton today, because you have to install the fonts to use them. If you just have to point your pages at them, that hosting will expand dramatically; and if you have no other way to get other browsers to use commercial fonts, you’ll expect it’s okay.
2) I’m not missing the point here. Prince’s usage of Ray Larabie’s fonts actually violate his license today, IMO (no attribution) – is that a concerted effort to infringe? Not really, just not really paying attention to the license.
4) (you skipped 3) No, I can’t – but I want an interoperable system, that is implemented in more browsers than just IE, and font linking is irresponsible.
5) I’m not convinced of that, but I don’t think it’s that important a point.
6) yes, you could set this up. It doesn’t change the fact that you can’t use direct font linking for commercial TTFs without infringing your license and running the risk of getting sued, while you can (in some cases at the very least, and a variety of vendors like Ascender are now working thru their licenses) use font embedding with those commercial TTFs.
@matthew raymond
There is a difference between CSS, Javascript, and image files and TTF’s. TTF’s are labeled internally with the name of the foundry and licensing info. Plus, the font is named and the name presents trademark/copyright issues just on it’s own. The TTF’s contents are referenced within the CSS and then processed by the browser (or not) using that name.
These, to me, can add up to big legal differences. And why assume that this would have been tested legally by now? For what reason until now? And with big foundries like Adobe and MS involved, well, we’ll see what happens. That’s why I find it interesting that Opera still hasn’t implemented @font-face with direct linking to TTF’s. What’s the hold-up if it isn’t legal?
That aside, your “fontconverter.aspx” idea which is similar to what fontembedding.com has going, seems to me the way EOT creation needs to go to become a viable proposition. An online wizard of some sort. (I keep thinking of the sites that have you upload a gif or jpg or bmp and convert them into an .ico favicon file as a model.)
Seems to me to be an opportunity for the foundries that get on board with it. After all, their commercial fonts are already being distributed on the web for free, as bitmaps!
It’s incomprehensible why Microsoft is pushing EOT to the world while its own shiny-new platform — Silverlight — does not support it!
And how hypocritical it is to complain about Apple supporting linking to bare TTFs in Safari, while Silverlight also supports exactly that.
Instructions for downloading fonts using Silverlight:
http://timheuer.com/blog/archive/2008/03/10/embedding-fonts-in-silverlight-2.aspx
(This is the blog for a Microsoft Silverlight Product Manager).
Wouldn’t having complete SVG support (including embedded fonts) solve this and a couple of other issues (i.e. finally having a web vector format) all in one go? Sure, it wouldn’t be ideal for ALL you text, but at least for headlines. You shall not use crazy fonts for copy text anyway. That doesn’t mean there aren’t any more readable fonts out there apart from Arial and Verdana.
I hate having to deal with IE6 (and to a lesser degree IE7) as much as the next guy. But with this font embedding stuff i can see where they’re coming from. I also would like to use different fonts on the web, and EOT would allow me to. And i agree that putting your fonts right there on your server for everyone to grab isn’t the smartest thing to do, so a solution should be found that can circumvent that problem.
“You can download any posted images off websites”, someone said. Well, but can you use those for print production? I don’t think so.
Now i don’t know enough about this to draw a final conclusion (for me), but i’d say EOT isn’t all that terrible.
EOT does nothing to prevent people grabbing fonts from your server. Extracting a regular OpenType font from EOT is a trivial programming exercise, and if EOT was popular you’d easily be able to download tools to do it.
@John Daggett: if you’d look thru the SL docs, you’d notice that Silverlight doesn’t have a solution for commercial fonts. They don’t use EOT because they don’t think they can be considered “documents”.
@Dan – no, SVG punts on embedded fonts in much the same way.
@Robert O’Callahan – not true. You would have to download tools to do it, and re-host the EOT (or TTF). It makes it harder, and intentional.
And @Robert O’Callahan – no, I don’t believe it IS hypocritical – because Silverlight 1) needs the fonts to be in a package starting with SL 2.0, and that package would need to be opened (i.e. you can’t just link to fonts on other people’s systems, 2) has a tool needed to build the files, and 3) warn people explicitly in the documentation that you can’t use commercial fonts this way. Oh, and 4) as I stated in previous comment – they don’t believe they can be considered a document.
And this is your warning – call me hypocritical on your own blog or the IE Blog, not mine.
While pushing for Silverlight adoption, possibily, push for adoption in SAMI encoding for Media Player as well.
EOT and IE’s support for it exists now, today, and that at least allows for the camel’s nose to get into the tent.
An example from the real world:
A web designer goes to myfonts.com looking for a font to use on a web page. myfonts allows the designer to type in some text, choose a size and get an idea of what it will look like.
But the killer is: the font samples generated are bitmaps. And the designer can’t really get an idea of how the font will render as embedded at various sizes unless the sample is HTML text as rendered by the browser. And at that point said designer is most probably not going to cough up money for the font on the gamble that it will hopefully render OK. I wouldn’t, would you?
And so it’s back to square one with Verdana, Arial, et al and Photoshop for the rest.
At least EOT – inside IE – can addresses this basic marketing and distribution problem and address it today.
Things can begin.
I got into web work in an IE-only intranet environement. And there are many of them. If using an embedded font via EOT had productivity and/or accessibility advantages none of my managers would have objected and the few bucks extra required to license and deploy them would have been found. There’s a tendency to think of the Wrrld Wide Web as the end-all and be-all but it ain’t.
If the aim (and it should be) is for embedded fonts to become mainstream, settling for the ability to sneak them in through the back door with Flash and Silverlight is no solution and IMHO it’s a separate issue altogether. I’m a populist at heart, I suppose.
Chris, is it really true that the font has to be in a Silverlight package in SL2? Because I found this blog from an SL program manager:
http://timheuer.com/blog/archive/2008/03/10/embedding-fonts-in-silverlight-2.aspx
which says
> First, the FontFamily is set to “timheuer.ttf” in this example,
> which is my handwriting font in TrueType format. This font is
> located next to the applications XAP file which is in ClientBin.
> It could be located anywhere in the same application domain and you
> could use an absolute URL here as well. For our purposes, we have
> a file on a web server.
> When we set that in the FontFamily to a file, Silverlight
> essentially creates the downloader for us in an efficient manner.
> The font file is requested based on the URI provided and downloaded
> via a GET request.
Have things changed since March? What’s the story?
Thanks for the warning. I did blog:
http://weblogs.mozillazine.org/roc/archives/2008/08/the_coming_batt.html
The article on Web directions contains mis-information and also fails to adequately distinguish between supporting @font-face with direct linking to TTF’s as opposed to EOT’s.
I take particular issue with this statement:
“all the major currently released browsers (IE6, IE7, Firefox 3.1, Opera 9.5, Safari 3) currently, or will shortly, support font linking or embedding using the same @font-face rule. ”
Firstly, if Opera 9.5 supports direct linking to TTF’s via the @font-face rule, it’s a well-kept secret because Opera’s own documentation says it doesn’t (see my previous post) and I’ve tested it. (Never take documentation at face-value.)
Opera has no, repeat, NO font-face support at all.
Secondly, Firefox 3.1 does not support @font-face for direct linking to TTF’s or EOT’s, either.
Thirdly, no evidence is cited that Opera and FF will “shortly” support either of these things.
The evidence, so far, points in the opposite direction. Hakon Wium Lie, the chief technology guy at Opera has been hawking the idea of directly linking to TTF’s for two years now, and Opera still has not done it.
In other words, IMHO, the article is dishing out baloney in the guise of reportage.
Correction: FF3.01 does not support @font-face. What’s going to be in FF3.1 remains to be seen.
Update: Mozilla has decided to make the move. FF 3.1Beta1 supports direct linking to TTF files, via the @font-face rule.
Interestingly, as of Opera 9.6, despite Wiem Lie’s vociferous support, Opera still does not.
Where’s this all heading?
@Richard Fink – I don’t know. I would hope the FF guys come to their senses, but I don’t know.
I’d much rather have a solution that enables using commercial fonts but doesn’t have to destroy any business model for fonts.
@ Richard Fink &
@thacker
Sorry, haven’t visited this blog for a while, so you both may already be aware of this, but EOT font embedding now works just fine in Internet Explorer Beta 2.
I hit the same problem myself when putting together a set of (about 140) standards-based pages on my site. Couldn’t get it working until I had an internal build close to Beta 2. Then one day it just worked as it always had in previous versions of IE.
Among the best fonts I’ve found for reading on screen are the ClearType-optimized fonts we (Microsoft) shipped with Office 2007, Windows Vista and Mac Office 2008. I know, you’d expect me to say that since I ran the group that made them, but it’s still true…
They’re all shipped with their embedding bits set to “Editable”, so they can be freely used for EOT embedding on the Web if you have a license to them – which you get when you buy one of the products with which they ship. So there are hundreds of millions of people out there who already have these fonts and can legally use them with EOT embedding.
I’m using Candara, Calibri and Cambria on my site. I’ve used WEFT to create the EOT font objects. Since I don’t write in either Cyrillic Russian or Greek, I used subsetting to create Latin-based language subsets. This means I only have to create those EOT files once – and I can use them forever, for any pages I create on tha site. The @font-face declarations are stored in the CSS stylesheets, so any page using the same stylesheet just gets them automatically. It took me a few attempts to get it right – but now I never have to think about this issue. The fonts I like to use just show up on the pages (which, BTW, are all HTML 4.01 and CSS3 standards-validated).
I’d like to see people carry out an open-minded test to see how this works.
Install Internet Explorer 8, Beta 2. Go visit my site and watch EOT in action. One caveat: the pages were experimental, and designed to be viewed at 1440 x 900 or better.
There’s a whole book on there, which consists of 112 manually-paginated Web pages. It’s really readable (using Cambria as body text).
If the other browsers would support EOT, the Web could be like this tomorrow.
If EOT became a standard, font foundries would begin re-writing their EULAs.
Implementation for other browsers is trivial – we got an outside contractor to build a sample EOT unpacker in “clean room” conditions, using only the documnentation we have already provided to the W3C. We plan to provide that code as OpenSource.
Let me give a little history here. Improving readability on the screen is what I came to Microsoft to do, and the Web is the most important platform for that.
I’m the guy at Microsoft who commissioned – back in 1995 – two new fonts specifically for reading long passages of text on the screen. You may have heard of Verdana, which was one of them. The other was Georgia.
Back then, I realized the Web needed at least a couple of highly-readable fonts which were so widely distributed that every Web page designer would know they were available on every reader’s machine.
In effect, we “seeded” the Web with those fonts – for free. And then the OpenSource OS vendors blew it for everyone.
But another Webfont pack – whether it’s a handful, or 25 fonts – isn’t the answer, because you’re always still completely dependent on the time it takes to achieve universal distribution. And it still means we don’t have, on the Web, the same situation we have in print: That the creator of the “document” (ie Page) can use any fonts they want, provided they have a license to them, and create as many copies of the “document” in which they’re used, without paying any additional fees. If I’m creating print, I can’t just ship copies of the font I’ve used to my readers so they can also create documents using them.
We’re trying to create the same usage model for commercial fonts on the Web: “Publishing a Web Page Is Just Like Printing”. You buy a copy of the font (or get a license in a product) and you get to use it on the Web in the same way you always have for print.
Is that REALLY so onerous?
We have a technology which was created in consultation with the font industry, way back in the early 90s. We modified TrueType itself to support it, way back then. So the industry knows the technology, they have experience of how it works, and largely support it and feel comfortable about it.
There are a few font creators who have suggested “special licensing” for fonts posted on servers – micropayments, if you like, based on usage.
I’m totally against that. My take is, you should be able to buy a copy of a font just like you buy one for printing (and at the same price), and you get to use it as many times as you like.
But you have to buy it (or get a license to it in a product you bought).
That model means font foundries will get more revenue from their fonts, as more designers buy copies to use on the Web. That’s exactly what happened when desktop publishing replaced traditional publishing in the mid-to-late 1980s; the number of people buying fonts exploded.
I know, I was there…
@Bill
Thanks for the update. I’ve been pressed for time lately but I have been keeping up with new postings here and elsewhere on this.
I’ve spent enough time myself with WEFT and FireFox 3.1, and Safari to come to some conclusions in my own mind about the pros and cons and gotchas surrounding the implementation issues. Even cracked open a few TTF files with an editor to see where that might lead me. White-hat hacking.
File compression is crucial IMHO and EOT’s got that.
Sub-setting (as you did by creating a Latin-only set) is also crucial but I find the WEFT tool very obtuse. The barriers to adoption need to be examined and then removed and/or simplified, one by one. I also find the EULA’s from the font vendors way too complicated and confusing. I still can’t quite figure out what I’m allowed and not allowed to do.
Personally, everything you’ve written makes perfect sense to me.
I have more to say but I’d rather not piecemeal it.
Working on an article about this, off and on and in-between.
Later.
Thanks again for keeping us posted. Greatly appreciated.
@Bill Hill and Chris:
After re-reading Bill’s previous post and looking closely at his online book and new blogozine, and in keeping with web fonts and web readability in general, I want to alert you to a new product called ZoomPerfect. ZoomPerfect uses IE’s own built-in javascript capabilities to turn IE’s Text Size menu into a true Text Zoom and/or Style Switcher. (Solving the accessibility issue Bill mentions on Page 8 of his Blogozine.) With ZoomPerfect, the web designer defines the sizing increments and decides exactly what text on the page gets sized and resized, and more. It’s a completely new approach to the problem – an approach that more sensibly balances the interests of designers with the user’s need to have some control over the size of text.
In short, ZoomPerfect solves the IE Text Size “Bug” that has been, for years, presumed to be unsolvable. IE Resizes Pixels. Finally.
As some pudding for proof, I’ve taken THIS page from this blog and applied ZoomPerfect to it.
Try making changes to the Text Size menu and see what happens.
Available here.
The demo uses ZoomPerfect in Style-Switch mode. Style Switch mode swaps CSS style rules depending upon the user’s selection in the Text Size menu. (It can also react to Zoom, too, but it’s not enabled in this demo.) Unlike other style-switcher methods, ZP greatly simplifies things by using only a single .css file. (You can view the contents of the cwilso.css style sheet in html form, here.) As a little bonus, I was also able to prevent IE from making a needless call to the server for the ie.css file by including the rules from that file in the ZP style sheet and wrapping the link tag to ie.css in a noscript tag, just in case javascript is disabled. (View source will reveal.)
In this sample demo, ZP is used to: 1) prevent text from ever getting unreadably small as it does at Smaller and Smallest; 2) produce a smoother size/resize at Larger or Largest without any bolding or other ungainliness; 3) tweak some line-heights and set a slightly larger base font-size. (Couldn’t resist #3, on my Dell laptop at 800×1220 your site is murder to read.)
Here is another demo from Bill’s online book:
Bill’s page is set in a “fixed” font-size of 16pt (or 12px) which breaks the Text Size menu in IE. And the results from the other alternative, IE’s Page Zoom, are horrendous. In this case ZP is working in Text Zoom mode to bump up the font-size in 1px increments. Somewhat like the type-sizes you see in the larger-type books that are quite popular.
Getting ZoomPerfect and css3-multi-column.js and hyphenator.js to work together harmoniously was a bear, but as a quick and dirty proof of concept, not bad I think. (BTW, hyphenator.js blows me away. It re-hyphenates when the size of the font changes, on the fly, amazing. That guy deserves an award.)
Ver 1.0 of ZP works for IE6, IE7, and IE8 and is to be released concurrently or slightly before the release of IE8. But it’s in “preview” (for want of a better term) now.
Any feedback you might have to share, of course, greatly appreciated: comments@zoomperfect.com.
I completely understand the question Bill is posing: Why is it so damnably hard to re-create a book-like experience in a web page? Hope ZoomPerfect adds a missing piece of that puzzle.
Now that you`re on WordPress, you should help Bill Hill get his BillHillsSite over to WP too… 😉
btw: Are you running the blog on WordPress.Com or IIS ?
Bill actually WANTS to run his own custom server. I suggested WP to him a while ago.
This is running on WordPress.com. It’s easier, and so far I haven’t found much of a reason to go through the hassle of running my own.
Apropos – I’ve owned the domain name readableweb for some years now with the intention of using it to address issues like typography, style, layout, and the like as they relate overall, to the web as a readable medium. (Hence my interest in EOT and Font Embedding.) It feels to me like the time is now right and I”ll be using wordpress – the product, not the company – to create the blog.
I’m sure Bill is looking for tight control over templates and such and so am I.
Not looking forward to climbing the learning curve, but I can’t see any way around it and still get what I want.
If it was my own personal site, I too, wouldn’t go through the hassle.
– Anything at all new on the font-embedding front?
It seems Google Chrome (Beta ver2) now supports @font-face embedding.
Congratulations on the release of IE8. IMHO a job well done. Kudos to you, Dean, and the entire team. What a juggling act!
Chris, EOT proponents could really help web designers out by publishing a list of foundries that are ‘on-board’ so-to-speak; those that permit EOT embedding. So far I see, Ascender, Larabie, and MS mentioned. Are there others? Having a list would sure beat scrounging around foundry websites and poring over EULAs. 🙂 I realize that EOT embedding is made on a per-font basis and not at the foundry level. A list, however imperfect, would be better than nothing at all.
One thing that everyone seems to be dancing around and I’ve only seen mentioned briefly is that the only tool that exists (that I know of) to create EOT files is from Microsoft and only runs on Windows!
If Microsoft truely wants EOT to be accepted then there needs to be the same tools for Mac and Linux as well.