EOT is the best solution for font vendors; the public at large don't care, and designers/developers want a solution - ANY solution - that allows us to use more fonts.

AFAIK, at the moment the only tools for creating EOT fonts are WEFT - which is umpteen years old and Windows-only - and the Ascender tool, which only works with a small pre-selected range of fonts.

So for anyone not developing on Windows - quite a lot of people - there is no option. Therefore, the open solution of Safari (and Firefox 3.1) is the best one.

I think you should credit web developers with the good sense not to contravene licenses with the fonts we use on websites, in the same way that we don't contravene with images, sound, or movies.

Peter Gasston

Definately Font Linking. EOT is just another way of limiting User's choice. No one uses it (as you say, it's been supported since IE4).

Sorry; I appear to have made your site worthless with one single comment!

JB

I'm not sure what to make of this technology as it is only supported in IE at the moment which wreaks of "IE not playing fair".

What I did notice though, is that your pages all have alt attributes on images, and no title attributes. Since the info in this attribute is handy as a tooltip, it would make sense to add a title attribute, since so many people do not use IE.

dave

Agree with Peter:
Definitely font linking. EOT is just another way of limiting User's choice.
No one uses it (as you say, it's been supported since IE4).

I'm looking forward to font linking and @font-face support in major browsers.

The verbiage on this site about Microsoft's EOT technique and WEFT seem confusing. Honestly, I thought EOT was a dead proposal, and am surprised to see anyone promoting it.

"DRM ... would be an awful thing to introduce to the web." Agreed. Let's just avoid DRM, and just use those fonts with licenses that allow font linking.

There already fonts available for @font-face linking (e.g. the Larabie and Jos Buivenga collections, and free fonts), and that's before all major browsers support it. Specifically, some great typefaces are specifically available for font linking in websites, including the Larabie fonts:
http://www.princexml.com/fonts/larabie/index.css
and those from Jos Buivenga: http://www.josbuivenga.demon.nl/
( License: exljbris.wordpress.com/.../ )

Professional designers already make sure that their logos, stock images, illustrations, any music or videos, are properly licensed. Why treat fonts differently?

Michael Montgomery

"I think you should credit web developers with the good sense not to contravene licenses with the fonts we use on websites, in the same way that we don't contravene with images, sound, or movies."

If all you want to use are freeware and open-source fonts on the Web then that's great. However, as mentioned on this site there are no commercial fonts (the fonts web designers want to use according to surveys) available under the Safari/raw-font download scheme. An open-standard EOT format supported by all browsers opens the door to the use of at least some commercial fonts. And hopefully more font foundries will get behind it as a technology.

Fonts are not like images, sounds or movies. With images you can make your own, you can take your own pics, or use licensed commercial images degraded (low-res) for Web use. That's really not possible with fonts.

"Definately Font Linking. EOT is just another way of limiting User's choice. "

Font linking limits choice - to freeware and open source fonts. Sorry with one post I've made your post worthless

Si

However, as mentioned on this site there are no commercial fonts (the fonts web designers want to use according to surveys) available under the Safari/raw-font download scheme.

AFAIK there are none available as EOTs either, so that makes us even ;)

Fonts are not like images, sounds or movies.

No; people actually want to pirate those.

With images you can make your own, you can take your own pics, or use licensed commercial images degraded (low-res) for Web use. That's really not possible with fonts.

No, but there are a LOT of decent alternatives available to first-choice fonts. Of course there are a lot of useless fonts, but it's rather disingenuous to say that no (or few) free fonts are of sufficient quality to use on websites.

Look, I don't want to be misunderstood as saying all fonts should be open for any use; if a font maker wants to limit his fonts, that's his business. But I think that most of them should consider new licenses to accommodate the majority of web designers who want to use good fonts in the right way; not to limit them based on the potential actions of those who don't.

If all the browser makers decide that EOT is the best option, I'm all for it; but what we want is action, now.

Peter Gasston

>AFAIK there are none available as EOTs either, so that makes us even ;)

Actually there's a chart linked to this site that identifies the vendors that allow EOT

>No, but there are a LOT of decent alternatives available to first-choice fonts.

