Well, screen fonts are screen fonts. If they’re build with that purpose, shouldn’t their license approve it? I would let people use it for embedding on websites.

It would help people make a decision about this if the implications of ’same-origin checking’ were explained. In practical terms, how would this work and what would it mean for fonts on the web.

To put it another way, in what way would using ’same-origin checking’ make linking a font for use in a website unlike, say, my just posting the font on a warez site and inviting all and sundry to download and use it in whatever way they like?

To put it another way, in what way would using ’same-origin checking’ make linking a font for use in a website unlike, say, my just posting the font on a warez site and inviting all and sundry to download and use it in whatever way they like?

It doesn’t prevent the distribution of the fonts, but it makes the prosecution of illegal uses easier, because the fonts have to be uploaded to the website using the fonts and not just linked from a .ru domain.

Thanks, Ralf. That is helpful.

Now, what is CORS and how does that affect things?

“Cross-Origin Resource Sharing” is like “referrer checking” - it is a way for webservers to refuse to send files to browsers, such as when the browser is loading a page from another site that links to files on your site.

For fonts, it means that if foo.com publishes a page with a @font-face font linked, bar.org cannot say in its CSS for its pages to be displayed using the font available from foo.com - well, bar.org CAN say that browsers should download the font from foo.com, but foo.com won’t send it to them.

However, for a site like openfontlibrary.org, it is possible to configure the webserver so that it allows cross-origin resource sharing with other sites.

I hope the difference between this and EOT root strings is obvious; the effect is nearly the same, but the means are starkly different.

Thanks, David. So what we’re looking at is what Håkon Lie described here:

http://lists.w3.org/Archives/Public/www-style/2008Nov/0412.html

To fill out my understanding further, what does it mean to ’XOR a few bits’? And what are the options being considered for compression (MTX, ZOT, gzip) and what might their relative merits be?

@all

By all means, get the technical issues out on the table. They can all be well-explained in non-techie, plain English.

But I’d like to repeat here what I posted on
http://typophile.com/node/59489

Font-makers as a group need to swiftly move towards a consensus and begin to speak - at least publicly - with one voice on this issue.
Those who don’t quite understand the technical barriers to unlicensed use need to defer to trusted colleagues who do.
Just as in a labor dispute - say, the Writers Guild of America strike a few years ago that stopped TV and Film production - fragmentation is enemy number one.

Just my humble, but informed, opinion.

@john hudson

“XOR a few bits” refers to the obfuscation (scrambling) scheme that EOT uses. Part of the EOT spec that’s been derided as “DRM”.
As far as compression, ZOT seems to give the most impressive results so far. Vlad Levantovsky of Monotype has suggested a combination of MTX and ZOT, I believe. Another algorithm, LZMA has also been discussed.
It’s been demonstrated that compression will result in much smaller file sizes and therefore faster page load times; or at least that’s the goal. Expecially important for fonts going into mobile devices.
Compression would also, today, have a barrier effect to unlicensed use in that no operating system would recognize the compressed font file. Someone who downloads the file wouldn’t be able to just pop it into the Windows font folder, for instance, and use it. But that’s part and parcel of what developing a web-specific font file format is all about.

>Please post your thoughts here :-)

I’m not sure what “internal compression” means. But I think compression of font files should be driven by external factors like, is it required? what’s the document need? and what can the UA use? ...and then compress that (that being a font with no additional glyphs or tables), as required.

CORS sounds pretty good, but I’m concerned that nearly every week (besides a new format being proposed), a new linking technique surfaces.

I, and many others now, feel that the only way to address all of these issues at the foundries is to describe permissions and recommendations in an OT table, (where the w3c is not required to act), but I’m having a devil of a time finding all the existing linking possibilities, documenting then in terms of their capabilities and requirements and putting fields in the table proposal to allow their inclusion in our excellent scheme.

Cheers!

>but I’m having a devil of a time finding all the existing linking possibilities, documenting then in terms of their capabilities and requirements and putting fields in the table proposal to allow their inclusion in our excellent scheme.

You could post a working draft here and have the community help complete it. Alternately perhaps you could organize an ad-hoc session at TypeCon.

Richard: Part of the EOT spec that’s been derided as “DRM”.

As I understand it, the aspect of EOT that has been objected to as DRM is rootstrings, not bit obfuscation. I’ve not heard any objections to obfuscation on that basis and, tellingly, it is something that even Håkon is leaving ’on the table’, although he thinks that compression is sufficient.

