I still fail to see what how a permissions table accomplishes anything in regard to protecting web fonts from misuse. What is the point if someone will just publish a tool to alter the permissions table at will?

@James
It might prevent the widespread use of non-licensed fonts on the web for 95% of the people. The other 5% are scumbags anyways, who have probably stolen the font to begin with, along with the stolen font-editing software.

I love how the "We have a standard that is now supported in Firefox and Safari…" question was either a) completely mis-interpreted or b) completely ignored.

Zeldman was obviously speaking of the "new" @font-face, but Berlow responded with attacks on the Zen Garden. Shame on you David!

It might prevent the widespread use of non-licensed fonts on the web for 95% of the people.

Exactly how does it do that? Is the assumption that 95% of people who would want to use fonts without a proper license are too lazy/stupid/technically inept to download a tool that alters the permissions as needed? It seems to me that if people are willing and able to crack dongled software and use registration key generators they’ll have to trouble tweaking a font.

James, I think David's concept is that web crawlers or spiders can be used to find fonts put on a server, when the site owner hasn't bought a license. They could be easily caught if they change just the permissions table, but not the name.

If they changed both the table and name it would be harder to do automatically, but people might report them if it's public, and also there's the 'what the font' matching software stuff.

Being a crook and using the web is a very risky undertaking for the crook, as it seems the new "Dr. Jeckle and Mr. Hyde" in Boston has just found out.

The main thing is that if you put it on the web, it's very public, and so a big risk if there is serious enforcement. Of course, with countries that allow crookedness on the internet, you aren't going to be able to get at them. But other places you will.

@James
You think that 95% of the people designing web sites are all willing to crack software? There is a large difference between someone downloading softwares and someone who has to go out of their way to intentionally find a way to crack open said softwares. I assume.

The moral barrier between using something that you think is free and something you know darn well isn't free, I think, is enough to dissuade a good majority of the people.

Some industries still believe copyright protection can be handled via technology. Some industries have gotten over that. I'm guessing it's a natural cycle of every industry as it tries to embrace the web.

"The moral barrier between using something that you think is free and something you know darn well isn’t free, I think, is enough to dissuade a good majority of the people."

I agree.

William, I don’t believe that enough font vendors are in a position to follow up with lawsuits that it will really matter. And even if one has the financial resources to file the suits, does one have the time?

Dan, I thought you meant it would prevent 95% of piracy, not that 95% of web designers would use cracked software. And I’m not sure that the moral barrier is really an issue. Designers could have been using EOT without licenses for years—most web users have been on IE for a long time. If EULAs have stopped accidental EOT use up to now, why assume it will suddenly change with the shift to @font-face?

James, it only takes one successful lawsuit--and probably not even that is necessary--for a letter from a lawyer to get somebody's attention. If they get a letter saying "Congratulations you are our customer, here's the bill", which is what I heard DB say at at TypeCon is his approach, then they are likely to pay up rather than risk a law suit. And one of the big boys, like MS, Adobe, Apple, may well join in a lawsuit to establish the principle, if there's an issue affecting them at stake, which would be the case here.

The open-source ideologue with a cruel-and-nasty streak, Mark Pilgrim, points out that “your” fonts are better than “[his]” fonts in every way but one.

—
Joe Clark
http://joeclark.org/

Heh heh. Joe, the censor-bot is messing up your link, as it contains the famous f-word.

It is current here.

I'm not clear on whether the permissions table would have to interact with browsers, as Mark Pilgrim says. And if so, how big a deal this is.

Perhaps David Berlow could explain more how his concept is supposed to work.

…it only takes one successful lawsuit—and probably not even that is necessary—for a letter from a lawyer to get somebody’s attention.

The experiences of the RIAA, the MPAA, Microsoft, Nintendo, etc. suggest otherwise. There have been plenty of successful lawsuits, and piracy just keeps on happening. The notion that font DRM and lawsuits will stop piracy is a fantasy. It won’t stop font piracy anymore than sticking pins in a map of Sweden will.

James, this is fundamentally different because the song you have on your computer is not public. The font on a web site is. Maybe it still won't work, I don't know enough to judge, but it is different.

