According to our logs, my font posts have been some of the more popular on this blog. So that got me thinking: how can I pander to the crowd and create a few more font posts to generate even more traffic? Seriously, it did get me thinking about web fonts again.
The root problem of typography on the web is current model that the browser will only render a font that is installed on the computer. Designers get around this by rendering text as images, but there are obvious scaling, localization, and internationalization issues. SIFR is a great utility for working around this -- and I highly recommend it -- but ultimately it too is a hack and is not very easy to use.
CSS 2 documents the @font-face rule, which allows designers to point to a font file on the web, thus ensuring that anyone viewing the page will see it in the proper font. However, Safari is the only major browser that currently supports this; heck, even Opera doesn't support it. Without support from IE or Firefox, this is bound to be another piece of amusing trivia, but not useful for actual web design.
But that got me thinking... Firefox does have an add-on architecture. One could write an add-on that supported @font-face. Nice, but why stop there? The designer in me wants a new system that will work with all the web sites that are already out there. What I want is a Firefox add-on that makes a list of all the fonts needed on each page, and if they aren't installed on the computer, goes out to the web and gets them.
Google recently announced their AJAX Libs API, which enables any web developer to link to popular Javascipt libraries and let Google worry about hosting and updating. It's basically a central repository for commonly-used web resources.
So here's my grand vision (1.0): a central server that hosts the most-recent version of all popular open-licensed fonts, and a Firefox add-on that uses the font repository when the required font is not installed in the browser's OS. It turns out we don't really even need support for @font-face, though it would be useful for those who want to use a font that isn't in the central repository.
Update to grand vision (2.0): Actually there doesn't need to be a central repository, just a central index of font files. So all we really need is an open font directory server that lists all of the known ttf and otf fonts out there by name with URLs to them, much like DNS is a directory of IP addresses based on domain names.
Anyone want to take this on? Ping me in the comments if you're interested. Googlers looking for a 20% project, take note!
The root problem of typography on the web is current model that the browser will only render a font that is installed on the computer. Designers get around this by rendering text as images, but there are obvious scaling, localization, and internationalization issues. SIFR is a great utility for working around this -- and I highly recommend it -- but ultimately it too is a hack and is not very easy to use.
CSS 2 documents the @font-face rule, which allows designers to point to a font file on the web, thus ensuring that anyone viewing the page will see it in the proper font. However, Safari is the only major browser that currently supports this; heck, even Opera doesn't support it. Without support from IE or Firefox, this is bound to be another piece of amusing trivia, but not useful for actual web design.
But that got me thinking... Firefox does have an add-on architecture. One could write an add-on that supported @font-face. Nice, but why stop there? The designer in me wants a new system that will work with all the web sites that are already out there. What I want is a Firefox add-on that makes a list of all the fonts needed on each page, and if they aren't installed on the computer, goes out to the web and gets them.
Google recently announced their AJAX Libs API, which enables any web developer to link to popular Javascipt libraries and let Google worry about hosting and updating. It's basically a central repository for commonly-used web resources.
So here's my grand vision (1.0): a central server that hosts the most-recent version of all popular open-licensed fonts, and a Firefox add-on that uses the font repository when the required font is not installed in the browser's OS. It turns out we don't really even need support for @font-face, though it would be useful for those who want to use a font that isn't in the central repository.
Update to grand vision (2.0): Actually there doesn't need to be a central repository, just a central index of font files. So all we really need is an open font directory server that lists all of the known ttf and otf fonts out there by name with URLs to them, much like DNS is a directory of IP addresses based on domain names.
Anyone want to take this on? Ping me in the comments if you're interested. Googlers looking for a 20% project, take note!
Dave,
there is no need for a "central server for fonts", just like there is no need to look anything up for fonts. Fonts can be specified by a family name (local fonts) or by a URL (server fonts i.e. web fonts). The URL is good enough, why would you want anything else?
Also, the problem with a central font directory is that it would never replace URL addressing of font resources. Why? Simply because not all web fonts will be for everyone to use, just like not all images are "for everyone to use" even though they're "on the web". If I obtain a license to use a server font on my corporate website, it does not mean that automatically other web designers can use that font on their websites — this is similar to images, again. If I purchase an image for use on my website, it does not mean that everyone else can use that images on their websites.
So what would the central repository do?
Also, keep in mind that one web designer can use a server font named "Garamond" on their website and another can also use a server font named "Garamond", but those will be completely different fonts — just like my "photo.jpg" is likely different from your "photo.jpg". It's the URL that will make the difference and uniquely define the font's location.
The web itself is a "central index of files" — and the URL is simply the unique address in that index. I don't understand why we would need a separate structure just for fonts.
Adam
It really comes down to ease of use.
Sure the @font-face standard allows you to point at fonts, but that requires the site developer to either put the font on their server, or hot-link to a font already on the web (which could go away at any time). My proposal requires no extra work on the site developer's part. They continue to use font-family declarations as they do now, and it gracefully falls back to the web as a resource if the local "cache" of installed fonts comes up empty.
Regarding licensing issues, that already exists whether or not my system is in place. If a font with a restricted license is up on the web in an unsecured location, it's the site owner's responsibility to deal with that. Simply asking that third parties not link to that content is untenable. Even Google, Yahoo!, and the other big search engines don't try to determine what content is fair to index and what is not. Note that there are ways to prevent hotlinking, such as using the RewriteEngine in the htaccess server config file.
To your point of ambiguity of font names, yes that would definitely be an issue. But I think it just comes down to intelligent defaults. For ambiguous font names, pick the best freely licensed option out there and map that to the generic name. Have a system of disambiguation of font names, such as the acronym suffixes popularized by the foundaries, or even allow fonts to be referenced by a GUID. Note that any search engine deals with ambiguity by ordering the search results, and ours would be no different. For any ambiguous reference, we simply return the best result. The key here, though, is to ensure consistency.