New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
Real Fonts on the Web: An Interview with The Font Bureau's David Berlow
by DAVID BERLOW, JEFFREY ZELDMAN
Coming in from left field here...
I wonder if it would be possible for type vendors to host the font files on their own server, and then license links to the files as a web extension, or web-only license? Seems like this keeps the permissions/access separate from the font files. I'm envisioning a per-domain license, where once a user buys a license, they can login and manage their domains as needed.
Obviously this doesn't fix the problem of people with print licenses from posting the files, but it does offer a relatively painless way for web designers who want to be legal to license. I'm envisioning this kind of license would be cheaper as you could only use it for one client. Maybe someone can turn this into a good idea. Or maybe it's a stinker from the get go :-)
Vlad wrote: but EOT also employs lossless font-specific compression (MicroType Express (MTX), developed by Monotype) that, on average, is 30% better that zip.
I believe that's comparing Zip *without subsetting* to MTX. If you assume subsetting first, the difference drops to 10%, IIRC. Also, MTX does next to nothing for OpenType CFF, as it's already compacted, right?
Bowerbird or anybody else new to the discussion: Yes, there is plenty of demand from both web designers and organizations/people with web sites. There's also plenty of evidence that even minor barriers to piracy will stop most users from pirating. We know that some people are going to pirate regardless, and putting even strong DRM on web versions of fonts won't stop that... meaning there's no point to strong DRM on web fonts. But most piracy can be deterred by "DRM Extra Lite," so that's all that's really needed.
I don't understand why they aren't already doing that. I mean, my company already does that with photos. As long as OUR site calls the image, it gets displayed fine. If you're someone trying to "hotlink" the image, then our server automatically switches the output to whatever we want. I wanted to switch it to something awesome, like a Rick Roll or something, but we instead pointed it at an ad.
Now imagine the same scenario for fonts. It's the exact same principle. When someone tries to hotlink your font un-authorized, we simply replace it with "the font", i.e., Papyrus or something.
That would be totally sweet.
Randy...that would be the best from the foundry protecting-its-files standpoint, but if we're talking a site like Amazon or Wikipedia or the like, they'd quickly be killed with giant hosting bills. ;0)
"There’s also plenty of evidence that even minor barriers to piracy will stop most users from pirating"
Really? Such as? (I'm curious)
I agree that 'extra lite' is the key but really haven't found such a thing yet. Usually, extra lite means 'easy to circumvent anyways'.
I envision 3 kind of font users:
1) people that just want fonts and will do whatever to get them for free
2) designers who understand the value of fonts and will pay for them
3) designers who understand the value of fonts and will pay for them up to the point where things get sticky with complex EULAs pertaining to using it for this vs. that vs. pdf vs. flash vs. web who then may or may not bother with even reading the EULA and either not buy the font, or use it outside of the EULA.
Nothing can be done about #1.
Nothing had to be done about #2.
So that leaves #3. Seems that ideally, for that person, the foundries would just try to make it really easy to implement a solution for online fonts.
I could be missing a form of user, though. Others?
>>a site like Amazon or Wikipedia or the like, they’d quickly be killed with giant hosting bills.
Then the foundries pony up for an Amazon S3 content distribution system that allows the same controls over who gets to actually access the end product.
An added benefit of that is then the fonts will load faster, since they're being hosted in the cloud rather than on whatever dinky server the foundry is hosting their own site on.
i'm right here in left field with you,
wondering the same thing, so thanks
for asking the question. i assume there
might be some problems with _latency_,
but that wouldn't be a killer per se, as it
could be solved with enough resources...
> Bowerbird or anybody else new to the discussion:
> Yes, there is plenty of demand from both web
> designers and organizations/people with web sites.
so go make yourself some happy customers.
that's all i'm saying...
> There’s also plenty of evidence that even minor
> barriers to piracy will stop most users from pirating.
all the more reason to make yourself some customers.
you gotta expect zero individuals will bother paying,
and write off any "piracy" they do as "good publicity".
use it as a selling point: "people love our fonts, see?"
at the same time, very few _businesses_ would pirate,
even without d.r.m. of any sort, simply because such
an action would be dirt-simple to detect, and therefore
expose them to an obvious, direct, and immediate risk.
> We know that some people are going to pirate regardless,
and still more reason to make yourself some customers.
> putting even strong DRM on web versions of fonts won’t stop that...
it's so good to hear people say things that resonate to the real world.
> meaning there’s no point to strong DRM on web fonts.
> But most piracy can be deterred by “DRM Extra Lite,”
> so that’s all that’s really needed.
thomas, you were doing _so_ well, right up to this last little bit...
this idea that "a little d.r.m." will "do the trick" is so pervasive
that it almost becomes persuasive, which is ludicrous because
it's so wrong wrong wrong. d.r.m. is impossible, and it's just as
impossible to do "d.r.m. extra lite" as it is to do any d.r.m. at all.
but somehow our minds fall for the trick that "a little d.r.m."
should be easy to accomplish, and -- since it would do _so_
much good, by keeping "honest people honest" -- that it's
a good path to pursue on a cost-benefit basis. but it's not...
because, just like a "little" d.r.m. is _impossible_ to accomplish,
it's also the case that a "little" d.r.m. doesn't do much deterring.
it ends up that a flimsy lock is usually worse than no lock at all.
because anyone with any intention of breaking the lock will carry
a hammer big enough to smash it. so the only people who get
"locked out" are the people who never carry around a hammer,
that is, the "honest" people, who you also know as "customers".
and so, too, it is with "d.r.m. extra lite". the _only_ people who
are adversely effected by it are customers, present and future...
and those adverse effects often occur when your d.r.m. backfires;
it's _your_ fault it acts inappropriately, but your customer suffers.
not only that, but the lock is a symbolic indicator to the customer
that you do not _trust_ them, and this rankles an honest person...
ends up honest people don't need anything to "keep" them honest.
they just _are_. the most you might need is a nice polite request...
if i were you guys, i would do this.
i would go to the browser people, and say "we want you guys to
use our fonts, so tell us how we can make it easy for you to do."
and then do what they say. let them know that you are looking
to get paid, maybe relative to how often your fonts are used, and
work it out with them to make it happen to everyone's satisfaction,
and forget all this stuff about permission tables and d.r.m. stuff...
nobody needs it. it doesn't deliver any benefits. it just adds costs.
otherwise, you're gonna spend a whole lot of time and energy to
build a cash-register, but no one is gonna walk into your store...
in a phrase: forget piracy and maximize sales instead.
dan: the problem is that someone has to pay for that hosting. How would that work? I suppose you could charge it as a hosted service, but at that point, I can see a lot of web designers/clients just saying 'meh...use verdana with a bit of sIFR' and forget about it.
Not trying to kill the idea...merely pointing out that hosting costs can sneak up on you.
S3 is actually quite affordable. Much more so than trying to afford the servers and the bandwidth yourself. http://aws.amazon.com/s3/#pricing
“Pay only for what you use. There is no minimum fee.”
Sounds reasonable to me. The foundry has the agreement with Amazon, sets up the domain/font access permissions, and includes the hosting fee as a minimal addition to the cost of licensing the font.
If you did it right, you could even structure the contract price based on time. Only want it for a year? $15. Indefinite? $50. You could call it Rent-a-font.
I'm curious what people on the foundry side think of the hosted font idea?
"includes the hosting fee as a minimal addition to the cost of licensing the font"
Yea, that's where I see the plan not working so well. I like the idea, though.
I wonder if it would be possible for type vendors to host the font files on their own server, and then license links to the files as a web extension, or web-only license?
I am proposing this idea for some time now. See my webfonts survey and my comments:
Such a service is not hard to set up. I will do it myself if I would ever find the time.
Still, I would consider this a promising market, but an additional market. The majority of today's users still want a regular way of licensing, which means: Pay once and get the font files (to be uploaded on their own server). And we cannot change this system just because of our security issues.
We also experimented with ways how OT/TT files could be manipulated so they will work in the browser, but not in the user's OS. There are several ways to achieve this. So this DRM-lite is already possible. If there will be a standard way of doing it in the future, that's fine with me. But we will not wait for this to happen and start selling webfonts rather sooner than later, probably later this year, when Firefox 3.5 will have @font-face support in their regular version.
Some people seem to doubt that "users" would pay for webfonts at all. But professional webfonts are probably not for private users with a MySpace page (they have plenty of Dafont and open source fonts to choose from). Professional webfonts are licensed through professional design studies. Especially for webdesign studios it is very common to license software for a project, for example a Content Management System or an E-Commerce solution, or even just a tiny plugin for those systems. Those packages usually come with a per-domain license. The design studio will purchase that license and bill it to the client. Those packages are not protected in any way, but if a second client wants that same system the studio would license it again for this new website. So such a procedure is nothing new and licensing webfonts in this way would be no problem.
Thomas Phinney wrote:
I believe that’s comparing Zip *without subsetting* to MTX. If you assume subsetting first, the difference drops to 10%, IIRC. Also, MTX does next to nothing for OpenType CFF, as it’s already compacted, right?
I am comparing ZIP to MTX on the same input data set, without subsetting. For example, Verdana.ttf is 137KB, compressed by ZIP is 81KB, and 58KB when compressed by MTX. ZIP file size is 39.6% larger than MTX. The relative compression gain remains the same if you subset the font. However, if as a result of subsetting the font file size becomes really small, the compression efficiency will go down for both ZIP and MTX, and because MTX is most efficient when compressing glyf table data you will see less of a difference between ZIP and MTX when the glyf table size is small.
I agree, MTX will do nothing to compress CFF table (it's already compressed) but it will reduce the size of other tables in a font, and it will also obfuscate the OpenType CFF font so that it cannot be used on a desktop directly.
sounds like you got it figured out! best of luck with it!
> What type designers and font vendors want is that
> web fonts can not be easily copied from the web
> (or browser cache) into OS font folder and re-used
> in other applications.
Not I, that is so far gone since 1990 I can’t imagine going back. Any user anywhere can get any font they want and install it. They have not to wait for the web.
I am sorry, I am not sure I understand what you are referring to. Are you saying that any user today can get any font they want for free, without license? I don't believe this is the case.
> Adding a bit that is ignored by all existing OSes
> and applications would do nothing to stop this.
Yes, but adding a bit that is not ignored by everything is out of the question.
Agree, but I am not sure I understand how this is relevant.
So, the world has given us this choice. Even if your miracle MTX format doesn’t allow users actual fonts, it’ll be hacked.
Yes, and I believe I attempted to make it very clear in my post. No encryption or DRM will ever stop a person who is determined to rip a font. However, obfuscating font data so that it can't be used without hacking will stop people from "discovering" fully functional raw font files on their hard drives. And, since I believe that serving uncompressed font data (any data, in fact) is a waste of bandwidth, MTX is the most efficient font compression that can also be an effective obfuscation tool.
Then, you’ll have a hacked font with no permissions to start and certainly none in the end.
So the permissions tables come first, any format you want to which the permissions grant conversion, then is okay.
I am trying really hard to understand what the permission table will do and whether a browser or an OS would be responsible for processing that data. How do you expect browser vendors to agree to implement and support it? So far, they've been very reluctant to support even embedding bits.
I would really appreciate more info on your proposed permission table functionality.
Thank you for conducting the survey and sharing the results. I find it very interesting but it also raises some questions:
1) If a web font is hosted on font vendor website and is offered based on pay-per-use or subscription-fee model - what would be your web hosting costs if your clients get many millions of hits per year?
2) Has any of your survey participants ever raised concerns about privacy? Technically, hosting a web font would allow you to track the number of hits for different client websites. Is this an issue (I assume it can be)?
3) What will be a font vendor liability if, for whatever reason, a font can not be served to a client website visitor, and the content layout is broken as a result?
(These are just a few that I can think of right now)
ME> Yes, but adding a bit that is not ignored by everything is out of the question.
VLAD> Agree, but I am not sure I understand how this is relevant.
I see... adding a table that only deals with the legal rights of the font, as I propose, is irrelevant?
Obfuscating font data, then revising all browsers and OSs to use it, as you propose, is a good idea?
Me (from before my previous post) >The linking to PermitTabled OT fonts (or any font) is I think, strictly between the linker and the owner.
>I am trying really hard to understand what the permission table will do and whether a browser or an OS would be responsible for processing that data.
>How do you expect browser vendors to agree to implement and support it?
>I would really appreciate more info on your proposed permission table functionality.
To say exactly what the founder said to say, sit in the font and stay the same. That's all that's 'demanded' from my side. No browser or an OS would be responsible for processing that data.
VLAD> Are you saying that any user today can get any font they want for free, without license? I don’t believe this is the case.
Do you live in prison or something? ;) Oh, sorry, no prisoners can get all the fonts they want for free too. Ummm, do you live on earth?
Randy>I wonder if it would be possible for type vendors to host the font files on their own server, and then license links to the files as a web extension, or web-only license?
That's the plan, but, we want to be licensing something distinctly different from the print font. The permissions tabled font is the beginning of fonts distinctly different from the print font. And... without a distinction that forces apps to rev. but with a legal distinction.
Thank you, this has been a good conversation.
what would be your web hosting costs if your clients get many millions of hits per year?
The license costs would depend on the number of hits, just as any webhosting provider might charge you more when your traffic exceeds a certain limit.
Technically, hosting a web font would allow you to track the number of hits for different client websites. Is this an issue (I assume it can be)?
Good point. The webfont service provider would have to ensure that those data is not misused. But again: We're not inventing something new here. Including external services is common practise in webdesign (e.g. page counters, news applets, feed services and so on.)
3) What will be a font vendor liability if, for whatever reason, a font can not be served to a client website visitor, and the content layout is broken as a result?
I don't think that's an issue nowadays. The service should be based on a reliable server (Amazon S3, Google App Engine et cetera) and the website layout cannot be "broken", since fallback fonts will always be around, because users will always have the chance do deactivate font-embedding on the client side.
I am trying really hard to understand your proposal. So far, I see that you propose a permission table be added to a font, and that this font can be served on the web if:
- web use is permitted by the font license (and this permission is reflected in the permission table), and
- your licensee can then link the raw font to his web content.
Am I right?
What I don't see is how this information will protect the font from being misused. What if million of copies of the font end up being installed on the machines that were used to access the website you licensed it to? How the permission table will prevent this? How will it protect your copyright owner rights if no application will ever be able to access the information in the permission table? And how is the permission table different from just encoding a link to the text of the EULA where all the rights granted by the license are spelled out in details (something that has been done for years)?
David, you and I are in the same boat here, its not about my proposal vs your proposal. I am trying to find a way to enable web fonts and to protect font IP at the same time. It's not just about our IP, it is also about all those type designers who trust us to license their fonts and to pay them royalty for every copy of their fonts being distributed and to protect their IP rights.
Is it just me or are dberlow's replies completely unhelpful in actually understanding what he's talking about? I'm honestly trying to understand your table idea, dberlow. Feel free to call me names. Use sarcasm as much as you want. But please do try to explain it to me!
You say nothing is going to be changed at the browser level. If that's the case, what does this permission table actually do? As it is now, there's no need/concept of a permission table at the browser level, so how would adding this table change anything? Is it merely a table for foundries to ping as some sort of licensing log?
Is it just me or are dberlow’s replies completely unhelpful in actually understanding what he’s talking about?
It’s not just you. Dave’s posts on this topic are one step away from bonkers. Whatever his plan is, I think it’s safe to say that he’s not really interested in what anyone else does.
I support what David is suggesting 100%.
I think it's safe to say that whatever is good for Font Bureau will be good for other independent foundries, and feasible for the industry as a whole.
Nick...you know what he's saying? If so, please explain! ;o)
I know what it means, but …
I`m just waiting for free google webfonts.
"Wrong, wrong, wrong"? Next time you go off on a rant, have some evidence.
The type industry already have over a decade's worth of evidence that "DRM Extra Lite" can work reasonably well, in the form of embedding bits for print usage. Some vendors don't allow such embedding, or allow it for view and print but not editable embedding. They set their fonts appropriately. Most users who run into restrictions due to the embedding bit settings don't hack their fonts to get around this, they just accept it. Would it be easy to hack the fonts? Sure. Do a large percentage of people do it? No. If they don't like the restrictions, they learn from the experience, and maybe they license different fonts.
So, you're saying a nearly identical mechanism wouldn't work for the web, because...?
Re: hosted webfonts and bandwidth insanity
Seems this is the biggest question: What happens when the hits go nuts and bandwidth skyrockets??
Seems like the foundry could offer a basic web license that would guarantee a certain amount of bandwidth (impressions) that would be adequate for 95% of websites. When you get to people like Amazon or Wikipedia, or any site really where bandwidth would be crushing, this is a different kind of client entirely. They have already solved their bandwidth issues. License them to use the fonts on their own servers for a higher fee.
Somebody starts a company that services the foundries and builds a robust enough back end to handle it. We're talking small font files not video. The load wouldn't be THAT crazy.
Thomas, the PDF embedding bits serve a different purpose than web fonts and are deployed differently. Not many fonts disallow embedding, and while many disallow embedding into editable documents, I don’t get the impression that many people are creating editable PDFs using fonts other than common system fonts. I don’t see a big desire on the part of users to get their hands on collections of fonts that allow PDF embedding. Given this I don’t think that the example of PDF embedding bits is an accurate analogy to how users might react to permission bits in fonts.
A better analogy might be the DRM-extra-light system that Adobe uses to protect its software from piracy. Just a simple serial number and a registration system that phones home for some products. Any before any Adobe product makes it to retail, thousands of people are already using cracked copies and monitoring every outgoing nework port on their machine for attempts to contact Adobe. Because unlike PDF with editable content, people are actually interested in getting Adobe software for free.
I think that there are many, many more people who want to embed fonts in web pages than in editable PDFs. And I think that there would be quite a demand for cracking tools and cracked, just as there is for DVDs or software keys. But I also believe that, as with software, most of the demand for pirate fonts comes from people who would not buy the fonts anyway, and they probably aren’t really worth worrying about.
> Next time you go off on a rant, have some evidence.
it wasn't a "rant". there was no emotion in it at all from this end.
if you injected some in at that end, that's something that you did.
i'm just entertaining myself, talking with y'all... :+)
you say you've got "d.r.m. extra lite", and that it's working just fine,
and the "evidence" you cite is that honest people are acting honestly.
ok, i must be wrong.
d.r.m. "extra light" must be workable, and you've got it working fine,
and it's protecting you, as good as it can, from the dishonest people.
so it sounds like all the problems are solved.
(in other words, if you tell me you've got a frog in your pocket, and
you're willing to bet me money that you've got a frog in your pocket,
i'd be a fool to bet that you _don't_ have a frog in your pocket, right?)
which means we'll be seeing webfonts in use any day now, correct?
i look forward to that day, very soon, and i don't want to miss it, so
could you please have your people call my people when it happens?
thanks a bunch.
you see, i _do_ want you to correct me when i'm wrong. after all,
at the end of the day, that's what i'm here for, to learn from you...
p.s. and maybe now that you guys have some time free, you could
do something about that global warming thing al gore talks about?
It's true that there are a minority of fonts out there which completely disallow PDF embedding, but there are some, and mostly people don't mess with their embedding bits. Working for Adobe from 1997-2008 I learned a wee bit about how users work with these fonts.
# some text, where "some text" is the title of existing content or the title of a new piece of content to create. You can also link text to a different title by using show this text. Link to outside URLs with some text, or even http://www.example.com.
# Allowed HTML tags:
# Lines and paragraphs break automatically.
# Web page addresses and e-mail addresses turn into links a
Talking about this is like dancing about architecture.
i'm gonna turn off the italics with a tag right here,
and then turn off the bold with a tag right here,
so the rest of this thread can walk erect, yet without hubris.
And after all this time you all can't tell when Mr Berlow is having a wank. Astonishing!
Here's a link talking about hosting your fonts:
James de Clairavista: "Astonishing!"
Wow, sorry I missed this one.
James I have not played doctor for while now, but here's some help for ya: place your left hand on your right shoulder. Feel down to the first big bump — this is your elbow. The next part's a little difficult because you can't see your own, but ya if look way, way up the flagpole of understanding you can seen the other part, it's mine though, and hopefully one day you'll understand the difference.
Cheers to you David! This whole thread has been a joy to read and re-read. Such enlightenment, you must be very proud.
Another interesting discussion killed via cryptic sarcasm.
>Another interesting discussion killed via cryptic sarcasm.
Not Exactly. I'm very busy.
Besides, there is a building code here in the Commonwealth of Massachusetts that goes like this: when one builds a room for living space, there must be a light switch near the door and a light fixture in the room, so people don't have to walk into a dark room.
There is however, no code, no law and no bylaw that says that there has to be a light bulb in that fixture.