Stephen Coles notes that Tal Leming has weighed in on this. Is his proposal the same as Berlow's?

James, this is fundamentally different because the song you have on your computer is not public. The font on a web site is.

So the big difference between the proposed font situation and the existing situations with other media that it’s easier for font designers to sue a pirate because the infringing font is on a public server? Because a few font vendors claim that they have the time, money, and inclination to try and recover money from pirates via lawyers does not justify the inevitable DMCA (or other law outside the USA) violation lawsuits that arise when a software is released without the DRM system and font vendors decide that it constitutes a circumvention device. It doesn’t justify the resources programmers will waste coding an ineffective DRM system into their work to avoid getting sued. It doesn’t justify the hoops end-users will have to jump through when the DRM fails to work properly.

Font vendors who choose to pursue font DRM do so at their own peril, because in the end it’s just going to end up pissing a lot of people off. That “**** THE FOUNDRIES” post was just a start—think about what will happen when somebody sues a Linux distro that includes DRM-free web browsers and web font creation and editing tools. Font vendors are eventually going to have to realize that the only solution to the problem is accepting that some piracy will always happen and finding ways to exploit it to their advantage.

Tal Leming has weighed in on this. Is his proposal the same as Berlow’s?

It sounds like it, but only Dave can say for sure.

Tal Leming has weighed in on this. Is his proposal the same as Berlow’s?

It sounds like it, but only Dave can say for sure.

Or I can.

No, they are not the same. David is proposing changes for multiple font formats that are much larger in scope than what I'm proposing. My post details slight tweaks to the OpenType specification.

Another thing worth noting is that while fonts are fundamentally different from other media formats, DRM is not. The differences between the proposed simple font DRM systems and the convoluted encryption and watermarking systems used for music are not relevant to DRM’s pernicious impact on the freedoms of programmers. Once a font DRM system is in place, it becomes illegal to circumvent it in some countries. This opens programmers up to civil and/or criminal suits for writing an application that renders text. I’ll admit that nobody is asking for the kind of control that media conglomerates have attempted to emplace. But there are still a few litigious screwballs, not to mention overzealous prosecutors, who could really ruin somebody’s day.

Further, I want to reiterate something that came up when this debate was had on the ATypI list last year. A vendor does not need any kind of font DRM system in place to crawl the web for license violators. As long as a vendor has a list of web domains with a legitimate license, he can still go after anyone using the fonts without a license. If the ability to catch violators is important, that can be had today, using @font-face, sIFR, EOT, Typeface.JS, and Cufón.

I can’t read the type on Tal’s page (though I could read Kaypro, Hyperion, and Victor 9000 screens just fine). I’ll have to load it in Lynx later maybe.

—
Joe Clark
http://joeclark.org/

@Tal: "David is proposing changes for multiple font formats that are much larger in scope than what I’m proposing."

How so? He doesn't go into much detail, but his brief mention of adding a new set of embedding bits doesn't seem "larger in scope" to me. Different, but not larger in scope than adding URLs and scrambling the beginning of the file. Arguably smaller in scope than Sampo's proposal which you are backing.

BTW, Dave B lists four font formats. But two of them aren't font formats at all (FreeType and CoolType), and the distinction between TrueType and OpenType is rather razor-thin. Windows TrueType has evolved into OpenType. I suppose Apple probably maintains their TrueType spec, though.

Dave B also has the wrong target: it would be easy to get something like this added to the OpenType/OFF spec. The difficult hurdle is getting it accepted by the W3C. Sampo's proposal was already rejected by quite a few W3C members.

Then again, maybe the most effective thing to do is to get the info into the font spec(s), and then press the browser makers to respect those specs. Getting them to do *anything* more than raw desktop fonts on web servers on their own has been a lost cause to date.

Cheers,

T

tai, just a few points on your post,
which sounds fairly reasonable...

...except...

> The person can license the font
> to give the designer the respect
> he/she deserves for creating something
> that the person likes and wants to use.

is this about _respect_? or _cash_?
never mind, it's a rhetorical question.