Such as?

>If all the browser makers decide that EOT is the best option, I'm all for it;

I think web designers should have a say, as should type designers.

Si

"Specifically, some great typefaces are specifically available for font linking in websites, including the Larabie fonts:"

Actually Ray hasn't agreed for his fonts to be used under the web-fonts scheme. from Typophile a few months back...

“When it comes to my freeware fonts, I’m more reluctant to allow them to be used that way.”

Si

EOT is a Microsoft Font DRM format. DRM is fundementally contrary to the founding principles of the W3C. I will be shocked if the W3C ratifies a DRM standard.

What next - DRM for images?

John Sanders

Sorry you’re incorrect. EOT contains no DRM. The EOT specification respects the “embedding permissions” put into fonts by their creators.

Some history…

Embedding permissions are defined in TrueType and OpenType specifications. OpenType is an open standard (ISO Open Font Format).

The Web-fonts scheme specifies TrueType (and OpenType works) – so you can’t simply pick and choose which parts of a standard apply and which don’t. Hakon made that clear in his proposals around Web fonts and references these permissions (I don’t agree with his analysis but he recognizes them as being relevant).

The EOT URL binding is required under OpenType to conform to the requirement in the OpenType spec that fonts be embedded within documents. URL binding would, by definition, not be required for open source or public domain fonts.

The W3C understands these issues and as far as I know do not see these as blockers.

Perhaps Ascender could produce an additional page to counter any misunderstanding around EOT and DRM.

Si

>What next - DRM for images?

That ship has sailed. If the GIF and JPEG standards (that pre-date browsers) included permissions settings would browser makers have ignored them? Of course not.

Si

< No, but there are a LOT of decent alternatives available to first-choice fonts. Of course there are a lot of useless fonts, but it's rather disingenuous to say that no (or few) free fonts are of sufficient quality to use on websites.
With font linking you will be limited to free fonts, and will NOT have access to commercial fonts that are popular with designers, ad agencies, publishers, etc. This audience cares about the fonts they select for both print and web-based uses. They want to have a consistent brand, and that means being able to leverage the same commercial fonts they use in print-based publications.

At Ascender all of our fonts are distributed with a EULA that prevents posting fonts to a website. This is true of most all font vendors. So the only way we could allow fonts to be used with a website is with methods such as EOT.

< If all the browser makers decide that EOT is the best option, I'm all for it; but what we want is action, now.
Agreed ! We are hoping that this website can help get the ball rolling to encourage browsers to add support for EOT.

Bill Davis

< Professional designers already make sure that their logos, stock images, illustrations, any music or videos, are properly licensed. Why treat fonts differently?
Because fonts are software files, and in many cases the license agreements have specific language that prevents their being posted to websites for use with Font Linking. That's why EOT represents the best solution to get the font community to support extending their license agreements for use with websites.

Bill Davis

>This is true of most all font vendors.

Actually I think it's true of all font vendors making commerical fonts.

There are currently two experimenters/early-adoptors Ralf Hermann and James Arboghast who are experimenting with licensing models that support the web-fonts scheme in the hopes of finding a business model.

I've actually suggested (somewhat controversially) that font makers license a few fonts for use with the scheme as an experiment. Primarily to see if there’s interest and als0 to draw a line in the sand between available and off-limits fonts.

Si

Hello everyone. I'll get straight to the point: I made my recent Pyke's Peak font available in two versions; the fully-specced commercial version <a href="www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke's Peak</a>, and its lesser sibling <a href="www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke's Peak Zero</a>. PPZero is a "Zero Cost" font licensed for webpage use with the CSS @font-face rule. Visit the vendor page, click on Purchase Options, and download PPZero for zero $. It really is that simple.

PPZero may be distributed on web server in unlimited numbers at zero cost to users, and you may also distribute the font itself in unlimited fashion to free font archive sites such as Dafont, FontFreak and the zillions of others. It's a state-of-the-art OpenType font with the EULA built right into the OTF file itself.

