Web Embedding Allowed

Joe Pemberton's picture

Help create the list of pioneering foundries who are not afraid of the digital future. (Did that sound like an agenda? Oops.)

Shout out the type foundries that allow web and other digital embedding (@font-face, sIFR, Cufon, Flash, etc.

_ It's time to put an end to the ugliness of the web.
_ Time to change the licensing model: sell fonts to designers and web hosts and not to every single reader/device owner.
_ Time to let the desktop publishing mindset die like rubylith and the linotype.

Note: Tiffany started a list here, but it quickly became a discussion. (A discussion worth reading, but it wasn't a list.)

I'll start the list:

Type Together: http://www.type-together.com/

Stephen Coles's picture

Joe - Your requests are reasonable, and I know there are many foundries who want to move forward with some sort of web licensing. But in comparing fonts to music remember that iTunes was created and negotiated by a multi-million dollar company with a device and incentive to make the music store happen. There is no single company or cooperative organization in the font world to compare with that. Font manufacturers and their resources are small. The technology and systems for web fonts and licensing will simply come slower.

Sye's picture

@joe - good points and as a customer i agree with them.

@stephen - also good points and as a customer i understand.

:-)

Joe Pemberton's picture

Good point Stephen. It's analogous but you're right that we shouldn't expect to unfold the same way, or as easily.

Re-reading my comment about whining sounds harsh. I'm sorry if I came across as an antagonist.

I've been sitting on a draft of some larger thoughts on this topic, blogged on my Typophile blog that were spurred when I saw the beautiful New York Times Reader app. It's web content, but it avoids a lot of these embedding/licensing issues because a) it's a desktop app and b) it's their font to do whatever they want.

"Digital Branding Demands Custom Typography" http://www.typophile.com/node/58030

Rob O. Font's picture

We will be allowing Web Linking (@font-face) soon! Cufon is against the terms of our existing EULA and will remain so. Use on our fonts by unlicensed users is prohibited by trademark and copyright laws and we will enforce them where possible. SiFR will be part of our permissions. Flash is not a separate thing.

Sii: "Any embedding permissions chart will be pretty massive..."
How big is your Permissions Table, fella? We have even wider needs than MS, as you can imagine, so it's complex, but its doable...and we don't think anyone cares how big it is. All permissions being covered by a single Embedding & Linking User Addendum in our license is a problem to, but doable. I bet our Addendum's longer than yours, because again, we don't care how long it is.

Joe: "...the beautiful New York Times Reader...It’s web content..."
It works, I believe, because it is not web content, if I take your context correctly.

John: "PDF? Okay. Flash? Okay. sIFR? Okay"
If: a. it embeds, truly, there is no font file, just a file, b. it never unpacks a font 'in front of' the user, nor leaves fonts around, c. it subsets by document requirement, d. it leaves most of the intellectual property where the file was authored,

Then: Okay. (Cufon aims to short-circuit this to some extent. As I study it, it gets uglier.)

If: a. it can't agree what format it wants, b. it can't agree how it's going to install/manage these formats, c. it can't agree on how to interpret, scale or render, d. it can't agree on how to move towards agreement,

Then: well, okay. We, the font industry will let go of our fears, (whatever that means).

John: "Asking what kind of business models will be possible with the technical developments before us."

This is exactly what we've done/been doing @FB. But...we had to go looking for a "magical technical solution" because of the one presented to us when @font-face's "magical recommendations" started being followed. We've chosen an optional OT table to spare you-all the drama of revising a required OT table.

Though music is a fine analogy to fonts when music is distributed by the instrument (in which case there is a totally different use to the software), I'd suggest maybe reading up on Drivers Licenses. They don't actually "do anything" either, just like our Permissions Table and our Embedding & Linking User's Addendum.

Cheers!

dezcom's picture

My god, something might actually happen with this? Grrrrreat;-)

ChrisL

Joe Pemberton's picture

Thanks for your thoughtful response and for the window into Font Bureau's approach.

The web ≠ The browser