David, while we’re talking about permissions, Microsoft, Mozilla, Google, Opera and others are engaged in a browser market dominance struggle in which web fonts are apparently the new front line. In the past few days, there have been almost 300 messages on the W3C font discussion list — after an average of about two messages per year for the past decade —, much of it acerbic, accusatory or simply hostile. If there’s going to be a consensus, I suspect it will involve two web font formats: both EOT and TTF/OTF. The former necessary for compatibility with existing versions of Internet Explorer, and the latter probably becoming the more common format. What’s necessary to get that consensus is for MS to support the TTF/OTF solution alongside EOT, which I’m not currently holding my breath on, but it is possible. [I suppose MS might succeed in holding out for other browsers to support EOT, but we’d still end up with dual formats, since the other browsers would continue to support raw TTF/OTF with or without the kind of mechanisms being discussed in this thread.]

The TTF/OTF implementations that already exist (Opera, FireFox 3.5, ?) link to raw TTF/OTF font files and presume that only freeware or other fonts with open licenses will be used, i.e. fonts for which protection is not considered necessary. What is now being discussed are mechanisms to make this format palatable for font owners (not just font vendors but also e.g. publishers with custom fonts). These are optional mechanisms that could be added to the existing TTF/OTF format solution without breaking existing implementations for raw fonts, and introducing no new data that browsers would be obliged to handle, while providing some safeguards (e.g. compression and/or obfuscation) and limitations (single-origin linking, i.e. the font must reside on the same server as the webpages that use it).

Something like your ’perm’ table seems to fit nicely within this scheme, in that it provides permissions information while not requiring the browser to do anything with this new data.
____

That’s what’s happening on the web font format standards front, which seems to me the most important thing to watch because its the only front on which we have any hope of a limitation of the possible implementations (instead of a format war in the market, à la HD video formats).

Then there are the independent solutions being put forward by TypeKit, Kernest and presumably others lurking in the wings. But I think these need to be considered in terms of services rather than formats per se. The format used by these services may have some impact on whether one chooses to license fonts for use by these services, but ultimately this is going to be a matter of contractual agreement rather than format permission.
____

Back to the original survey question:

I’m not a font vendor, i.e. the distribution licensing terms or permissions of the fonts I make are generally determined by my clients, not by me. So the question as originally posed doesn’t really address me. But if it is rephrased as ’Would I advise my clients for or against such a web font format?’ then I think the answer is positive: I would advise in favour of this format. The single-origin checking is the kicker. If the main defence against illegitimate use of web linked fonts is going to be licensing policing, then there has to be a mechanism that makes it possible to determine whether a usage is legitimate or not, i.e. to identify who is using the font and where. Compression is probably in everyone’s interest in a web font format, just as it is in graphics, video and audio formats.

As I understand it, the aspect of EOT that has been objected to as DRM is rootstrings, not bit obfuscation.

Actually, obfuscation has been objected to as DRM as well, by a noticeable minority on the list. But those folks seem to have decided it’s not really DRM after all.

In fact, pretty much *EVERY* move to do anything that User Agents would have to comply with, beyond downloading a font, has been objected to by somebody.

That being said, I agree that some sort of compromise is close at hand. I tend to expect that its protections will be weakened enough that many font vendors will not like it much. Which is a good reason to try to get consensus within the font development community. Then again, I’m not sure the browser vendors will agree to anything that would make the majority of font vendors reasonably happy.

Cheers,

T

@jh: what are the options being considered for compression (MTX, ZOT, gzip) and what might their relative merits be? MTX and ZOT are “inside font” compression schemes, where a font is split up table by table and compressed with a algo suitable for that specific table; gzip is a widely implement general purpose compression algo already in http servers and browsers. “in font” compression effectively obfuscates web fonts so they can’t be drag’n’dropped to local operating systems fonts folders, and can make fonts 30% smaller than GZIP.

Thanks, David. Yes, I like the idea of in-font compression as an option, i.e. not something that would be needed in all web fonts but something that a font vendor could specify as a license requirement or a publisher could opt to use to limit exposure of a font used online.

@jh: This idea that obfuscation (via compression, or expressly for its own sake) will limit exposure of a font seems wishful thinking to me.

Nothing will stop graphic designers and everyone else who loves fonts and who do not respect font licenses - which is most people, from what I can tell - from not installing inevitable “web font vacuum” browser extensions that will automatically install every font they happen to browse across into the OS system folder, and using these fonts in their print design work. I would also expect such “vacuums” to do what non-paying web publishers want, too, automatically stripping the watermarks, XUIDs and so on so that running a web-spider to search out unlicensed fonts doesn’t spot them.

If font vendors try to proscribe the behavior of paying users in an attempt to annoy non-paying users, they will only hurt their own sales by annoying their paying users.