What's in this for me? Designers who use PPZero and like it may wish to purchase the much more capable original mother Pykie font <a href="www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke" rel="nofollow">www.myfonts.com/.../">Pyke's Peak</a>. Pyke's Peak contains over 590 extra glyphs and other goodies, most of them ligatures.

Thanks to Ascender Corp for saddling up on this issue. Thanks too to W3C, Adam Twardoch, Håkon Wium Lie, and most of all to Simon Daniels (Si) for tracking the webfonts debate for us typeface designers and graphic designers, and heading up the discussion panel at Typecon in Buffalo last week.

James Arboghast

Sorry folks I don't know what happened there with the URLs in my post. I had it all correct. Here is the URL for Pyke's Peak and Pyke's Peak Zero:
http://www.myfonts.com/fonts/sentinel/pykes-peak/

James Arboghast

While EOT has been around since '96, Ascender's EULA makes no mention of its allowed use. Paragraph 9 states, "[...]The Font Software may not be installed or Used on a server that can be accessed via the Internet or other external network system (a system other than a LAN) by personal computers which are not Licensed Computers, unless you acquire a license from Ascender granting you this specific right."

Davis, if you are asking developers/designers/browsers to support the technology, shouldn't your EULA reflect such stated use and support?

thacker

So, If I were using windows, I could take any of the many ttf files I already have (came with windows) and convert to EOT and use it?

queefsnoggle

>So, If I were using windows, I could take any of the many ttf files I already have (came with windows) and convert to EOT and use it?

Yes. The Windows font EULA says that you may embed fonts in content based on the embedding permissions encoded within them. So if they allow document embedding then you're fine for EOT. Be sure that the font in question actually did come with Windows - sometimes it’s tricky to tell where a font came from.

Si

<Davis, if you are asking developers/designers/browsers to support the technology, shouldn't your EULA reflect such stated use and support?

Very good question. As you pointed out our EULA is very clear that you cannot upload fonts to a web server, whether as raw .TTF or .OTF fonts, or as EOT or SWF format (for use with sIFR).

We do offer extended licenses for developers who want to use our fonts on a web server. This could be as EOT, and it could also be with Flash or Silverlight applications.

Bill Davis

Davis--

Thanks for the reply.

Does Ascender plan to adjust the EULA to support EOT? If not, why not? Since Ascender sells Microsoft fonts, would the EULA support EOT for just Microsoft fonts to come more in line with Microsoft's font EULA?

Thank you very much.

thacker

Pingback from sitepoint.com

SitePoint Blogs » Custom Web Fonts: Pick Your Poison

sitepoint.com

Pingback from recycleemail.com

  Business,Internet,Technology,Uncategorized | Welcome to the 200th Edition of the SitePoint Tech Times!  — Recycle Email

recycleemail.com

Technologically, EOT makes no sense because it isn't an effective DRM mechanism; an EOT file offers very little protection over what a TTF provides.

Therefore, the benefits of EOT, if any, are purely based on licensing. For that, I have the same question as thacker: Under what terms and pricing are Ascender, Microsoft, and other foundries willing to let us license fonts for use on websites as EOT files? For example, I have a license for all the Vista fonts via various free downloads on the Microsoft website (Powerpoint Viewer 2007, Consolas for VS.NET 2005, and the Chinese/Japanese/Korean Cleartype Font packs). In all those cases, the license said I was allowed to "embed" the fonts in documents, but there is no legal definition of what it means to "embed."

EOT only makes sense if it makes licensing significantly cheaper and easier than it has been historically. Right now, neither Ascender nor Microsoft have EULA's that clearly state the conditions under which we can upload EOT versions of their fonts to a web server, nor do we have any idea of what additional charges (if any) are levied for doing so. It doesn't make sense to build EOT support into a bunch of products only to find out after the fact that licensing fonts for EOT embedding is too expensive or impractical.

Brian Smith

Brian Smith--

There may exist a practical solution. Adobe, Ascender and others are third-party foundries. Adobe creates its own fonts but also sells fonts from other foundries within the Adobe Font bundles. When an ITC font is purchased within an Adobe bundle, the Adobe EULA and any changes made by Adobe to the document rights within the font apply.