> I think this could be done in a way that
> honors all of the work that we’ve done to
> create the fonts that people want to use.

there's that "want to use" phrase again...

> Say you have a blog and you want to use
> a font from the XYZ foundry for headlines
> on your site. You go to the foundry’s website,
> you enter the domain that your font will be
> used for, you buy a web embedding license
> for a small fee, you download the web font file
> and you put it on your site.

and again, "want to use".

the thing is, people might want a variety of fonts,
but they ain't gonna be willing to _pay_ for them.

they won't necessarily question your "right" to
charge money for fonts, and they certainly won't
argue with you that it might take a lot of time to
create a good font, and they would agree that
you deserve to be compensated for your time...

but -- in the end -- they won't want to pay...
because it's just not that _important_ to them.
they will use whatever free font they have now.
they don't "want to use" your font all that badly.

just like they _want_ the hometown daily paper,
but they don't want it badly enough to subscribe,
not at the price that would keep that newspaper
in the black and laying ink on paper every day...

so even if you win the right-to-charge battle,
you might lose the actually-getting-paid war.

which might mean you shouldn't even bother
to fight that particular battle, but rather instead
engage a different strategy so you win the war...

-bowerbird

Thomas,

@Tal: "David is proposing changes for multiple font formats that are much larger in scope than what I’m proposing."

How so? He doesn’t go into much detail, but his brief mention of adding a new set of embedding bits doesn’t seem "larger in scope" to me. Different, but not larger in scope than adding URLs and scrambling the beginning of the file. Arguably smaller in scope than Sampo’s proposal which you are backing.

From what I understand, David is proposing a new table to be added to the OpenType (and therefore OFF) and TrueType (does anyone even maintain the TTF specification anymore?) specifications. This table would be, and I'm guessing based on his vague statements here, similar to EEULAA. He is proposing that everything should immediately start honoring the bits in this new table.

The only change to the OpenType specification that I'm proposing is a single addition of a bit to fsType in OS/2. That's a backwards compatible change that doesn't require any support from font managers, applications or OSes. The only things that would need to understand this bit would be browsers, theoretical web authoring tools that work with web fonts and, of course, new font editors. Those applications are in the early stages of developing web font support, so this won't require a big change. The second thing my proposal does is to offer support to Sampo's idea for a web specific font format. The differences between this format and the OpenType format (the root table and the first 100 bytes) would not be rolled back into the OpenType specification and this new format would require only changes from applications that are still in the early phases of supporting web fonts.

My point is that the time that it will take to get a new table out of the concept stage and get it approved for inclusion in the OpenType specification will likely be longer than the lifespan of the working group that will decide the direction of web fonts.

bowerbird,

is this about _respect_? or _cash_?
never mind, it’s a rhetorical question.

For me, it is about respect first. It's disheartening when I spend a year designing a typeface and then have someone explicitly or implicitly tell me, "I can do what I want with this and you can't do anything about it!" The "_cash_" part you mentioned only comes up when I need to pay my bills. If you seriously think that anyone becomes a professional type designer in order to get rich, you are quite mistaken.

there’s that "want to use" phrase again...

I'm sorry, but I don't want to engage in a philosophical discussion about conflicting human desires. That's above my pay grade.

Thanks, Tal!

ChrisL

Thanks for your work on this Tal, and explaining it further here.

I don't know what solution is good, but I do know that the current situation of producers not getting paid is not sustainable. We are seeing it now dramatically and writ large in the case of newspapers collapsing, and online news places not being able to pay reporters as print media did. Something in the way the web operates has to change, and in a direction that rewards producers.

W3C ignoring the needs of font designers reminds me of Hillary Clinton excluding the doctors from discussions of what the future health system should be.

Hmmm. Maybe we need a "Harry and Louise" video :)

That whole thread with it's comments makes me really not like certain aspects of the FOSS community. The vitriol should be bottled up and sold as anti-fungal medicine.

I like what Tal is saying, but I don't think it really resolves the bigger issues. As stated, it really doesn't make it difficult to circumvent and, as such, doesn't really do much to actually protect the type designer via any technical method (which is par for the course in the world of DRM).