Policing web fonts is going to be a total nightmare for those clients you just described on www-font, faced with the dilemma of having a font asset they wish to send to everyone who visits their website, yet not wanting anyone to use it. Perhaps Monotype and Adobe’s legal teams will have time and money in the recession to write takedown notices to people publishing their fonts without licenses, as it makes more sense for them to bet their existing revenues (from print based publishers, who are in decline) on the chance that new revenues from web publishers (who have pent up demand, and are growing) will be more profitable than sticking with the declining market. But for clients as you’ve described, they paid all the costs and will not offset their loss of exclusivity through incoming revenue from the font assets.

@all

I’m glad to hear Thomas Phinney getting the same vibe as I do - that a solution is within reach.
All the more important that font-makers come together, and soon.
I chose to use the analogy of a labor dispute because it highlights that this is a quid-pro-quo negotiation.
Those browser-makers with reservations about a web-specific font file format are looking to font-makers for assurance that web fonts will get the time and attention that they deserve. Just offering up print fonts for web use is not going to get the job done. (I’ve done a lot of testing. Taking the bulk of fonts as they exist today, and readying them for the screen will require work, and lots of it.)

And these fonts will need to be accompanied by simple, plain-English EULAs and reasonable pricing.

Actually, I do think of the font-making community in the same way as I do, say, professional baseball players. When the pro ball players go out on strike there’s no replacing them; there is no professional baseball, period.
And I think some of the folks involved in the discussions at the W3C have come around to sensing the issue in this light as well: that without enthusiastic and active participation by the pros, a dark cloud is cast on the future of typography on the web.
Now, one ideologically thorny flaw in the analogy is that the business model for fonts looks to copyright and not strictly to pay-for-performance as in sports.
So, as I said to Vlad Levantovsky on another thread, “Stop waving the EULA flag”. Stop going on about your “rights”. Not because you’re wrong, but because it’s counter-productive.
On the web, the extent of your rights, as well as your opportunities, will be defined not by legalities, but by a file format implemented through an agreement among the major browser-makers.
And these browser makers, web authors, and the browsing public sorely need and have a right to expect performance in exchange for this file format insofar as it provides reasonable protections against unlicensed distribution.

And so the bottom line question that many await an answer to is this: if you are given these protections, will you perform?
That’s the deal, yes or no?

@dberlow

As per Sii’s suggestion we can ad hoc ’til the cows in Georgia all come home, but politically, I think your proposal stands the same chance at the W3C as a snowball in hell.
It’s similar in some respects to Thomas Lord’s proposal, which many, myself included, find reasonable and intriguing.
However, there is clearly no interest in making this new font file format into an experimental poster-child for a new labeling/wrapper scheme. There is a clear preference for a timely solution targeted narrowly at the problem at hand.
I think your horse is dead, and the time to stop flogging it is soon. (Don’t mean to be snide, it’s just the way I see it. I don’t think I’m alone.)

Respectfully,

Richard fink

Dave, so basically what you’re saying is that there is no way to use fonts on the web that isn’t de facto giving the fonts away to anyone who wants them.

John: Speaking plainly, yes. I think selling web fonts means kissing rents for desktop use (ie, print publishers) of those fonts goodbye, for all but handful of loyal print designers who WANT to send type designers money, and are lucky enough to still be in business. Perhaps this will be more than offset by the money made selling web fonts. Maybe it won’t, and like everyone else in this depression, type developers will be earning significantly less money in 5 years time.

Personally, I think that all this talk about “fence posts” seems like wishful thinking about how the world really works, and in a couple of years these 200-emails-in-a-day discussions are going to be looked back on as a total waste of time that was costly and counterproductive. I mean, the guys who run thepiratebay.org got a jail sentence, and the site is still up.

Tom Lord and I spent a lot of time talking over this issue 9 months ago, and we really think that the best win-win-win situation for font developers, free software developers, and users is something like his MAME proposal - something to get people reading licenses.

People who love fonts really need to know what the license terms of the fonts they are downloading are. If the licenses are not made available in a way people actually pause to read - which is possible as that link demonstrates - then they will be ignored.

CORS has a precendent in Firefox, and no one objects to it. Compression is a good idea, Jonathan Kew’s ZOT is a fine free implementation, and no one objects to it. Neither of these things will stop the deflation of the print font market as I’ve described. More than these things isn’t going to work in the real world - except better licensing visibility.

This does NOT mean machine-readable licenses - that invite DRM features in programs and DMCA-style lawsuits. I think that hammering out the details of how to do this is the only discussion that is good value for time/effort long term.

