David Berlow on A List Apart on Webfonts

[dezcom]

"@bowerbird: Please format your submissions to ..."

I thought I was the only one who wanted to puke from over-scrolling when I saw those tiny line lengths. Is this a control issue thing? Please step away from the return key and just let the lines wrap on their own.

ChrisL

[Randy]

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

[Thomas Phinney]

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.

Cheers,

T

[Dan Gayle]

@Randy
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.

[aluminum]

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?

[Dan Gayle]

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

Win-Win.

[bowerbird]

randy-

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

***

thomas said:
> 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...

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.

-bowerbird

[aluminum]

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.

[Dan Gayle]

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.

[Randy]

I'm curious what people on the foundry side think of the hosted font idea?

[aluminum]

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

[Ralf H.]

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:
http://opentype.info/blog/2008/04/19/font-face-survey-results/

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.

[Vlad Levantovsky]

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.

Cheers,
Vlad

[bowerbird]

ralf-

sounds like you got it figured out! best of luck with it!

-bowerbird

[Vlad Levantovsky]

I wrote:
> 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.

dberlow wrote:
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,
Vlad

[Vlad Levantovsky]

@Ralf Herrmann

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)

Thank you,
Vlad

[dberlowgone]

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.

Cheers!

[Ralf H.]

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.

[Vlad Levantovsky]

@dberlow

David,
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.

Regards,
Vlad

[aluminum]

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?

[Dunwich Type]

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.

[Nick Shinn]

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.

[aluminum]

Nick...you know what he's saying? If so, please explain! ;o)

[Nick Shinn]

I know what it means, but …

[JohnM]

I`m just waiting for free google webfonts.

If they have interest in hosting the javascript I use, I guess they will have interest in free hosted google webfonts too...