I appreciate the want of the type industry to somehow manage how fonts are used on web sites. I don't have a solution, though. And I don't think DRM will ultimately be a solution either.

It seems that the issue can be distilled down to the following:

Type designers...
- don't want people freely copying their fonts
- (some) would like additional $$$ for use on web sites (and PDFs)

Web designers...
- would like to use fonts they purchase online just as they do on paper
- don't want to deal with another layer of technology to get it to work (DRM)

Ultimately I don't think there is a solution that will appease all of the above bullet points. So, there'll likely be some EULAs that favor the web designer and some that favor the type designer and we'll have to see where things end up in a few years.

I don’t know what solution is good, but I do know that the current situation of producers not getting paid is not sustainable.

You’re correct, but that’s not the issue at hand. This isn’t about giving fonts away, it’s about selling fonts. Font designers need to focus on selling fonts to the thousands of web designers who want to buy them instead of worry so much about the people who will steal the fonts. Yes its offensive that after months or years of work on a typeface people will pirate it without thinking about it. But intellectual piracy is a force of nature. Waiting for someone to find a way to stop that is like sailors sitting in port all day waiting for the open ocean to calm.

W3C ignoring the needs of font designers…

I really don’t think that’s the case. The W3C has heard the desires of the font designers (I saw desires because font DRM is a desire, not a need). But the W3C has to balance it against the legal, ethical, and commercial disasters that are the history of DRM so far. Unlike the groups that have overseen DRM in the past, the W3C is not a corporate entity with bottomless pockets and legions of lawyers and lobbyists. Asking them to implement a font DRM system is like asking them to smear themselves with blood and hop into a shark tank. It makes much more sense for them to just wait for younger font designers to start licensing for the web and then watch the old guard cave or die.

That whole thread with it’s comments makes me really not like certain aspects of the FOSS community

Now imagine what its like for the people sitting on the W3C.

Font designers need to focus on selling fonts to the thousands of web designers who want to buy them instead of worry so much about the people who will steal the fonts.

Exactly!
I sympathize with a permission table but that will take many years to be fully implemented – and only days to get hacked. There will probably be an online tool or Firefox plugin where you just enter a URL of a website and the tool will retrieve all the used fonts with the permission bits changed.
So I wouln't hold my breath until such a form of "protection" is in place. I would be much more interested in discussing the ways in which webfonts could be licensed. It's a completely new market, so there are a lot of possibilities and opportunities. Why does the type industry doesn't discuss that? There are enough webdesigners and clients waiting to purchase webfont licenses.

Ralf, I may have got it wrong what Tal and David envisage, but my impression is that the point of such a table is to have fonts that are defined for the web, and can be licensed as such.

The defacto situation now for print fonts is that if someone uses an unlicensed font for personal use, or at least not published widely, they don't have much of any risk of prosecution. But if it is for big commercial use, then they run a risk, and have a motivation to license beyond just wanting to be honest.

I think that the goal should be to have something like that for web fonts, and I thought that is what David and Tal are after.

I do think that some of them have a point about "media" though. If the "photographic" industry had their druthers, and a voice in the matter, then the way the internet deals with images would undoubtedly be much different than it is today.

They are right in a sense. It's not the delivery that should be put through so much difficulty. It's the deliverer who should be held accountable.

That's why adding a basic table to new opentype fonts seems like a good idea to me. Deliver all of the fonts, regardless of format. Then hunt down those who blatantly use illegal fonts.

The web scraping technology to find illegal font users for that should be easy. You would have to go for the big dogs, the top of the DIGG/hot trends/mass viewership sites, because the dinky sites wouldn't/aren't worth it.

Thank you all for your fine comments.

Tal>He [Berlow] is proposing that everything should immediately start honoring the bits in this new table.
WADR, I have not proposing anything regarding honoring.

Web Authoring tools or browsers may do or not do anything in the presence of the proposed table. I support that fonts not having this table be un-considerable for web linking by new tools and browsers.

From William's link:
>What he fails to mention is that every font-consuming application on every platform on every computer on Earth will need to be “upgraded” to “respect” this permissions table.