Richard: All the more important that font-makers come together, and soon.

We’ve already been told on the W3C list, by a representative of the W3C, that the only opinion that counts is that of the browser makers and everyone else’s is ‘pragmatically irrelevant’ except insofar as as it influences the browser makers. So far, I’ve seen precious little evidence of font makers influencing any browser makers, and I’m not sure what you think we should do once they’ve ‘come together’. Microsoft is the only browser maker that has expressed any interest at all in protecting fonts, and even then I can’t help wondering if this isn’t simply a stance that happens to fit with their strategy in the browser war.
_____

re. David Berlow’s ‘perm’ table proposal:

I think your proposal stands the same chance at the W3C as a snowball in hell.

The proposal doesn’t ask anything of the W3C: its a font table that expresses specific license permissions in a font. It ain’t the W3C’s remit.

I can’t help wondering if this isn’t simply a stance that happens to fit with their strategy in the browser war.

Recalling the slashdot thread about this a year ago or so, I think many see it as a slippery slope to introduce DRM to the web.

@John Hudson: We’ve already been told on the W3C list, by a representative of the W3C, that the only opinion that counts is that of the browser makers and everyone else’s is ‘pragmatically irrelevant’
John, which representative of W3C told you that? I know it wasn’t me ... pointer please?

Nice to see your contributions on www-font, by the way, especially the point about publishers with licensed, exclusive fonts which they do want to use on (their) websites.

@john_hudson
“We’ve already been told on the W3C list, by a representative of the W3C, that the only opinion that counts is that of the browser makers and everyone else’s is ‘pragmatically irrelevant’ except insofar as as it influences the browser makers.”

I didn’t see this anywhere. I, too, would like the source of that quote.
But outside of it’s harsh phrasing, essentially true, I would suppose.
And that’s why I wrote:
“On the web, the extent of your rights, as well as your opportunities, will be defined not by legalities, but by a file format implemented through an agreement among the major browser-makers.”
This pretty much sums up the situation for anybody wishing to present anything on the web. That’s why the standards movement started up in the first place. If the browser doesn’t support the format you need on the client side, you’re screwed.
So the mission becomes: influence the browser makers.

As far as David Berlow’s permissions table:
“The proposal doesn’t ask anything of the W3C: its a font table that expresses specific license permissions in a font. It ain’t the W3C’s remit.”

Wrong. What the browser makers choose to support is very much their remit, as we’ve just established. You can’t have it both ways. You can add ten tables, but what are you going to do if the browser makers choose to ignore them on implementation?
You are most definitely asking something of the browser makers, certainly, even if there is no formal spec from the W3C, otherwise the table is an exercise in pointlessness. You are asking them to display, or act upon, the table.
So, please, by all means ask them if they want to be bothered with it at this time?

Chris Lilley — ... pointer please?

The comment was by Aryeh Gregor at 3.7.2009 with subject “Re: Fonts WG Charter feedback”:
Because the browser implementers are the ones who decide what formats they’ll support. All other parties are therefore pragmatically irrelevant except insofar as they can get the browser implementers to agree with them.

@Daniels>You could post a working draft here

The second draft has gone to tool developers. The third will be posted by TypeConTime.

>Alternately perhaps you could organize an ad-hoc session at TypeCon.

I wish, and I thank you for the idea, but my goal here is to do the best possible presentation of as much knowledge as I can, to the most powerful people in the path of this thing. That means my lawyer, my tool developers and the committee to re-elect OT/OFF president and dictator for life. Besides which I have 3rd degree burns on my fingertips from unknowingly stepping into ad hoc audiences, like the new fellow I respond to down below.

@Hudson>Microsoft, Mozilla, Google, Opera and others are engaged in a browser market dominance struggle...

That’s one way of putting it. And what is the revenue of that market?

Another way of putting it is that the W3C has had an unnatural sometimes not so secret user agent struggle on its hands for 15 years and so fonts are going to blow the web to smithereens if someone doesn’t do something 3 years ago.

Yet another way of putting it is that the OS/UA manufacturers have the non-OS/UA manufacturers by the throat and because one of them is a W3C headman, they are all unhappy.

> I suspect it will involve two web font formats: both EOT and TTF/OTF. The former necessary for compatibility with existing versions of Internet Explorer, and the latter probably becoming the more common format.

With all due respect, if old versions of user agents do not work or cannot be made by the web developer to work with OT@F-F, the user whose agent it is will need to upgrade. Besides which, if a PERM table solves ’the problem’, EOT can vanish as fast as a speedo-ing bullet.

@Phinney>In fact, pretty much *EVERY* move to do anything that User Agents would have to comply with, beyond downloading a font, has been objected to by somebody.