I say it's "web content" because it's content served from a web server, viewed by a client application on a remote machine. The NYTimes Reader that is a Flash application built on Adobe's AIR platform and the fonts are embedded in the app, not installed on the desktop or the OS level. But I wouldn't limit web content to mean stuff that's viewed in a browser.

The Xbox, iPhone, PS3, Wii, Chumby, G1, Blackberry, etc, etc, are all delivering web content to people, sometimes in browsers on those devices, but most often not delivered through a browser. Where will the fonts live? Will they live at the OS level of the device or will they live in the apps or widgets users download? That's the horizon to solve for.

iPhone apps and Safari for iPhone both deliver web-based content. The former uses fonts embedded in the apps, the latter requires fonts installed at the iPhone OS level.

fonthead's picture

I have just updated the Fonthead license agreement with fairly loose licensing. My thanks the James Puckett and his EULA. I see you took the MyFonts EULA and modified. I essentially just did the same thing and tried to delineate between PDF, web and application embedding. Here's the gist of it:

4a. Adobe Portable Document Format ("PDF") Embedding
You may embed the licensed fonts into any read-only PDF you send to third parties. Such documents may only be viewable and printable (but not editable) by the recipients.

4b. HTML Web Page Embedding
You may embed the licensed fonts into HTML web pages for the purpose of typesetting the page using any of the following methods and technologies: @font-face Cascading Style Sheet ("CSS") rules, Adobe Flash files, Microsoft Silverlight files, sIFR, fLIR, Cufón and Typeface.js. Other technologies not listed here that would allow a designer to typeset web pages using the licensed fonts are allowed providing that the licensed fonts themselves are not obviously downloadable and reasonably hidden from average users

4c. Application and Game Embedding
You may embed the licensed fonts into any application or game displayed through a computing device with the following caveat:
If the application allows end-users to render custom typographic design or content using the licensed fonts for the purpose of creating a customized design, you must purchase a 15-device license. For example, your website allows visitors to typeset a t-shirt or bumper stickers or promotional items using the licensed fonts.

------

I look at my license more in the sense that it is for conscientious people who desire to do what is right. I'd rather err on giving too much away. My fonts are pretty low-grade compared to likes of many of you, so I guess I have less to protect. I see less restrictive licensing as a way to build more business as it leaves a wider door open.

My 2 cents. Whatever they are worth!

Ethan Dunham

blank's picture

And the snowball gathers mass!

@ethan: I like that you simplified things so much. I will probably do something similar with the next revision of my license. Your application and game embedding license is also interesting—since you already run your own store, why not sell embedding licenses specifically?

fonthead's picture

@James: I try very hard to keep things simple. That's why I don't have multiple licensing options. It is like Apple's approach. The fewer the options the less confusing it is and an easier purchase.

And after selling fonts for 14 years, I guess I finally decided to cover all my bases in the license itself. I answer a lot of emails asking for clarification about what someone can and cannot do. It ended up being significantly longer than my older one, but seems more complete.

Ethan

ralf h.'s picture

Started a wiki page for foundries supporting @font-face:
http://webfonts.info/wiki/index.php?title=Commercial_foundries_which_all...

Let me know if there are more.

Si_Daniels's picture

Ethan 4a seems rather narrow compared to the other broad rights you provide. I particularly like 4c which would let me ship one of your fonts to a billion Office customers for the price of a 15 device license :-) but back to 4a - how about PDFs posted to the Web?

Michael Jarboe's picture

As soon as I have a chance to get in and edit our EULA we will support @font-face. Plan to loosen things up as soon as possible, I'm tracking this post so I'll chime in when I get it revised.

Rob O. Font's picture

Joe>The web ≠ The browser

Perhaps more specifically in your native weight;>
HTML/CSS+UA ≠ ??ML/?+UA ≠ Air/Bravo+UA.

Cheers!

Joe Pemberton's picture

Fine. You win. I'll take my toys, my geeky talk and go home.

John Hudson's picture

Tal Leming's suggestion for web font embedding permission is both simple and sensible:

http://talleming.com/2009/04/21/web-fonts/

The only thing lacking, from that proposal and from much of the discussion of web fonts, is a clear statement of what is meant by ‘web embedding’. The variety of different file types being served over the Internet -- some document-like, some application-like -- really demands some clear statement about what permission to embed/link a font for the web actually means. What is permitted by the permit?

Rob O. Font's picture

Joe, I'm not trying to win, but to expose the discussion to the actual specifics.
Everyone is asking for this, and I am trying to oblige to the best of my knowledge.

As John says, a clear statement of what is meant by ‘web embedding’ is critical.

>What is permitted by the permit?

This is exactly (though not only) what the permission table is being designed to do.

>Tal Leming’s suggestion: Tal says in his post, "One simple change to the OpenType spec, that's all there is too it!"
Tal's proposal calls for a rev to all fonts (agreed!), all browsers (a year at least?), the OT spec (a year?), and the OFF spec (2 years from now?)... Even if it all happened this summer, it is hardy 'a' simple change.

Our proposal is simpler, forward thinking and self-rev-contained within our industry.

Cheers!

fonthead's picture

@sil Wow, excellent insight. Definitely need to reword my application section. As for PDFs, what difference would the distribution make? I assume that most PDFs are downloaded from websites, no?

fonthead's picture

I reworked part of the embedding text. I think I was trying to lay out too much scope without knowing the particulars of someone's intentions. Since I've only licensed for application embedding a few times, I think adding a permissions statement is enough and allows me to judge on a case by case basis.

I appreciate the thoughts, everyone.

4b. HTML Web Page Embedding
You may embed the licensed fonts into HTML web pages only for the purpose of typesetting the page using any of the following methods and technologies: @font-face Cascading Style Sheet ("CSS") rules, Adobe Flash files, Microsoft Silverlight files, sIFR, fLIR, Cufón and Typeface.js. Other technologies not listed here that would allow a designer to typeset web pages using the licensed fonts are allowed. The licensed fonts must not be obviously downloadable and must be reasonably hidden from average users with whatever web page embedding method you employ.

4c. Application and Game Embedding
You may embed the licensed fonts into a computer application or game only with the written permission of Fonthead Design Inc. Additional licensing fees may apply.

Michael Jarboe's picture

Okay you can add us to the list if you'd so desire, appreciate it. A like the idea of being aligned with a new protocol for this digital age were living in.

Rob O. Font's picture

Fonthead, I very much admire you taking the bull by the horns for your users.

>The licensed fonts must not be obviously downloadable and must be reasonably hidden from average users with whatever web page embedding method you employ.

The first part is impossible, I think. . . @font-face means : the font file is linked by url in the CSS, the url says where the font is, the font is downloaded and installed from the server to the user's cpu. @font-face demands that the files at the end of the url be downloadable. There is no embedding of the font 'in' anything.

Cheers!

Christopher Slye's picture

I am actually really bothered by the term "embedding" as it is a typically used for this topic.

When font data is included in a file -- as it is often in a PDF or Flash file -- it is embedded. The font data moves with the file, is copied, transmitted etc.

When a font reference is made in a document, as with @font-face, there is no embedding (IMO). An HTML document (for example) has an instruction that says, "Go get the font from this place". The font is retrieved and used as needed. The font might end up stored or cached as a result of this, but that isn't the essence of the process.

Using this word, "embedding," is, I think, causing some confusion about different methods, and conflates PDF or Flash font embedding with web font serving, which to me are completely different. Many foundries don't mind font data being embedded in a PDF, because it is (usually) deconstructed, obscured, and somewhat protected, but having a font file sitting exposed on a server for all to take is alarming. From the perspective of a EULA, it's probably going to be treated quite separately.

Tal observes that most designers see font embedding bits as applying to PDFs, which sounds right to me -- but he misses the point that the reason they don't think the embedding bit applies to "web embedding" is because, I think, "web embedding" really isn't embedding.