I failed to mention this? No I think I left it out 'cause it ain't there to say. The linking to PermitTabled OT fonts (or any font) is I think, strictly between the linker and the owner.

Tal >My post details slight tweaks to the OpenType specification.
That's nice, but it's time for the table that the publishing industry needs. It will span to the next format, so why not now?

(Everyone else shoehorns their pitiful little app specific menu quirks into the std, and then "Oh time's up" or "it's full!"? ...or “let's get out of this format”? Wise thinking, too late.)

Tal> to offer support to Sampo’s idea for a web specific font format
And how does that help us? @fontface already works with Raw Fonts and most browsers. Web sites are already counting on fonts this way. What does a digital font format for the web have to have or not have that the OT font does not?

TP> BTW, Dave B lists four font formats.
Peck out my eyes for completeness.

>The difficult hurdle is getting it accepted by the W3C.
The Permissions Table is not for W3C to decide, or to implement anything based on, ever, (without my permission;)

>– and only days to get hacked.
Oh GOd! I hadn'T ThoUghTof ThAt!

Cheers!

"The web scraping technology to find illegal font users for that should be easy."

It could be if there was this tied-to-domain-per-license DRM. That said, I doubt such a DRM would be met with much applause from the consumers of type...let alone their clients. I also question whether there is actually a way to monitor said registry easily by the type foundries.

Maybe I'm wrong...

Count me confused. Thomas says that this has to be accepted by the W3C. David says no.

I confess I don't understand how these proposals--Tal, David or Sampo--are supposed to work.

1. Who has to do what? Is it Microsoft and Abobe that have to move on open type specifications? Who else?

2. Once some kind of table is in existence, how is type put on the web, and who has to do more work to get it on the web?

3. As far as enforcement, how does that work?

4. Who is burdened by this? In what way? Who benefits?

Excellent questions, William!

Tracking

WB wrote:

Count me confused. Thomas says that this has to be accepted by the W3C. David says no.

Well, let's put it this way. Putting it in the OpenType or TrueType spec doesn't *do* anything in and of itself. It needs to get respected by browser makers. Arguably that could happen without W3C approval, I suppose.

I confess I don’t understand how these proposals—Tal, David or Sampo—are supposed to work.

There is no distinct Tal proposal: he's backing Sampo's proposal.

1. Who has to do what? Is it Microsoft and Abobe that have to move on open type specifications? Who else?

Anybody who cares can have input to the OpenType / Open Font Format (OFF) spec. I'd suggest that somebody who cares get the OFF ad hoc group to examine both proposals and implement something for OpenType 1.7 / OFF

2. Once some kind of table is in existence, how is type put on the web, and who has to do more work to get it on the web?

Not defined. There are many different possibilities here.

3. As far as enforcement, how does that work?

Define "enforcement" first. :)

Browsers would need to respect the new info, for starters. But beyond that, dealing with hacked fonts, it would be no different than dealing with fonts stuck on web servers today. There could be several different ways of doing so, but most minor infringement will get ignored.

4. Who is burdened by this? In what way? Who benefits?

People who create or license fonts for money benefit. People who want to be able to legally use retail quality fonts on the web benefit. Browser makers are burdened by the need to deal with more info in fonts, and by possible legal risk under the DMCA (they are at least afraid of this, whether justifiably so or not).

Cheers,

T

William>2. Once some kind of table is in existence, how is type put on the web, and who has to do more work to get it on the web?

William, FontLab makes a table writer, the table is editable in FL, it's written in the fonts, we and our licensees are covered and can go on. (FL is suddenly claiming to have made the table for release soon, but it is still called EEULAAHA, so I'm dubious because; a. FL can't get the end point to attach to the start point, b. "End Users" are not involved in the legal or linking issues of web fonts, and c. FL doesn't license many fonts to web users, so they are likely to be under-clued as to the needs of such a table. We are writing our own for these and other reasons.

Thomas >Not defined. There are many different possibilities here.