... beyond downloading a font, installing a font and deleting a font, I hope...:) That’s all I want them to do.

>@abattis

I’m not going to quote you, but, I can read that you are misinformed. You think e.g. people “love” their User Agents more than they “love” their fonts; Do you know how much bigger the revenue stream is for fonts than for W3C-compliant User Agents? (come to think of it, you think they are jealous?).

“Print people” license if they need to, “web people” will license if they need to. Your opinion seems based on a misunderstanding of the place of IP in developing unique visual identities, (a force much more powerful than the web).

But if you’ve talked it all over with a Lord (whoever he is), that makes it all the more authoritative.

>We’ve [...] been told on the W3C list [...) that the only opinion that counts is [...] the browser makers and everyone else’s is ‘pragmatically irrelevant’...

Nice to know, thanks and thanks for the compression terms. What happens if they are not of one opinion? What happens if they are not of one good opinion? What happens if they are not of one good legal opinion?

Cheers!

Do you know how much bigger the revenue stream is for fonts than for W3C-compliant User Agents?

Maybe we should pass the hat round, and buy them out?

The comment was by Aryeh Gregor at 3.7.2009 with subject “Re: Fonts WG Charter feedback”:

Thanks. Aryeh Gregor is not “a representative of the W3C”. I’m puzzled why John Hudson thinks that to be the case.

Chris, sorry, I see that now. Aryeh’s email address confused me, but I see that it is probably a list-specific e-mail; previously, I just spotted the ‘w3c’ in the email address and jumped to conclusions. So I withdraw my statement about ‘a representative of the W3C’.

Actually, I’ve decided I’m probably riding the ‘pragmatically irrelevant’ statement too hard. It stung at the time.

This seems to me a bit like climate change. The time to act to accomplish a meaningful solution and prevent unfortunate consequences may have passed years ago, but we’ve mostly been talking since then. Now changes we don’t like are upon us and, at this last minute, we start scrambling around trying to patch together a solution suggesting things like EOT many didn’t want to have anything to do with a few years ago - and that, at best, may afford only temporary shelter, easily blown away.

I’m not suggesting nothing should be done - but let’s be realistic about what can be accomplished at this late stage. TTF/OTF linking is already starting to happen - it’s not going to go away.

Adding something like David’s PERM table or an EEULA table to the OTF spec should not be that difficult - though I think there needs to be a fairly immediate deadline for specifying the layout of this. Font developers and vendors could then, without too much difficulty start adding this table to their fonts - and begin trying to persuade at least some browser vendors to make use of the additional embedding bits etc. contained in the table. This table would be useful whatever the eventual font format(s) browser vendors decide to support.

- CF

>...though I think there needs to be a fairly immediate deadline for specifying the layout of this

I am not afraid to do this, but because having such a deadline will target the effort for those who are intent on all solutions failing, other people should be afraid...

Don’t forget that this problem, in my humble opinion, has resulted from unregulated development by a non-legislative unelected body of people who seem unable recuse or explain themselves in the presence of either unfair competition, or conflict of interest.

Cheers!

...and who while on the one side refusing to have anything to do with DRM-like protections on the grounds that failure to respect them might open the browser makers to DMCA lawsuits, are already ignoring the embedding bits that are part of the format that they have chosen to implement. Since they don’t own that format, and since that format is extensible under an ISO standard, they can’t know that new linking permission bits or tables won’t be added to that format.

Coming to TypeCon, David?

...but
>Chris, sorry, I see that now. Aryeh’s email address confused me

But on the other hand, HL/UA developer/w3c menber, did say this:

Personally, I’m not comfortable with formats that add more licensing
information, even if the corresponding standard says it can be
ignored. It seems quite easy to construct a case where the browser, by
ignoring digital rights in the files, breaks DMCA-like laws and is
therefore a “circumvention device”. I’m not convinced that the
standard would trump the law in court.”

SO000oooo..... I think perhaps it should work like this?
’we’ make a table (perm) proposal and assuming it survives, or it will survive, for having been designed so browsers can easily Present 100% of the Permissions to Users, (both web dev. and end using people) and Enforce 0%. Presentation will include all ness. links to ownership lic. options and future auto lic. options as they become available. This is on our current path I believe, though One developer is resisting immediate Internationalization capabilities, and that is concerning me. What to do?

Presenting Recommendations to users, then should be icing on the cake that the browsers can take credit for and may compete on typographically with an open std via which they can help users design and employ type more effectively.

I am happy with that. But we have to add more lic. info... there’s more divers licensing to do. And the spec for the table is growing exponentially entertaining.

