Jos Buivenga allows for @font-face embedding with the free weights of his fonts. (And others as listed above by Joe.)

Exljbris Fonts: http://www.josbuivenga.demon.nl/

http://typophile.com/node/56316

What's with Type Together? I don't see support for something like @fontface/sIFR/cufon in their EULA
http://www.type-together.com/resources/eula/TT-EULA.pdf
Only "secure" subset embedding for non-commercial use.

I think the comments on Twitter might have been a misunderstanding. I've asked them to come and comment.

insigne allows web and .pdf embedding.

www.insignedesign.com

Thanks for starting this thread Joe. I only hope that it doesn't turn into a battle of opinions, but rather a genuine resource for a very simple question: Who allows what and where can I buy it?

I think the different web embedding needs to be outlined. There are foundries that allow sIFR with their basic license. There are also foundries that allow sIFR but only with extended licensing. There are very few foundries who allow @font-face and/or the use of Cufón.

I agree with you Zara. I just think when people foundry-x allows for web embedding that is too vague an answer. They need to state in which forms it is allowed.

The future is now!

http://www.fonts.info and http://www.theleagueofmoveabletype.com/ appear to allow @font-face embedding.

http://www.cape-arcona.com appears to allow "secure" web embedding, but likely does not support @font-face.

We have always allowed PDF embedding for workflow and internal uses. Our new website will launch in a few weeks with a new EULA which will allow sIFR and Flash embedding as part of the basic license. My web guys are working on some new things that may allow us to go further than that.

[[Terminal Design]] http://www.terminaldesign.com

For my commercial fonts I allow PDF embedding for workflow and internal uses also and secure web embedding, unless it's used for customization tools (online graphics editor for instance), in that case a special license is needed.

My freeware has been updated to allow "editing of the document". I will allow all web embedding for the freeware. Should I go further with "installable mode"? Would that be necessary?

-Jess
bvfonts.com
http://twitter.com/bvfonts

We need to create another chart. Or at least a wiki entry for Cufón, @Font-face and sIFR.

Not sure how helpful this list will be as most foundries allow PDF embedding. Need to be more specific about technologies to make the list more useful.

Yes, Tif - I agree. The specifics should be outlined.

Well, as Tiffany says, if we are looking specifically at foundries that allow web embedding rather than just considering PDF embedding, it should still be useful. Especially at the differentiation between sIFR, Cufón and @font-face given the differentiation in technologies between them. We may also want to add fLIR (or facelift) to the list as well to cover the full range of different embedding methods that exist at the moment.

Looks like we need to update our EULA :)

We have always allowed PDF embedding for workflow and internal uses and do also allow secure web embedding in PDF and flash, which covers sIFR and i think Cufon too.

We do NOT allow font-linking, in sense that the font files reside on a server. If i understand Font-face correctly, then this is not covered.

We're collaborating with a web company on a font-license scheme which will allow fonts to be linked to a website easily and painlessly. It should be launched very soon.

>secure web embedding

sorry but that's an oxymoron :-(

There's a PDF embedding topic I'd like to see addressed, although there aren't a lot of people in my situation. We submit new business proposals to various government agencies in response to RFPs, BAAs, etc., and the agency always wants a PDF in addition to the hard copies and Word files. The PDF isn't public in the sense that it's included in a product we sell to the general public, or posted on a web site, but it's hard to see it as workflow or internal distribution. What kind of a license do I need? Is the regular license OK, or do I have to buy an embedding license?

sIRF is a secure font embedding tool. Technically almost all fonts should be allowed to be used with it (I've personally not come across any EULA's that forbid flash embedding).

Font-face and cufon are not 100% secure. I'm interested in a list that allows for these in their EULA's because cufon is like 100000000000x easier to set up than sIRF.

Cufon is not flash, just to clarify.

Cross-posted:
http://typophile.com/node/57934
http://typophile.com/node/56316

Do these threads intend to produce something different than Ralf's wiki page?
http://www.webfonts.info/wiki/index.php?title=Fonts_available_for_%40fon...

... if not, and for the sake of community participation, perhaps that could be used as a starting point for a Typophile wiki page.

If the only difference between the list we're trying to assemble here and the list Ralf has begun is that we're attempting to cross-index licensing nuances with web technologies like sIFR, Cufón, and FLIR, I don't think it's worth the time. @font-face is ready to go. Focus on that list.

Gus,

We have many clients that are in your situation, and we always consider this use to be within workflow. We do ask that the pdf be password protected against content extraction, if possible, but that is all.

We always encourage our users to ask us when they are unsure of what is an allowed use. We usually are very accommodating.

… if not, and for the sake of community participation, perhaps that could be used as a starting point for a Typophile wiki page.

I think this is exactly what we would like to see happen, that list is exactly the kind of resource I had in mind.

Ralf: Would you have any objections to using your current list as a starting point for a Typophile Wiki page? If so, it would be ideal if you authored it (not to create more work for you) :)