There are not many different real possibilities here, though I'd love to here you stretch it. I have proposed discussion of a solution that is entirely, 100% self contained in the font industry. Anything that expects anyone else to do anything is not a proposal to count on.

>Browser makers are burdened by the need to deal with more info in fonts,

No actually they are not. I put Permissions Tables in my fonts, site and link to them, the browser's OS displays them on the user's machine and no browser has to do anything. It's already done today, and that's how I know.

>and by possible legal risk under the DMCA (they are at least afraid of this, whether justifiably so or not).

And this is 50% of the point of my proposal for discussion. Browser makers will no longer be at risk, the situation passes to be between linker and founder. No other legal is solution is available with no work by anyone else.

Cheers!

Thomas, David, thanks.

If I understand it rightly, David is just going ahead and doing this, and wants other people to come along, preferably with input on the best table. And that will raise awareness of and possibility of enforcement of licenses to web site owners for web use, paid by site owner but not user, without any additional steps.

Right?

I put Permissions Tables in my fonts, site and link to them, the browser’s OS displays them on the user’s machine and no browser has to do anything.

I’m confused. Are you saying that the end-users computers won’t ever be handling the permission table, that the OS will handle the permission table, or that you just want to put the permission table out there and not worry about whether or not apps that render type ever support the permission bit?

Yes. Doing it ourselves is the most effective option we have between the rapidly and slow moving W3C and the slow, slower, and possibly done OTF/F standards committee. And it's not just for enforcement/promulgation of licenses to web site owners, but also to the EOTs and Cufóns of the world that we must address changes, as the authors of those tm-busting services, wish to use only the PDF permissions for everything imaginable, and forever.

Cheers!

David, are you saying that the current version of FontLab can generate this table? How do you get it to connect the dots for both type designers and users?

ChrisL

Dave, have you considered writing up a white paper about your permission bits plan and publishing it with signatures from Fontlab and whoever else is on board? Your idea would probably be getting a much better reaction if you just put it all out there instead of dribbling out a little detail here. People aren’t too keen on what appear to be schemes hatched in secret, and I think it probably looks especially strange to non-type designers convinced that Microsoft is already the Vanguard on this issue.

David: “End Users” are not involved in the legal or linking issues of web fonts

They are not? Well, what is the legal or contractual relationship between a font vendor and a website reader who, by chance, finds a full-working font by said vendor on his hard drive after visiting a website? Would any EULA be valid for this user? It might be quite hard to prove that the user wanted to enter an agreement with a third party when he thought he was just visiting a website.

I think that's an interesting question, but I really can't come up with an answer.

What, exactly, does this table do? I'm a bit confused about that. Who/what is talking to who/what when a font is requested from the server?

> I’m sorry, but I don’t want to
> engage in a philosophical discussion
> about conflicting human desires.
> That’s above my pay grade.

mine too.

fortunately, that's not what it was,
a "philosophical" discussion. nope,
it is _practical,_ pure and complete.

so let me attempt a rephrase...

you're doing a lot of work
trying to build a system
to sell your work, without
first having determined if
enough customers want to
pay your price to buy it...

you are assuming there is
a demand for your product.

maybe there is. maybe not.

i certainly don't sense it, but
my experience is irrelevant...

so i'm not informing you that
there's no demand out there.

but i _am_ suggesting that you
might want to find out if there
is enough demand before you
spend time building a system.

or -- to say it another way --
you might find out, after having
spent a lot of time and energy
building a d.r.m. system that is
cracked "in a couple days", that
even when people _can_ steal your
fonts, we have no desire to do so.

most of us font heathens out here
have more than enough fonts now,
so we have settled in with a few that
have become our "favorites" and we
are happy with the current situation.
we don't think we need more fonts,
and you probably can't convince us.

but hey, maybe you know something
that i don't know. maybe your clients
for your print fonts are calling you up
on a daily basis and asking you _when_
they'll be able to use your fonts online,
and offering to throw so much money
at you that you cannot afford to ignore
this opportunity for a huge cash inflow
from corporations with money to burn.
in which case, i'd say "yeah, fleece 'em."

maybe there's some things i don't know.

i dunno...

-bowerbird