I’m also sorry that I’m tempted to explain to another person, much less from the w3c, that this is not like photography we are licensing here, (or music, or text, or graphics). . . but I don’t seem to have time.

TypeCon is getting close is it?

Cheers!

It seems quite easy to construct a case where the browser, by
ignoring digital rights in the files, breaks DMCA-like laws and is
therefore a “circumvention device”.

Therein lies your big problem: the needs, desires, and intention of font designers will probably never trump potential abuse of DMCA-likw laws in the eyes of software developers. Given that web font formats and the related issues will probably remain a morass for years, it might help those want web font protections and whatnot to join the cause of DMCA reform as a gesture of goodwill.

James, while I’m no great fan of the DMCA, I’m not yet convinced that a gesture of goodwill is what is necessary in the current situation. There is a time for such gestures, and I hope that such a time will come, but there is also a time to demonstrate that one is willing to make a fight out of something.

On the other hand, Håkon (’twas he) may be bluffing or simply mistaken in his concerns about DMCA. See also
http://lists.w3.org/Archives/Public/www-font/2009JulSep/0266.html

@ Richard: “this is a quid-pro-quo negotiation.”

I’m not at all convinced of that. The browser vendors aren’t really giving up anything, have nothing at risk really. Any change is good for them. The font vendors are worried about losing their entire livelihoods.

@Chris Fynn: “TTF/OTF linking is already starting to happen - it’s not going to go away.”

It’s not going to go away, but it isn’t a huge deal until/unless Microsoft starts to support it in IE (on top of the other browsers doing it).

The converse is also true: any other solution needs to be supported by at least MS/IE and Mozilla/Firefox (and arguably Apple/Safari) to become a real standard in the practical sense, which sees people using it widely.

@ abattis: “I think selling web fonts means kissing rents for desktop use (ie, print publishers) of those fonts goodbye”

If everybody will have the font, why won’t they use it for web use as well? It seems to me inescapable (with any of the options being discussed) that if it destroys the retail market for desktop fonts, it stifles any such market from even emerging for web fonts. What am I missing here?

@ John Hudson: “Håkon (’twas he) may be bluffing or simply mistaken in his concerns about DMCA”

I believe that some of the Mozilla/Firefox folks expressed similar concerns. Not saying those concerns were justified, just that they had them.

Cheers,

T

“TTF/OTF linking is already starting to happen - it’s not going to go away.”

TrueDoc started to happen, and it went away (heck, the whole Netscape browser as it then was went away). I expect several startup web font services like TypeKit and Kernest will start to happen and then go away. Raw TTF/OTF could easily be replaced by a format that is as easy to implement and with no greater obligations of digital rights management on browsers, but which would include numerous optional gates between using fonts and giving fonts away. I think TTF/OTF linking happened because nothing else was happening, the non-MS browsers didn’t want EOT, and they went for the easiest option, in part to force the issue. Okay, the issue is forced. W3C is possibly interested in defining a standard, let’s start making some proposals. But not as additional formats alongside raw TTF/OTF linking. I think we should be totally clear that raw TTF/OTF linking is unacceptable even for fonts with unrestrictive licensing because font formats should resolve technical and usage problems, not licensing discrepancies. If a difference in licensing requires separate font formats, you know there’s a basic error in thinking. A font with unrestrictive licensing might have open gates, but it should still have the same gates as another font. There is no need for multiple formats. [And if there were to be multiple formats, the one associated in users’ minds with unrestricted licensing or ‘free fonts’ shouldn’t be the TTF/OTF format. That is just inviting every TTF/OTF in the world to be uploaded onto the new filesharing — sorry, web publishing — system.]

> http://lists.w3.org/Archives/Public/www-font/2009JulSep/0266.html

Forgetting about whether Opera has done their due diligence on their own software, if browser makers were going to be sued over font linking, who in their right minds would sue Opera, Mozilla or Firefox first?

>And if there were to be multiple formats, the one associated in users’ minds with unrestricted licensing or ‘free fonts’ shouldn’t be the TTF/OTF format

That’s already done.

Cheers!

That’s already done.

I’m not convinced that it can’t be undone. The only reason I see that ‘it won’t go away’ is that there are people saying so, and no one has yet come up with an acceptable alternative. But Thomas makes a good point: so long as Microsoft hold out against TTF/OTF linking, it isn’t a big problem. The browser makers are very, very keen in interoperability, which is why Opera et al are trying to make their possible support of a second webfont format conditional on Microsoft supporting TTF/OTF linking. I think Microsoft should just say no.