_ Time to change the licensing model: sell fonts to designers and web hosts and not to every single reader/device owner.

Joe, I couldn't agree more. I think graphic designers and type designers need to become best friends. Together both groups can go much further as allies than as adversaries.

Gus, we also allow for general pdf embedding, even if it's not strictly workflow related. We only ask the client for a special license in case the pdf (or similar) is sold as a commercial product.

James, thanks for saying so. Designers need a licensing model that puts the font control (and the font licensing) in the hands of the brands and the designers/agencies who are creating and managing the brands. I'll say more when I can come up for air... Back to pitch land.

Sii is correct...using the term 'secure' in the EULA is only going to add confusion.

If it's on a web page viewable on my machine then I already have the files on my machine in some digital form already.

As much as I'd like to see a license that merely stated 'you can use this in digital file' or 'you can't use this in digital files', unfortunately, it seems like we need to create a matrix to fully compare all these options:

- PDF
- Cufon
- @font-face
- Flash
- others? (Silverlight? SVG? Etc...)

And then those that refer to 'secure' of any of the above would need a superscripted reference with small print defining what they actually mean by the term.

Another layer of potential complexity for web use: documents or applications? At Ascender Corp. we consider this an important distinction. We have licensed our fonts to a wide variety of websites for use with web-based applications. In these apps the fonts reside on the server but are not downloaded to the client. In the case of @font-face (web fonts), Cufon, Flash, Silverlight, etc. the font files are downloaded to the client as part of the document (albeit temporarily in most cases). So my point here is that web-based applications should also be added to Tiffany's new chart :)

"In these apps the fonts reside on the server but are not downloaded to the client"

So they are images? Just outlines?

"So my point here is that web-based applications should also be added"

True, but that's another vague term like 'secure'. I can make a web application that uses sIFR, for instance.

If we're still having a go at this thread, I'll mention Process Type Foundry. I licensed Bryant from them and asked if I could embed it with sIFR. Their answer:

"If you are to follow the advice that Andy linked to about protecting the files/font, then you should be within the bounds of our EULA and we would have no issue with that usage." Link

The advice they were referring to is this.

Tiffany, we'll discuss this today at the Typophile meeting. It may be possible to write a table into a Wiki page for the community to edit.

Any embedding permissions chart will be pretty massive... a few of the potential options just for PDF...

PDF Embedding
- Basics
-- No PDF embedding allowed
-- Print & preview only
-- Editable okay (forms)
-- Must subset
-- Must encrypt
-- Must password protect
- Distribution of PDF including the fonts
-- Workflow only distribtion (to service providers like printers, proofreaders)
-- Limited organizational distribution (within organizations)
-- Limited geographical distribution (within a specific worksite)
-- Extended distribution (eg. distribution via email)
-- Unlimited distribution (ie posted to Web)
-- Commercial distribution (ebooks)

For each of these the answer for any given vendor will be yes/no/requires extended license

As far as I understand, this is the base differences between the different methods of using fonts on the web (besides PDF)

Providing some protection against download is the big advantage of flash (and probably silverlight) implementations of fonts for web usage. Cufon re-encodes the file and *can* secure it to a domain, but enterprising folk could reverse engineer it to get the font back much easier than they could with flash. fLIR or facelift, uses PHP to create an image with the font in it, but that font has to exist somewhere on the server and could also be reverse-engineered. @font-face, in its current form, provides little to no protection.

Another layer of potential complexity for web use: documents or applications? At Ascender Corp. we consider this an important distinction. We have licensed our fonts to a wide variety of websites for use with web-based applications. In these apps the fonts reside on the server but are not downloaded to the client. In the case of @font-face (web fonts), Cufon, Flash, Silverlight, etc. the font files are downloaded to the client as part of the document (albeit temporarily in most cases). So my point here is that web-based applications should also be added to Tiffany’s new chart :)

@billdavis > I don't really understand what you mean here. When you access anything on the web, it is temporarily downloaded to your computer and the browser renders it (resulting in the happy IE issues). Can you provide an example of where font files are on the server and not downloaded?

>When you access anything on the web, it is temporarily downloaded to your computer and the browser renders it (resulting in the happy IE issues). Can you provide an example of where font files are on the server and not downloaded?

Font foundry "type tester" applications would be one area most of us are familiar with, another might be Google maps - text is rendered on the server and the resulting bitmap is sent to the browser.

Ralf: Would you have any objections to using your current list as a starting point for a Typophile Wiki page? If so, it would be ideal if you authored it (not to create more work for you) :)

It's probably not a good idea to maintain two separate lists, though if you want to use the content of the webfonts.info page, it is all licensed under Creative Commons. So a proper attribution of the source would suffice.

I would be happy to help with that, but as far I understand this thread people here are more asking about an EULA matrix of possible web uses. But as Simon already pointed out with his PDF example, every of those technologies has plenty of options and a simple list or matrix would probably not work.

