Web fonts - foundries allowing sIFR, FLIR, cufón, @font-face, etc.

Hi,

is anywhere a table showing which foundry supports and allows which webfont technology? I couldn't really find anything close to what I mean, so I put together quickly this draft: http://en.wikipedia.org/wiki/User:Pepa007/Foundries_allowing_web_fonts

Is there something like this already? Or should I publish it and kindly ask you to help me with adding more foundries?

Thank you

Josef

josefrichter's picture

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

Richard Fink's picture

@josefrichter

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

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

I, for one, appreciate your efforts, though.

rich

josefrichter's picture

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

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

apankrat's picture

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

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

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

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

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

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

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

--

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

--

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

Si_Daniels's picture

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

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

blank's picture

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

apankrat's picture

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

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

Si_Daniels's picture

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

apankrat's picture

Sorry, I don't follow.

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

Ray Larabie's picture

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

ralf h.'s picture

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

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

ralf h.'s picture

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

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

Richard Fink's picture

RE: FLIR

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

That it?

blank's picture

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

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

apankrat's picture

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

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

blank's picture

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

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

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

Because they are my fonts any I want more money.

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

apankrat's picture

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

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

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

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

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

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

blank's picture

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

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

blank's picture

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

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

apankrat's picture

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

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

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

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

--

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

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

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

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

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

Ray Larabie's picture

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

apankrat's picture

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

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

Ray Larabie's picture

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

josefrichter's picture

Hi everyone,

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

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

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

Thanks everyone

Josef Richter

Thomas Phinney's picture

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

Not that I'm a lawyer, of course.

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

Cheers,

T

Ray Larabie's picture

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

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

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

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

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

Richard Fink's picture

The Nancy Reagan approach.

aluminum's picture

Nancy Reagan didn't solve anything with words.

And her husband did little with the military industrial complex.

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

We'll find a middle ground sooner or later.

Ray Larabie's picture

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

hoefler's picture

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

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

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

aluminum's picture

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

Jackson's picture

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

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

apankrat's picture

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

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

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

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

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

Richard Fink's picture

@typodermic

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

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

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

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

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

rich

Ray Larabie's picture

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

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

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

ralf h.'s picture

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

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

Thomas Phinney's picture

How's WOFF for security?

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

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

Regards,

T

Ray Larabie's picture

Cufon is just an awkward JavaScript hack.

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

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

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

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

capthaddock's picture

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

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

Jackson's picture

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

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

Ray Larabie's picture

. . . and strip the OT features.

Richard Fink's picture

@typodermic

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

Some thoughts:

But the remote rendering aspect of FLIR concerns me.

On FLIR:

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

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

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

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

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

rich

apankrat's picture

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

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

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

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

rob keller's picture

Just a couple quick notes:

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

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

Cheers,
Rob

Ray Larabie's picture

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

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

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

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

corymawhorter's picture

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

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

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

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

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

===

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

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

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

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

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

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

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

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

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

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

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

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

Si_Daniels's picture

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

aluminum's picture

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

Aren't the web designers 'the market'?

Si_Daniels's picture

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

Syndicate content Syndicate content