What we are really talking about is font serving (or is there a better word?). Foundries want a way to serve fonts to web browsers and other clients which doesn't make those fonts easy to steal.

I understand it's just a word, and many people understand the difference, but I think it's confusing for other people and might be corrupting the discussion to some degree.

John Hudson's picture

Christopher, I agree wholeheartedly: the terminology is a real problem. These comments from Bert Bos (W3C) to the ATypI list may be helpful:

A characteristic of embedding is that the font is as much associated
with the document as the document with the font: when you have one, you
automatically have the other, because they are just one file.

A characteristic of linking as we use it on the Web is that it is
unidirectional: the document links to the style sheet, but given just
the style sheet you don't know what document uses it.

That is a very powerful feature: you can use the style sheet from
anywhere on the Web and in as many documents as you like, without ever
having to change or copy the style sheet. But such unlimited re-use is
probably not compatible with the typical licenses for embeddable fonts.

So we either need to change the licensing model for fonts (not something
I expect to happen soon), invent a way to put a font file inside an
HTML file (not easy), or create bi-directional links. In my mind, the
latter is as good as putting the document and the font in one file;
better in some respects, because for many uses of the document you
don't need the font and thus have a smaller file to deal with.

aluminum's picture

Christopher brings up another excellent point. @font-face isn't embedding any more than an img tag is embedding.

The confusion continues...

"Foundries want a way to serve fonts to web browsers and other clients which doesn’t make those fonts easy to steal."

And therein lies the potential problem. If I understand dberlow's proposal (and other similar ones) there will end up being a mild form of DRM in the font that says "this particular font file can or can't be 'served' via an @font-face request". If that is correct (dberlow or anyone else please correct me if I am wrong) we are then assuming that:

- all HTML rendering software is going to be updated to obey said bit flag
- no one will write a browser add-on to circumvent said bit flag
- no one will create yet-another-open source browser that ignores it
- and I'm sure a few other gotchas I haven't thought of.

Seems like that's a lot to assume.

Gus Winterbottom's picture

sIFR looks remarkably similar to this clickjacking exploit. Could sIFR become a malware vector?

aluminum's picture

sure, sIFR being flash, and dependent on a plugin, could be exploited. Clickjacking, as described in that article, is really just exploiting basic layout features of HTML and CSS.

Rob O. Font's picture

Alum.>Seems like that’s a lot to assume.
I don't assume that any of it.
I never stated your first hyphen, your second depends on the first, the third is related to the first wrong assumption as well and that part of your post makes me curious as to exactly what you are reading and who wrote it. ;)

The Permissions table proposal is designed as an Optional OT table, to state the permissions allowed between the owner of the font and the licensee. There is no DRM demanded or assumed and no other applications will be required to rev. for it to accomplish it's intended task.

The one assumption the strategy of the permission table makes is that eventually all W3C compliant UAs share one @fontface font format in common. That is not the current situation, and probably a good way for the W3C to move this along if they can.

Bert via John>So we either need to change the licensing model for fonts
This year we plan to add to our licensing model. But until every single solitary printer in the world, which needs a font it doesn't have in memory, is online to the web, we can't just change the licensing model for fonts. :)

>invent a way to put a font file inside an HTML file (not easy),
Is anyone even working on it?

>or create bi-directional links.
This will be permitted in said table. Assuming this means the table can contain both the url of the font's server one is permitted to link to, and the url(s) at which the font is allowed to be displayed.

We also believe in permitting uni-directional links for the sake of some client types.

Alum.>Christopher brings up another excellent point. @font-face isn’t embedding any more than an img tag is embedding...The confusion continues...

I can see that for sure. Are you only reading alternating posts? ;)

Cheers!

aluminum's picture

"This will be permitted in said table. Assuming this means the table can contain both the url of the font’s server one is permitted to link to, and the url(s) at which the font is allowed to be displayed."

As it is now, a browser request a URL from a server, which typically serves back an HTML document. That document contains a list of requested assets. @font-face would be one of those. It then goes an requests it from the server hosting the asset. Where does the permissions table come into play in this scenario? What is 'pinging' that table? The browser? The server hosting the web site and font? That's the part of the proposal I'm not understanding.