A forward thinking foundry may decide to create a practical and functional brand extension of their line of products, e.g. a Web-HTML Font bundle. The bundle would include the foundry's own fonts and fonts from other foundries that are best suited for use within HTML documents. The accompanying EULA reflects support for EOT and the fonts are embedded with the appropriate document rights.

thacker

>In all those cases, the license said I was allowed to "embed" the fonts in documents, but there is no legal definition of what it means to "embed."

Actually the OpenType spec defines this. Microsoft has for ten years promoted the fact that we believe EOT conforms to the OpenType (previously TrueType) definition of document font embedding due to the URL binding tying the font object to a specific Web “document”.

>It doesn't make sense to build EOT support into a bunch of products only to find out after the fact that licensing fonts for EOT embedding is too expensive or impractical.

These are valid concerns, but there is currently no viable alternative that foundries will accept. Unless someone discovers a business model around font linking, EOT will always offer access to more fonts, more fonts designers want to use, than the freeware fonts usable under the font linking scheme.

Si

Si, the technical definition of "embed" is different from the legal definition of embed; or at least, the license doesn't say that it means "embed" in the same way as the OpenType or EOT specifications. Further, the EOT specification says "The RootString in the EOT file must be set by the authoring tool in a manner consistent with the EULA permissions." But, the EULA doesn't define what RootStrings I am allowed to use. Plus, the EOT specification is a technical document with technical, not legal requirements. If I use a NULL RootString to create a EOT for Calibri, am I in violation of the license? It seems not, according to my reading of the license; yet, the RootString restriction is the primary reason EOT is even remotely useful.

The EULAs really need to explicitly talk about the RootStrings and other technical details of the EOT files that are allowed. Otherwise, EOT-generating applications that are not as restrictive as WEFT will render EOT useless.

Brian Smith

>"The RootString in the EOT file must be set by the authoring tool in a manner consistent with the EULA permissions."

I would have to look at that in context, but in this form it doesn't make a lot of sense to me. Maybe it's related to a EULA that explicitly permits the creation of unbound EOTs?

To meet the spec definition of document embedding you need to either embed the font within the document or tie it to the document using URL binding. If that's not clear in the EOT spec then it should be.

Si