Disclaimer: I work for Monotype Imaging, the information presented below is my opinion only and may not represent the official Monotype Imaging position.

Tal wrote:
"The only change to the OpenType specification that I’m proposing is a single addition of a bit to fsType in OS/2. That’s a backwards compatible change that doesn’t require any support from font managers, applications or OSes. The only things that would need to understand this bit would be browsers ..."

I am afraid this is exactly the reason why adding a new fsType bit, or a whole new table wouldn't accomplish anything. 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. Adding a bit that is ignored by all existing OSes and applications would do nothing to stop this.

Font vendors do not want raw Truetype / OpenType fonts be served on the web to prevent font piracy. Luckily, web masters do not want to serve raw fonts either (you can find many embedded fonts discussions on www.webmasterworld.com). They need compressed fonts beause they want to minimize the amount of data transmitted from a web server to reduce traffic, and web designers want to speed up webpage download times. I understand that EOT domain locking mechanism may get in the way and be an obstacle when web content is staged on different servers, 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 if web fonts are just served compressed using MTX, this would be a win-win situation for both font vendors and web developers. A browser would have to simply decompress the file to use a font for rendering. An MTX compressed font file can not be used "as is" in OS applications and because the compression is not generic, it would at the same time work as the obfuscator to create a barrier for font piracy. Yes, I do realize that soon enough we'll see decompressor tool available on the web, and that there is nothing font vendors can do to stop people who are determined to steal a font. MTX will minimize web traffic (which is even more important for slow connections) and will prevent casual misuse because the compressed font can not be simply copied from a browser cache and used elsewhere. I do believe that 99% of users will not knowingly seek a tool that would allow them to rip the font from the MTX-compressed file.

Monotype Imaging has agreed to provide MTX compression free of charge on W3C royalty-free terms. So far, browser vendors oppose to implement it, they say it's to much work even though the source code implementation is readily available as part of the MTX spec (http://www.w3.org/Submission/2008/SUBM-MTX-20080305/).

-Vlad

Welcome,

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

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

So, the world has given us this choice. Even if your miracle MTX format doesn't allow users actual fonts, it'll be hacked.
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.

Cheers!

>Who/what is talking to who/what when a font is requested from the server?
CSS is talking to the UA which is talking to the server delivering to the UA.

What is so confusing?

>They are not? Well, what is the legal or contractual relationship between a font vendor and a website reader who, by chance, finds a full-working font by said vendor on his hard drive after visiting a website?

>I think that’s an interesting question, but I really can’t come up with an answer.
Do you want end users to be involved non-accidentally? Nobody does. We want them to get the benefit of superior type and typography, if possible. If a few fonts end up loose, (with a permission table that says it belongs to X under license to Y), who cares?

Cheers!

Vlad, thanks for coming on this discussion.

When you edit on Typophile, it changes the location to last. David, above, was responding to your first post, now below his. It is less confusing for readers here to add corrections or modifications in a new post, unless you know no one else has posted yet.

@bowerbird: Please format your submissions to at least 7 (and preferably 10 or 12) words per line.
Your current layout freaks me out. Which is nice-speak for ‘I am unable to to read it’.

. . .
Bert Vanderveen BNO

"CSS is talking to the UA which is talking to the server delivering to the UA.
What is so confusing?"

That's what we have now, no? What is the point of adding this table to the whole thing? Sounds like as Vlad mentions the browsers would have to be updated to a) use said bit b) restrict use of fonts based on said bit c) somehow not allow add-ons/plugins to circumvent said bit.

@bert bowerbird is the local troll. Best just to ignore it if you can't read it. (like I do).

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

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.

Cheers,

T

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

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.

Win-Win.

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

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

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

ralf-

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

-bowerbird

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

@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

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!

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.

@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

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.

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

bowerbird:

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

OR

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.

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

anyway...

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

so it sounds like all the problems are solved.

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

-bowerbird

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?

James:

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.

Cheers,

T

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

-bowerbird

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:
http://openfontlibrary.org/wiki/Blocking_drive-by_access

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!

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.

Cheers!

LOL!

ChrisL

...