[EDIT: or is the intent that we'd request the typeface via @font-face directly from the type foundry's own servers?]

"I can see that for sure. Are you only reading alternating posts?"

God damn it's hard to keep a civil discussion going with you. I'll try, though. ;)

Christopher Slye's picture

Are you only reading alternating posts? ;)

I don't know how you managed to slip in your comment before mine. I know I didn't take an hour and fifteen minutes writing it!

Anyhow, thanks for bringing it up. I agree. :)

Rob O. Font's picture

> Where does the permissions table come into play in this scenario?

Before any of what you describe, and only before, so far, and for the foreseeable future.

>What is ’pinging’ that table?

Depends on what services the pinger wants to provide. There are no required pings.

What would you like to ping it?

>...or is the intent that we’d request the typeface via @font-face directly from the type foundry’s own servers?]

@font-face directly from the type foundry’s own server is intended as one of our least expensive licenses. For a previously licensed font for print or pdf embedding or for a font new to the user, the simplest user can go to a web site, pay a small fee, and get a url to link their css to. The font, in the permissions table, will record the domain to which the font becomes an asset, and the url from which the font is serve-able.

Cheers!

aluminum's picture

"What would you like to ping it?"

I'm just trying to understand what in your proposed system does what.

"@font-face directly from the type foundry’s own server is intended as one of our least expensive licenses."

Ah! OK. Well, that makes some sense from a technical standpoint. Thanks for that explanation!

miha's picture

invent a way to put a font file inside an HTML file (not easy)

It’s a nice and officialy possible idea. You can “embed” files in HTML with data URI scheme. Actually, it’s better to embed them in CSS file, because of chaching and redudancy. Here is an example of embeded image in CSS: link.

In theory, it should work for font files too (browser support?). So, CSS would look like this:

@font-face {
font-family: Font_name;
src: url(data:image/gif;base64,R0lGODlhEAA/*font data…*/OALMAAOazToeHh0tLS/7LZv/0jvb29t/f3/);
}

Furthermore, if combined with unicode-range, font could be scattered in multiple parts in CSS file, making it unpossible to manually get the whole font file. Example:

@font-face {
font-family: Font_name;
src: url(data:image/gif;base64,R0lGODlhEAA/*font data…*/OALMAAOazToeHh0tLS/7LZv/0jvb29t/f3/);
unicode-range: U+000?;
}

@font-face {
font-family: Font_name;
src: url(data:image/gif;base64,R0lGODlhEAA/*font data…*/OALMAAOazToeHh0tLS/7LZv/0jvb29t/f3/);
unicode-range: U+001?;
/* etc … unicode ranges for all characters */
}

Good side of this is a mild DRM protection. It’s something like fonts in Flash, but just a little less protected.

Bad side is additional work for web designer. In best case, an program has to be used with input of font file and an output of text (wich is then copied in CSS file). There is also a little more time to download the whole thing and just a little more time for browser to compute everything.

Sye's picture

another for the list: SMeltery as stated here: http://www.smeltery.net/SMFFEULA.html

SMELTERY FREE FONT END USER LICENSE AGREEMENT
SMFF EULA version 1.2, november 2008

Embedding this font in a PDF document is allowed.

Embedding this font in a web page with a @font-face declaration is allowed once you credit SMeltery with a link somewhere on your site.

jdaggett's picture

One thing to keep in mind when considering different forms of font obfuscation is that the 'name' table of a downloaded font is effectively ignored when loaded via an @font-face rule, since a downloadable font needs to be private to the document in which it's used. The font-family descriptor name in the @font-face definition is the name used to group together a set of faces. So for web-only fonts, it would work just fine to ship fonts with GUID's for the family name of each face along with sample @font-face definitions for inclusion in stylesheets. Anyone attempting to use the font as a desktop font will see very funky entries in their font menu.