We’re collaborating with a web company on a font-license scheme which will allow fonts to be linked to a website easily and painlessly.

Veronika, can you talk more about that or is it confidential at the moment? Sounds like the first foundry with a "webfonts hosting service" to me.

> Font foundry “type tester” applications would be one area most of us are familiar with, another might be Google maps - text is rendered on the server and the resulting bitmap is sent to the browser.

Ah, that makes sense. I guess that is similar to how the faceList software works — creating an image based on a font file.

Cindy Li:
I wanted to use the lovely font created by House Industries but I looked into their llicensing and the font I found cost: $140 from House Industries, unfortunately to use it on my site its going to cost me an additional $1500 because their licensing doesn’t allow embeding.

http://cindyli.com/site/comments/font_embedding_and_licensing/

Adobe's license allows Flash/sIFR embedding, as I understand it.

sIRF is a secure font embedding tool.

Assuming you mean sIFR, I would not say it is "secure." It uses Flash, which has a public spec, and the files are accessible, so... the fonts could be pulled out of the SWF files. I would however say that sIFR and Flash are "about as secure as PDF." Which may be good enough for most font vendors.

T

House Industries does allow web embedding, but only with an extended license. The published price is $1500 for one font and $7500 for a collection. However, they stress that you call and let them know what you're doing to get specific pricing.

This could be a trend until foundries are comfortable with a flat fee for all. Most foundries appreciate phone calls and you'd be surprised at the benefits of having a good relationship with any of them.

>Most foundries to appreciate phone calls and you’d be surprised at the benefits of having a good relationship with any of them.

Almost anything short of posting the font to the web in raw form can be negotiated, if the price is right.

If money is no object, or you're willing to take ethically dubious short-cuts, then "custom" will be the alternative if you want to raw link.

Joe: for the lazy people like me coming to this late, can you update your initial post with the list, you know, so there actually is a list in here somewhere? Thx.

I have updated the license for Downturn to allow embedding via dynamic Flash text, sIFR, Cufón, Typeface.js, and direct linking to EOT or OT files. Now I just need to design something someone might actually want to use on the web and release it under the same license…

Can we see the EULA? How do you deal with the issue of the font being linked to, but prohibit other forms of loose redistribution eg dafont etc.,

Si: Almost anything short of posting the font to the web in raw form can be negotiated, if the price is right.

Heck, if the price is right, posting the font to the web in raw form would be fine too. Hence my position on all this: I care less about the format and the security model per se than about the viability of the associated business model. Which is why most discussion on web fonts seems to me to come from the wrong end: it's looking for a magical technical solution that will satisfy current business models, rather than asking what kind of business models will be possible with the technical developments before us.

And 'the ugliness of the Web' is pretty insignificant aspect of what we're looking at, which is font linking and embedding in live electronic documents, online applications, cloud computing, etc. I suspect that foundries, taking an ad hoc approach to online technologies -- PDF? Okay. Flash? Okay. sIFR? Okay. -- are going to find it harder and harder to establish grounds on which to say 'Not okay!' to future developments.

@sii: Here’s a link to the EULA.

I have updated the license for Downturn to allow embedding via dynamic Flash text, sIFR, Cufón, Typeface.js, and direct linking to EOT or OT files.

Nice! But what do you charge for the additional license?

Nice! But what do you charge for the additional license?

The same price as any other license. My plan to offer single-server embedding licenses at a low price ran into a wall: MyFonts system just isn’t designed for those licensing options. I was going to set up my own web store to handle the sales, but than I ran into a wall of incorporation and sales tax laws. I’m not making enough money to justify hiring a lawyer and an accountant and setting up a new online store, so I decided to rewrite the workstation license to allow web embedding.

Might want to define "user" in a way that doesn't count Web site visitors.

Good point.

Randy, to my chagrin, the list is yet to emerge. What has emerged is lots of discussion of why that list is a pain to create. Lots of whine, no cheese.

Stuff like @font-face won't work unless foundries let go of some fears.

Permit me to give you guys a gentle ribbing. Right now font licensing so complex that licensors can't just focus on the right typographic solution, they have to navigate cumbersome EULAs and nuanced embedding permissions. (Foundry A has these flavors, Foundry B has these other flavors.)

Consider how the iTunes music store made it easier to buy license music than to download it illicitly. Seriously. Win, win. Yes, music is still downloaded and shared illicitly, but the default is that it's just easier to buy it. This is an analogy, and not a perfect one, but I think it has merit. Companies that make it easy (and have quality type) will win -- that's why I was motivated to start the list.

The complexity is the foundries' problem to solve, not your customers'.

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.

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

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

:-)

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

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!

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

ChrisL

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.

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

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?

@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

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.

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?

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.

Joe>The web ≠ The browser

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

Cheers!

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

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?

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!

@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?

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.

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.

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!

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.

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.

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.

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

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.

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!

"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. ;)

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. :)

> 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!

"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!

“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.

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.

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!]

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

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.

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

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.

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

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.

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)