One of the lines along which I am thinking is something like this: the sfnt format is extensible, so extend it to include the gates and bulkheads necessary to make it an appropriate format for web fonts. I have no objection to TTF/OTF being the web font format if TTF/OTF fonts come with optional gate and bulkhead systems, of which something like your perm table or an embedded electronic EULA table would be one example (others would be compression, domain-linking, single-origin linking, etc. What I object to is putting these gates and bulkheads into a different web font format but still supporting TTF/OTF as the ‘free font’ format.

@thomas phinney who wrote:

“The font vendors are worried about losing their entire livelihoods.”

 Firstly, do you know if 401K’s will be exempt from this? Or are web fonts going to wipe those out, too? After all, for those planning on a forced retirement due to web fonts, this is important information! (Just a little gallows humor, Thomas. My Israeli friends are getting inside my head.)
 I’d like to know if you agree with this assessment:
 If it is anyone’s firm belief that Web Fonts will bring about a world where, because of unrestricted access to font files on web servers, font makers will no longer be able to get paid for their work, then it’s important to realize that the process has already begun and there’s no stopping it. It’s a process that can be influenced and modified, but not reversed.
 IE has supported @font-face using EOT files for many years. I can already convert any TTF file into an EOT and it will display in IE. I can use “free” fonts, retail fonts, it doesn’t matter. And as long as I’m willing to ignore copyright considerations I can do anything I like. And those that believe that font makers will no longer be able to get paid are implicitly acknowledging that I can do what I like and get away with it.
 Otherwise, why the worry?
 Plus, I can pick up the retail fonts I need at no charge on the darknet. No money down.
 Now, recently, Safari and FireFox have both begun supporting font-linking as well, but they support linking to “raw” font files that I don’t have to pre-process to use.
 So you would figure that I’m all ready to roll. Time to start using web fonts today. Not quite.
 The one thing that’s stopping me is lack of @font-face support in older versions of FireFox and, to a lesser extent, Safari. If I want to get a uniform result across browsers, I have to wait the couple of years for enough FireFox users to upgrade to version 3.5 to bring my expectation of cross-browser uniformity to an acceptable level.
 But once that threshold is reached, web fonts are a completely practical proposition.
 So, if there is a firm, rational basis for the worry, then it would be wise to start looking for a way to replace that lost income starting today.

Right?

It seems like the fear is based on the assumption that graphic designers hate paying for fonts and only do it because...well, I’m not sure why in that scenario.

As it is now, I assume that graphic designers and print shops are the primary purchasers of fonts. I also assume (from experience as a graphic designer) that most designers know how to very easily get fonts if they want to without having to pay for them.

So it seems like this already exists. I’m not sure how @font-face will make the problem any worse. I suppose grandma, not knowing any better, could accidentally or purposefully install a font from a web site to use on her own computer, but she wasn’t really a paying customer before anyways, was she?

I’d like to believe that it could work out like the music industry...make the asset easily available and usable to the consumer and many will buy it (even if many do not).

@TP: If everybody will have the font, why won’t they use it for web use as well? Because it is far easier to spider the web and send takedown notices.

@abattis

Are independent font makers in a position to do this? To spend a lot of time and money on takedown notices?

My opinion is that font makers might prosper in spite of all this.
Just asking if the boogeyman is for real, that’s all.

Cheers,

rich

@Richard: I expect a “font-police.com” business will be started shortly.

@Richard:

I agree with almost everything in your epic post above, except the final conclusion. Until/unless all the major browsers agree on and implement a single format for web fonts, web fonts won’t take off (or any take off will be only via those vendors offering hybrid solutions, such as TypeKit and Kernest).

Unfortunately, most type designers don’t have a 401K. Folks like me who have worked for large companies are the exception.

@abbatis:

Richard is correct. Sending takedown notices is a time-consuming thing, and potentially a full-time job in itself. Many foundries already ignore all but the most flagrant violations because it just isn’t cost-effective, or because attempting to police the web is a quick route to insanity. I don’t see that having a couple of orders of magnitude more fonts on web servers will help that situation.

Cheers,

T

@tp: sure, but isn’t that a business opportunity for a savvy law firm?

And who, pray, will pay them? Not me.

> And who, pray, will pay them?

Why, they will work for free, over the Internet. Everything on the Internet is free.

Some measure of font piracy is built in to DTP and the promiscuous font formats that we’ve been using for over 20 years, during which time the present digital font industry has grown and diversified, especially during the last few years.

In professional circles it is endemic, due to the peripatetic nature of design employment, and yet “above” a certain level, legit companies also form the best clients/customers.

As long as there is some indication of what is allowed and not allowed, there will be a variety of legal and non-legal font use.

Recently in science news, it has been noted that virtuous behavior in one area of a person’s life may be compensatory for transgressions elsewhere. And vice versa, which could be called the Spitzer Effect.

So the sky isn’t falling, but at the same time we have to send a clear message, create a magnetic field against which people can set their moral compasses, whatever course they choose to take.

No doubt we are clothing our self interest in the garb of ethics, but that’s the way everyone plays the game.

Here’s a random idea out of the blue that may have merit or may be ridiculous, but I’ll toss it out there...

What if the browser manufacturers implemented some sort of colophon feature? It’s long been standard in pro web design to have a copyright block at the footer of the page. What if the browser, itself, rendered such a block in, say, the browsers bottom status bar?

The web site author could use a copyright tag, perhaps:

[copyright]All Contents (c) 2009 megacorp[/copyright]

And then perhaps the browser, supporting @font-face would know how to grab the font’s copyright data from the file itself (provided such a tag would exist in the font file format).

So in the browser’s status bar, something like this could be displayed:

Site: All Contents (c) 2009 megacorp; Fonts: Font X (c) 2008 Adobe Systems, Font Y (cc) 2007 freebie font corp.

(or maybe it could be rendered in a slide-down panel ala Firefox’s pop-up blocker or password remembering windows)

On top of that, perhaps the browser could intercept any call to a font file directly with a pop-up dialogue window that also explains the copyright info. Something like:

You are about to access a font directly: [font-name] [copyright] [brief license overview] OK/CANCEL

The basis of the idea is to ensure licensing/EULA information is communicated (in the name of educating the naive) rather than burdening the web devs and/or browser devs with various forms of DRM or DRM-lite/esque features.

Just a thought...

Any kind of mandatory credits feature is a bad idea as things tend to pile up and become unmanageable. The free software world ran into trouble with this early on when all the little code snippets that required credit ended up creating huge lists of contributors that had to be dealt with and people got sick of it really quickly. Complex web sites would have to credit themselves, the CMS system, the plugins to the CMS system, the Flash stuff that powers their image zooming, fonts, images, etc. and the list would never end.

And nobody is going to use web fonts if it involves the users seeing a popup and a clicking through licenses. People hate that kind of annoying interaction. Remember when Microsoft had to put a popup block in IE, hampering it’s own popup ad network? Even if they do, the users won’t read the licenses anyway; they’ll just install some plugin that automatically agrees to them without displaying them.

James is right.

But for what it’s worth, pretty much all fonts have copyright notices built in already in a standard place. There’s no technical reason one couldn’t do such a thing.

Cheers,

T

@thomas phinney who wrote:

“Until/unless all the major browsers agree on and implement a single format for web fonts, web fonts won’t take off (or any take off will be only via those vendors offering hybrid solutions, such as TypeKit and Kernest).”

Take off to the extent it would if there was that single format, no, it won’t. I agree.
But enough said, epic or otherwise. Web font fatigue.
Gotta go do other things before Atlanta.
Later...

Richard Fink

@aluminium: A similar idea was proposed by Bill Hill last year.

The basis of the idea is to ensure licensing/EULA information is communicated (in the name of educating the naive)

What licencing information should be displayed for “restricted” (as in not available under a free licence) fonts? There is no licence agreement between the foundry and the reader of the web page, nor would the foundry usually be interested in entering one.

>What if the browser manufacturers implemented some sort of colophon feature?

Look! Users (and I don’t mean ’end’ users, but web developing users), do not want to ’read’ licensing information. They just want clear statements of their permissions, should they seek then. The only other thing that can get them and browser bowsers drooling is if you have quality information in the font pertaining to its best uses, i.e. recommendations.

End users are just not in this loop unless the browser developers are sloppy font pigs.

> A similar idea was proposed... last year.

And? It was useless last year too.

Cheers!

Well, it looks like we’re siding with it being more of a ’ridiculous’ idea, and I really don’t disagree. ;o)

But I guess that does still leave me scratching my head a bit as to what kind of solution the industry is looking for.

But maybe there isn’t ’one’ solution that the industry is looking for.

It seems like there are maybe a few camps:

- those that think @font-face means that all people will just download the fonts they want from various web sites and never ever pay for another font again as long as they live.

- those that want/hope for a DRM system that somehow—unlike every DRM system before—will actually work as intended and not annoy the paying customers

- those that are going with the flow and just see it as another venue for both sales and illicit use

- those that want some sort of web font format that is compressed, subsetted, and slightly munged. Not DRM, but definitely a different file format.

Seems like the last 2 are the likely scenarios going forward, eh?