@miha: Data URI's work fine but they're not terribly efficient, the font will always be downloaded whether it's used or not. If you're setting up a site-wide stylesheet that won't scale very well. Using unicode-range per-glyph will break kerning.

[Note: data URL's could also be used to write a TT/OT font editor in Javascript!]

ilynam's picture

Wordshape typefaces are licensable for siFr and @font-face.
http://wordshape.com

blank's picture

Lino/Mino/ITC has a new EULA that allows EOT use, but only with non-commercial web sites. I guess that you’re supposed to contact someone over there to work out an agreement to do it for commercial embedding, but nobody seems to have explained that yet.

aaronbell's picture

Well, that is an interesting update. I guess that means that they're not supporting the new Typekit system and rather favoring EOT.

blank's picture

Apparently “non-commercial” in the Lino/Mono/ITC license would actually allow used on most of the web. Allan Haley expains by way of Typegirl:

Monotype Imaging has three types of commercial use categories: Web site content, commercial product and commercial use. These use categories cover the use of fonts in EOT as well as other font formats. Business models are being finalized to support each category.
Commercial Web site content: Commercial Web site content use covers the use of EOT fonts on the Web site of a commercial enterprise. The Web site cannot charge for the content that is displayed in the EOT font or allow the user to interact with the font (content displayed in the EOT font can be read and printed only) to fit into the commercial Web site use category.
Commercial Product: Commercial product use covers the inclusion of fonts in any format in a product that is sold. Games and e-books that ship with a font are examples of commercial product use. Commercial product use also covers the display of content on a Web site that a user must pay for in order to access. An example is an online magazine such as ConsumerReports.org.
Commercial Use: The commercial use category covers scenarios where users can interact with fonts that are embedded within a document or application that is stored on a server. This category includes companies selling products that are created with hosted fonts such as a Web site that allows users to interact with a font to create a custom greeting card. It also includes application service provider (ASP) and software as a service (SAAS) companies such as Web sites that allows users to interact with fonts to create a document that can be shared.

aluminum's picture

Unless Firefox adopts EOT, I don't think too many web developers will be jumping on board with Linotype anytime soon.

aaronbell's picture

Well, that's the thing. Monotype, Linotype and ITC are pretty big names in the industry. In addition, we don't even know who is onboard with typekit (if anyone actually is). Usually when one or more big players in an industry do the same thing at the same time, it indicates a shift and FF / Safari may end up supporting EOT simply because the big players are pushing for it.

In any case, it will be interesting to see how this plays out now. Will EOT become more widely accepted? or just (continued to be) ignored? It all depends on FF & safari at this point.

ralf h.'s picture

It all depends on FF & safari at this point.

It depends on the users! The Adobe EULA also allows EOT linking, but as far as I know, no webdesigner was ever interested in such an IE-only solution. So I don't think the new Monotype EULA will change anything. I guess they wanted to do something about webfonts, but didn't dare to go all the way. (Which is understandably of course)

abattis's picture

I hope all font vendors will support EOT vigorously. :-)

Rob O. Font's picture

We will support EOT 'vigorously - through our permissions table.:-) But...

no web designer has proven a site design that can query a UA for the right font format to download to that user.
no browser guild is pressing for a single font format to be common among all browsers, even if they have a pet format.
no foundry can serve moderately successful font linking, and only a handful of hosting services can be considered.
no commercial OS's are 'ready' for low resolution readability, though wysiwyg works just fine, thanks!

We really wish someone else 'out there' would move along as fast as we are, because this is looking like someone else's problems and users are beginning see that. :)

Cheers!

Richard Fink's picture

David,

