As far as I can make out you’re proposing a central repository for “open-licensed” fonts designed to be used on webpages. That’s the main thing, and I don’t think it will make much difference how this repository is accessed by user agents—as long as user agents support @font-face, the font resources could be centralized or scattered at numerous locations.

It’s an appealing idea, but you can probably improve web typography faster by spurring Microsoft, Mozilla and Opera to make their browsers support @font-face. Håkon Wium Lie, the guy who developed CSS and @font-face, works for Opera, so I assume the next version of that user agent will support @font-face.

The other major factor in all this is support from font makers. I’ve just released a font explicittly licensed for “embedding” on webpages using the CSS @font-face rule and unlimited distribution on web servers. You can read more about it here: http://typophile.com/node/46088

j a m e s

A web service for commercial fonts would be great. I am also trying to promote that idea:
http://opentype.info/blog/2008/04/19/font-face-survey-results/

But a web service for “open-licensed” fonts doesn’t make sense to me. Why should I rely on a service when I can put the font on my server instead? The Google hosting of code libraries is a different thing because such libraries change all the time and it’s a nice service that you could just link to the library and Google cares about the updates. But fonts are rarely updated.

>just having a browser plug-in

Well, that’s what we have now, isn’t it? It’s called Flash. And 90% of font vendors either allow, or turn a blind eye, to font redistribution within .SWF.

Cheers, Si

And it’s a malice...

@font-face, a XHTML+CSS standard is the way to go.

Szabolcs

This solution wouldn’t preclude @font-face, but @font-face has 3 barriers to entry:

1. Requires browser support, which only Safari has now
2. Requires explicit calls in the CSS
3. Doesn’t deal with commercial licensing issues

My proposal still has #1 as a requirement, but the other two are not issues at all.

Actually @font-face has been supported in IE for ten years. However, one of the major problems with its support (and the same goes for your suggestion) is that it uses a proprietary font format (Embedded OpenType). As Szabolcs’ suggests open standards are clearly the way to go in today’s world - not that Flash is on the way out.

As you probably know EOT has been submitted to the W3C for standardization.

1. Requires browser support, which only Safari has now
2. Requires explicit calls in the CSS
3. Doesn’t deal with commercial licensing issues
My proposal still has #1 as a requirement, but the other two are not issues at all.

Your system works without “explicit calls”? How are the font selected then? The visitor of the website decides!?

As you probably know EOT has been submitted to the W3C for standardization.

Any update on how that’s going? It’s been nearly a year now.

Actually it was submitted in March or April. I think the schedule is by the end of this year.

My proposal still has #1 as a requirement, but the other two are not issues at all.

Q. If the other two are not issues at all for your proposal, why are they such big issues for @font-face?
A. Because any kind of scheme for using explicit fonts on webpages requires explicit calls in one form or another in the CSS, and the type industry doesn’t run on good will alone, but well-defined EULAs and cash. It has to be practical, and if your proposal treats an issue like commercial licensing as a non-issue, it’s hard to see many people getting behind it.

j a m e s

@Ralf Herrmann: In my system, fonts are simply referenced in the font-family CSS declaration as today. The system would then fetch any reference fonts from the server if they are not present on the local computer.

@James Arboghast: Having a central server makes it trivial to ensure commercial fonts are not present. If for any reason they do appear, requests (or in the extreme DMCA takedown notices) are all that would be needed to rectify the situation. And again, if this turned out to be a popular system, it could be extended to include DRMed font files to enforce commercial licenses.

Of course if it gets popular, the costs of running the service could become pretty large. Which is why I think Google should do it, just like they’re doing for popular javascript libraries.
http://code.google.com/apis/ajaxlibs/

Ralf, I think David’s idea is to make font face declarations as simple as possible.

@davidc: Having a central server makes it trivial to ensure commercial fonts are not present...

You trivialize the issue of commercial licensing by calling it a non-issue, using flawed reasoning like ...If for any reason they do appear, requests (or in the extreme DMCA takedown notices) are all that would be needed to rectify the situation.

If your proposal is practical it will ensure commercial fonts never appear in the central repository. Then nobody will need to send cease and desist notices and commercial fonts won’t have to be removed. A DMCA takedown notice is not extreme. That’s kid’stuff in the world of intellectual property and commercial rights enforcement.

Have you talked to Google about it yet? Google may say yes, but then you’d have to get font makers to donate fonts to the repository. I’m not trying to knock your idea into the ground. It has potential, but it needs support from font makers. It needs fonts. You already have my support in the form of Pyke’s Peak. The question is, How many other font makers will donate a font or two from their catalogs?

j a m e s

Ralf, I think David’s idea is to make font face declarations as simple as possible.

Here someone just started a service for central hosting of sIFR fonts: http://www.fontburner.com/
Makes a lot of sense, because sIFR is not easy to set up.
But a @font-face declaration is as simple as linking an image on a website. So I don’t see a real benefit in this plugin approach over a @font-face implementation. Am I missing something?

@font-face declarations can be as simple as linking an image on a website, if the font resource is on the same server as the html/css files. If it’s on another server the call will involve http://website.com/yada-yada/yoda.otf.

If a central repository of “open licensed” fonts existed, broswers could in theory be made to look in the repository by default if the font called doesn’t exist in the same directory on the same server as the html/css.

The increase in simplicity may be small, but in the world of web development many small gains add up.

j a m e s

Here’s a thought. What if we just consider the union of all the current free font sites out there* “the font service”? At that point the service is simply an mediator. Create an index of the fonts available and their source URLs, and grab the file from the server when it isn’t available locally. This seems like a pretty straightforward piece of code.

BTW, thanks to all for having this discussion with me. It’s been helpful in thinking about how to approach the design of the system. Now I just need to find a developer...

* dafont.com, 1001freefonts.com, urbanfonts.com, simplythebest.net/fonts, fontgarden.com, fontsugar.com, larabiefonts.com &c.

Just one of the many flaws: you have to many name conflicts in fonts.
Also, they are virtually unavoidable.

Szabolcs