I might start to take this thing seriously, as soon as:
- the format is not steered by one single company, documented, available for everyone to implement
- you people as well as Microsoft show up in standards comitees and participate actively without too much of a one-sided agenda (some one-sidedness from is part of the business, I guess)
- there is the OPTION to create unrestricted EOT (in accordance with the font's EULA of course) and tools that support this

I am not against font foundries wanting to protect their work, but all of this smells of vendor lock-in.

If Microsoft and others support either a standardized, unrestricted flavor of EOT that anyone can create and implement or (better) TTF *in addition to* restricted EOT fonts, then this will not hurt anyone. If EOT is meant to be the only font format on the web, then this is trouble unless the format is seriously opened up.

So, *my* preference is Font Linking. I am not against an *additional* option for font embedding.

FC

Si, the problem with the license is that it doesn't reference the specification and the license doesn't require any compliance with the specification. Even if it did so, you'd have a circular situation where the EOT spec. says "do what the license says" and the license says "do what the EOT spec says," and there is still some things that are not specified in either place.

Further, the RootString part of the specification sucks for caching. If I have a license to use a font for my entire site, I cannot put a single EOT file on the site that says "http://briansmith.org/" rel="nofollow">http://briansmith.org/*"; instead, I either have to modify the EOT file once for each page (to add the RootString), or I have to have a separate EOT file for every page. In either case, that makes the use of EOT for large files (especially for CJK fonts) completely impractical because there is no effective way of using HTTP caching for them. The RootString mechanism needs to be extended to allow patterns of some kind, e.g. "http://briansmith.org/" rel="nofollow">http://briansmith.org/*" in order to solve this problem.

Otherwise, if there is going to be a one-to-one correspondence between EOT files and documents, it would make a lot more sense to embed (subsetted) TTF files directly into the documents using "data:" URIs + gzip compression, skipping EOT completely.

Brian Smith

Some valid points. Will work to clarify the rights around MS supplied fonts and get that posted to an official place online. I don't think we'll be able to change the Windows and Office EULAs in the short-term.

If there are failings in the specs then we can get those fixed - that's part of the standardization process.

I fully support the ability for people to make and post unbound EOTs, font-license permitting. Such EOTs would not conform to the OT spec requirements around "document embedding" but that's okay in my opinion. I see no reason to artificially limit the various advantages of EOT (such as compression) to "document embedding" - people should be able to take advantage of EOT as a delivery mechanism providing they have obtained the required distribution rights.

Si

Si, I think there is a useful space between a EOT file being "unbound" (NULL RootString) and a EOT file that is bound to a specific document. If my license to the font allows me to embed it in any document I publish on my website, then I want all my documents to be able to share a common EOT file that can be downloaded once and cached by the browser or intermediaries.

This is especially the case for fonts that allow editable embedding that are used on interactive web pages. For example, imagine a Wikipedia-like cite that wants to embed Corbel. It would be impossible to enumerate every Wiki page in the RootStrings of a single EOT file (the EOT spec only allows 64K URLs per EOT file due to technical limitations, and listing all the URLs would make the EOT file huge, and the set of URLs in the wiki is constantly changing). It would be equally impractical to generate (and force the user to download) a new EOT file for every page, every time each page is edited.

This type of situation came up when I wanted to create EOT files for embedding Corbel on a weblog.

Until these kinds of issues are addressed, I would say that EOT is a good substitute for sIFR (e.g. for display type) but it isn't a practical solution for many situations that I expect to be common. At least, in every situation where I've tried to use use EOT files, the above problem of enumerating each web page always stopped me from doing so.

Brian Smith

>If my license to the font allows me to embed it in any document I publish on my website, then I want all my documents to be able to share a common EOT file

That's already supported - just include "http://en.wikipedia.org/" or equivalent as the binding. A document isn't necessarily a single static page (although it could be), it could just as easily be an online encyclopedia or a blog.

Si

Si and Bill, thanks for your replies. If things are supposed to work as you say then there is no problem. But, the EOT submission says:

The RootString contains one or more full URLs from which the embedded font object may be referenced

and

User Agents must validate that the page using the embedded font is within the list of URLs from which the embedded font object may be legitimately referenced.

It doesn't say anything about any kind of "same-domain" policy or URL-prefix matching like you are suggesting. This is something that needs to be clarified in the specification.

Brian Smith

I am also curious about what kinds of transformations we will be allowed to do to the fonts when converting them to EOT. For example, in the C* fonts there are lining figures, small-caps lining figures, and alternate forms of punctuation (e.g. for all-caps), but there is no way to access those glyphs in HTML+CSS. I've thought about pulling out those glyphs into separate "C*-Lining.EOT" file that makes these alternate glpyhs the default glyphs for these characters. It would be nice if the licensing terms allowed at least this important type of modification until support for OpenType features can be added to CSS.

Thanks again for your replies.

Brian Smith

>But, the EOT submission says:

That will need cleaning up.

Cheers, Si

Si

We would like to know if you think EOT is a better solution for web fonts than font linking.

EOT is not "better" – it's just different. I would want all browsers (including Internet Explorer) to support both techniques.

If I want to use a freeware or Open Source font that allows font linking, why should I be forced to tie it to the website? Especially if the only tool to do this is the outdated WEFT tool.
If I want to upload a commercial font to my website, EOT is obviously the best solution.

I think we should support webfont embedding in every possible way and not start another format war.

Ralf Herrmann

Please please don't push EOT as a reasonable solution - font linking all the way.

EOT is DRM, its not the way the web should work... web developers have the sense and capability to only use licensed fonts, or find a way of preventing them from being downloaded.

Ryan Mitchell

EOT is not DRM in any meaningful or conventional usage of the term.

I've just posted on my Adobe blog about this, and Adobe's position on EOT. Our current license terms allow for EOT usage (with a URL binding). Our license terms do not allow font linking to original format font files.

See: blogs.adobe.com/.../web_fonts_2.html

Cheers,

T

Thomas Phinney