Direct linking of fonts to web pages must happen. Period.
The need has now become pressing.
And it will happen whether anyone in the font industry likes it or not. (This is just a statement. I'm not an advocate one way or the other.)
However, it is going to take years for it to unfold and there is time to influence its direction to your benefit.

I read opinions about font-linking all the time on forums and come away almost always shaking my head at the extent to which the cart is being put before the horse.

Here's one example of what I mean:

Let's, for arguments sake, assume The Font Bureau offers a completely open license for font Caslon FB with regards to web use. If you buy it, you can use it without restriction.
A lot of freedom for the money right? Well, right now, as a web developer, I would have to pass on the offer.
I would have to pass unless you were willing to refund my money if Caslon FB turned out to be unusable for the design purpose to which I want to put it. (Which it probably will be.)
The reason is this: Bitmap representations of fonts are horribly inaccurate when it comes to assessing how the font will actually look when used to present normal HTML text within the browser. In assessing how the font will look at different point sizes, it is absoutely useless.
A specimen pdf does me absolutely no good in assessing, either.
Plus, your web site only offers sample bitmaps in two sizes, 24pt and 36pt which, at best, might give me an idea of how the font would look if I were to use it for unusually large headlines and unusually large headlines alone.
In other words, your sales presentation is totally geared to print.
I have absolutely no way to assess your product for the purpose of web design.

So, you can amend your licenses any which way you want and you still can't get me as a customer. Not because I'm not interested, but because I won't buy a pig in a poke.
(Provided they still keep pigs in pokes. If not, substitute another analogy.)

Jokes aside, are you getting what I'm telling you?
Potential customers, quite willing to pay, will be driven to get samples of your fonts on the darknet just in order to test them. Just to see if they work onscreen.

Vlad Levantovsky's picture

I hope some clarifications will help make things clear:

Non-commercial vs. commercial use.
As Allan Haley already explained, Monotype, Linotype and ITC support both commercial and non-commercial uses. Web font embedding for non-commercial use comes for free (one just need to buy a font); commercial use will require additional license and fee. The vast majority of the websites (such as individual blogs, schools, churches, etc.) are non-commercial, and using fonts on these websites will not require any additional costs. The commercial use is mentioned in the press release, but an emphasis was made on free license for non-commercial use.

EOT adoption
I believe that EOT as a technical solution is an good technology for web font embedding; it is the only technology available today that provides reasonable level of IP protection for font vendors and is supported by 3/4 of all browsers (IE) in use today. This is why new EULA allows EOT font linking.
EOT hasn't been widely adopted because until recently there was no public specification that would allow to implement it. The reasons that some browser vendors are reluctant to support EOT today are mostly non-technical and, among others, are related to technology IPR licensing. Monotype wants to see high quality typography and fonts on the web and we did go all the way - we joined the W3C, paid our dues (literally) and are dedicated to work with all browser and font vendors to come up with the technical and IPR licensing solution for web font linking that will be widely adopted. I do not support raw font embedding, in my opinion it has drawbacks beyond IP protection, which became evident for early adopters (http://lists.w3.org/Archives/Public/www-style/2009May/0036.html).
A good technical solution (and not just any solution) that is universally supported by all browsers will benefit everybody - web designers, font vendors and millions of websites and their visitors. Earlier in this thread, iTunes was brought up as an example of a successful business model but it is based on sophisticated technology that employs a strong DRM protection. EOT is not DRM despite what some people want you to believe, but it does have sufficient technical barriers in place that prevent "drive-by" access to unlicensed font resources, provide reasonable protection of font vendors' IP and optimize font data for web use, especially on slow connections. Monotype is eager to work with all browser vendors to come up with a good solution (and I believe it will happen soon). We are reluctant to support a raw font solution that was proposed with no consideration for font vendors (http://news.cnet.com/Microsofts-forgotten-monopoly/2010-1032_3-6085417.html) and doesn’t satisfy the needs of many web designers and users (http://blogs.adobe.com/typblography/2007/11/web_user_survey_results.html).

blank's picture

The need has now become pressing.

Yes, civilization is in grave danger of too much Verdana. Very pressing indeed.

Si_Daniels's picture

Maybe old news... "So, there isn’t much new to report on that front in Opera 10, but it’s worthy to note the beta does include support for the controversial @font-face rule."

Via... http://www.webmonkey.com/blog/Opera_10_Beta_1_Offers_Speed_and_a_New_Int...

Rob O. Font's picture

>Direct linking of fonts to web pages must happen.

I think I've made clear, that I know this.

>Potential customers, quite willing to pay, will be driven to get samples of your fonts .... Just to see if they work onscreen.

That is why the combination of Permissions and Recommendations in a single table is our starting solution. Without it, we will not be motivated/rewarded to make fonts that look good at all sizes and make good typography possible in all uses.

>A specimen pdf does me absolutely no good in assessing, either.

Do you know, Richard, what will work for assessing how the font you choose will look on all and any devices, users, and user choices? Do you know what it takes to make a font that will pass all such inspections during purchase?

>the cart is being put before the horse.

That is why I am driving my own.

>Monotype wants to see high quality typography and fonts on the web and we did go all the way

Really!? Then start at the beginning, not in the middle and explain how your plan will help see high quality typography and fonts on the web.

>Maybe old news...
Sii, have you seen your Panose monkey? Can't we please have Sota and Atypi conferences again for the 4th straight year where we're compelled by the sponsors not to talk about meaningful web font issues? It worked for so long, what happened?

Cheers!

Si_Daniels's picture

>Can’t we please have Sota and Atypi conferences again for the 4th straight year ... talk about meaningful web font issues?

Despite putting this on the agenda at both events year after year (starting at TypeCon Boston), and bringing the W3C, Opera, Adobe, Apple, Roger Black and other notable players to the table to discuss the issue, no one seems very interested in Web fonts. If you want to talk about it at ATypI or TypeCon I'm sure the organizers would love to hear from you.

Richard Fink's picture

>"Do you know, Richard, what will work for assessing how the font you choose will look on all and any devices, users, and user choices? Do you know what it takes to make a font that will pass all such inspections during purchase?"
Yeah, I do. And I'm not asking for that. I'm not saying you should be held to an impossible standard. Let me narrow it down: I'm looking for a way to see, before I buy, how a font renders in a browser as HTML text on a typical LCD screen at the sizes that matter most in web design. Those sizes being, roughly, in CSS values: 10px to 36px or the equivalent point sizes of 7pt to 27pt. I don't think that's too much to ask, is it? I mean, just let me see how it renders in my browser under normal circumstances.
Off the top of my head, you can give me that in any one of three ways:
1) Show me a specimen page using EOT - as Vlad points out, IE still has 70% of the market. It's available on every Windows machine. No web designer worth their salt - even if they are Mac users - doesn't keep a Windows machine handy for testing.
2) If you don't want to keep it IE specific, for Safari, etc... you can link a narrowly subsetted and specially named TTF/OTF file to the specimen page. That would be enough for me.
3) Lastly, a specimen page consisting of a screen grab from an LCD screen saved as a .bmp file is quick and easy to create.(With the screen resolution properly set to match the native resolution of the screen) It's not as convincing and authoritative as an actual linked font file, but better than nothing. Providing both would be wise.

Unfortunately, when this is done and the bitmap anti-aliased mask is peeled away, the vast majority of fonts that look fine in print, or even an E-Paper screen, look like sh-t in a browser under usual circumstances. (And this will almost always be true when they are compared to the Microsoft Cleartype fonts, which seem to be the gold standard at this point.)
But I'm entitled to know all this before I buy.
And once the truth is apparent, we can move on to address the reasons why and improve the situation. You want money to do the additional hinting? I, for one, don't mind paying you for that.

>"(EOT) is the only technology available today that provides reasonable level of IP protection for font vendors and is supported by 3/4 of all browsers (IE) in use today."

This is a fact. If web developers don't want to wait another 10-15 years for font-linking, EOT has to be accepted and embraced. It is, as they say in military terms, "a fact on the ground."
If the W3C comes along with something similar down the road, fine. Then add support for that format, as well. But today, this is what we have to work with.

@jp
I knew when I wrote that line about "pressing" , somebody was going to run with it - I certainly would have. (Hah!)

Rob O. Font's picture

Touchy.

Syndicate content Syndicate content