Real Fonts on the Web: An Interview with The Font Bureau's David Berlow
by DAVID BERLOW, JEFFREY ZELDMAN
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?
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.
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."
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.
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 “FUCK 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.
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.
@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.
tai, just a few points on your post,
which sounds fairly reasonable...
> 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...
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.
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 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:
- don't want people freely copying their fonts
- (some) would like additional $$$ for use on web sites (and PDFs)
- 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.
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!
"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!
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.
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.
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.
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).
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.
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.
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.
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?
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.
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.
Disclaimer: I work for Monotype Imaging, the information presented below is my opinion only and may not represent the official Monotype Imaging position.
"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/).
>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.
>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?
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.