- Typography (along with layout) is one of the two basic elements of design.
- You currently cannot pick a typeface for your website without using graphics. Many excellent designs therefore use images for all headings.
- Domestic broadband has reached up to 80% penetration in some countries. It is over 50% in many countries. In commercial organizations it has a much higher penetration. Jakob Nielsen says, “100KB is certainly a reasonable page weight for fast downloads” in ‘Proritizing Web Usability’ (p. 87).
- TrueType fonts range in size from about 10KB to about 100KB (gzipped even smaller). Most web pages carry images that are of similar size.
- CSS 2.0 defines the @font-face command that explains how a user agent should download a font where required.
- @font-face was removed from CSS 2.1 because of a lack of support in existing user agents. (No major web browser implements it apart from support limited to .eot files in Internet Explorer). It is back in CSS 3.0.
- It is a Mozilla FAQ to ask why Firefox doesn’t support downloadable fonts. But the reply concerns unicode and support for non-Latin characters rather than design/typographical issues. Nonetheless, support for @font-face does not seem to be on the Mozilla roadmap.
- Support for downloadable fonts is not the only thing needed to bring print-like type to the web. Current screen resolutions of 72dpi are much less than the 300 dpi or much more of the printed page.
Does anyone know why implementing @font-face seems to be such a low priority for makers of web browsers?
I think there are 3 (2 of them are actually valid) reasons for this.
the handling of fonts differs from operating system to operating system and in most cases this could present an potential security hole. (could be fixed by ‘sand boxing’ but that is difficult)
Some commercial font creators would not be happy see there work being copied whiteouts them being paid (DRM or similar would easily be broken since open source projects would open source there DRM decoding system and once you have that you could redirect it back to save the font DRM free)
TrueType is not an W3C format and knowing the W3C sooner or later they will want to create there own XML formatted font format that will be huge (if not compressed) and we know how good user agent implementors are in implementing W3C standards.
First time visitor, nice site BTW will come back.
If my English grammar and spelling is bad please tell me but don’t flame me it’s not my first or second or even third language.
because most fonts are copyrighted and sold commercially. having your website upload a TTF file to all clients automatically is largely impractical since in most cases it would be illegal.
Leaving aside the rights and wrongs of Intellectual Property which has been discussed to death elsewhere, I can see where you two are coming from. But if Firefox (or other browser) implemented @font-face I couldn’t see the Mozilla foundation being sued by Adobe (or whoever). Only the disseminators of fonts would receive the cease and desist letters. Firefox could (quite legitimately) claim that they mean the feature only to be used with fonts that it is not illegal to disseminate freely. Perhaps the free fonts of this world aren’t up to much. I’m not much of a designer myself but I’ve always been able to find free fonts for my purposes. I would have thought designers would apprectiate the facility even if it was limited to free fonts only.
The issue with TrueType not being universal is interesting. The W3C standard for TrueType does allow for the specification of various fonts of different file type: http://www.w3.org/TR/REC-CSS2/fonts.html#referencing (example includes TrueType!) Also, Firefox (to pick the most obvious example) targets three OSes, all of which support TrueType.
I’m not sure exactly what you mean about the security hole. Just that a different file might be pointed to, possibly containing malicious code? That’s certainly possible but that’s also the case with images, style sheets, etc. so that’s something the browser makers will surely have dealt with before. Perhaps I misunderstood that bit.
The FAQ you linked to also mentioned patent concerns.
Security-hole wise, the operating system itself usually is in charge of rendering text. And operating systems have been designed usually with the assuption that fonts would be something that would be locally installed. Once you start passing a file you got somewhere on the internet to your OS, you start to find all sorts of security problems in the OS.
We computer people are still really far from getting this kind of stuff right. A hole was recently fixed in an image rendering library that’s widely used by browsers, and all kinds of other software. The hole allowed a correctly crafted image file to execute code on your computer. And the image rendering library was already designed under the assumption that it would be handling all kinds of random data from the internet.
Yes, I can see that might be a problem. In my naivety I imagine that a font is not that complicated a file and thus ensuring it’s secure-ness within the browser before passing it on to be rendered might not be that hard. But yes, I can see that it might be unpleasant and not the kind of thing a Mozilla developer would rush toward with open arms. Doing that kind of thing does rather go with the territory of being a web browser though, doesn’t it?
Call me naïve, but I don’t buy any of those arguments against @font-face.
Making a font downloadable through a browser looks as legal as putting embedded in a PDF, yet Adobe seems to have no problem. As pointed above, it’s the webmaster responsability to only put legit content on its site, be it photos, text or fonts.
The three more important OS support TrueType fonts, and for the OS out there that don’t support them you have a pretty easy fallback: render the text with a system font.
As per the estability argument, a crash due to a malformed font is already handled as a bug on any system, just as you handle bugs on image libraries. It’s not like there are tons of bugs in the font handling libraries, there are right now suppossed to not load malformed fonts, not to crash on them.
The Mozilla FAQ only addresses the point of people that want to use alternative fonts to display international glyphs, and fails to mention the very legit use of people that want to use custom typography for their titles. The widespread use of sFIR has already proved such a need is very real.
There is also a potential missuses by having lot’s of fonts download even if individual fonts files are small if you would have an hundred or thousand font files download the system could potentially choke on the workload of registering and loading the fonts.
Putting an hard limit on this is not a solution because there is this real chance that if you do that (have an arbitrary hard limit) your most profitable client will wants to use exactly [HARD LIMIT] + 1 font.
@ Thomas David Baker
Well the security hole I’m thinking of would be more akin buffer overflows, where you would send big font files that could overflow the buffer of the font handling sub-system and so cause arbitrary code to run.
What compounds potential problem is the fact that in Windows there is no real way to handle fonts on an user level (that I know of). You register (copy) fonts to an central system repository and they become available to all (thus my believe that if you can inject code while in the font handling sub-system and/or the drawing subsystem, you can cause damage to the system and not only to the running user even if the user is not set as an “administrator
The security concern is somewhat more complex as TrueType is a programming language which outputs rendered glyphs. I guess that PostScript fonts are also executed.
My vote is security concerns. Any time you allow arbitrary content to be downloaded and executed in a users browser you invite a slew of holes.
I’m sorta surprised that the W3C removed it in CSS 2.1 though, because they don’t seem too dependent on other standards from being implemented to keep them in the spec. See outlines, :focus, and the other CSS 2 font properties.
Why not use sIFR?
I don’t know much about sIFR but I think it is true to say that sIFR is a hack. It requires flash and javascript that is turned on. It is not part of any standard. You can’t put your body text into a particular font using sIFR (I don’t think), only headings. This would be a much better solution as I’m sure the authors of sIFR would agree. They only use sIFR because it works now not because it is The Right Thing(tm).
Kirit is right, because of kerning and unusual things like that fonts are more than just vector images, but contain little executable subroutines. That said, there is no reason that these difficulties can’t be overcome. Flash, java, etc. are also executable. The operating system just needs to sandbox them.
I don’t think there’s an IP issue. Fonts could be stored in the browser cache and not installed generally to the system — this method has worked for everything else copyrighted on the web.
Eventually it will happen, but when, I have no idea. I bet support could be hijacked into existing browsers via plugins you only need to install one time (like the Flash player).
Security and patent implications aside, I think Kurt’s point regarding the system choking on a font overload has got to be a biggie. As a designer I have a lot of fonts on my system, and in the past I have had problems with my system crapping out because there were toooo many. Just imagine how many there could be if @font-face was implemented – and how would you control that? The fonts directory on windows eg is a system folder – ‘delete offline content’?? Ooh I don’t think so..
It could just treat fonts like it treats images. Store them in the cache and delete them when it starts to run out of room. A font doesn’t have to be installed system-wide to be used by a single application, just to be accessed by all the others (which, as you say, may be undesirable).
T.D. Baker is ritght. Actually, this is how IE handles EOT files today. Furthermore, this is the only legal option for fornt which allow embedding but not free distribution.
As a type designer and font developer/vendor, I would love to see a FOSS plug-in to use the @font-face rule in *any* browser. I suspect some interesting pork-belly activity got that yanked in CSS 2.1, and am really surprised that the Mozilla foundation hasn’t at least roadmapped it to trump the competitors.
Between OpenType, TrueType, PostScript Type1,2 and 3, MM, AAX, Metafont and SVGFont, there are a lot of potential formats out there today, as well. And all but one are proprietary, which complicates things. To be practical and idealistic I’d pick OT and whatever more typographically-mature Free solution grows from SVGFont, if any.
Caching and sandboxing the font data is a relatively simple task. However, it would be a lot more work than one might first imagine to create an internal (not os’s resources-dependent) system that would do everything required to place the glyphs (visual representations of the letters) in the right way, respecting the font’s security flags, scaling tables, kernings (individuals, classes and tables!), substitutions, contextual alternates, and all those other modern font goodies. Those things are usually still done for other applications (even when they use their “own” fonts), in part by the OS.
Choz Cunningham
!Exclamachine Type Foundry
Well, right out of the gate, click my name above – I use @font-face extensively on my site, in various places – my @font-face test page is actually also my contact page, there’s all sorts of @font-face trickery there. Of course, currently, this will only show up in WebKit (and therefore, Safari 3.1). I am a hardcore typophile as well as a sometimes web designer, so I can’t express how excited I am to see a chance for astute typographical works to come to the web through @font-face.
For those worried about intellectual property – don’t be. This is a technical implementation, to allow better design on the web – it’s not meant to be a way for somebody to illegally share your font. If you were a photographer (as I also happen to be) instead of a typographer, somebody could still digitally download your picture (as a JPEG, or whatever format it happens to be in) from a site that has been allowed to use it by yourself, and then upload it to their server and link it to people if they felt like distributing it without permission. It’s not the <img> tag’s fault. The same applies to fonts – I could easily upload a font file I don’t have the rights to use to my own server, and then distribute it… this has nothing to do with the CSS @font-face feature in and of itself. Now, of course, common implementation of @font-face will cause there to be many, many, many more people uploading fonts they legally bought to their server, without knowing any better than to do so – even though such is illegal. I understand reservations because of that, but it’s important to set them aside and move on. Sure, photographers might be a bit happier if there was no <img> tag, right? General people would be much less likely to ‘steal’ their image and post it on a forum or their little blog or something, not knowing any better than to do so. But did we not implement <img> because of this? No, we have <img>, and it’s a central part of the web designer’s arsenal. @font-face should, and will, be the same – if we let it. And we should.
Also, to pimp somebody I see as a great corner-stone of the @font-face movement… you all should check out Jos Buivenga. His work is not only absolutely stunning and free, but also (after an extended e-mail exchange with him by yours truly) released for use on the web with @font-face! I believe his are some of the first typefaces to be specifically so released, and I really hope to see them widely used as CSS @font-face gains better support. Of course, the terms are a bit more restrictive than I’d like (have to link to the font’s page from the footer of any page you use the font on), but hell – it’s better than absolutely anything else out there (except the bitstream vera fonts, of course, as they’re totally open source), so I can’t raise any complaints!
To others considering releasing their already-free fonts use for @font-face use – here’s my suggestion for use terms. If you want yourself credited, consider requiring your name and the URL to the font or your site be included in the CSS file, proximal to the @font-face declaration itself. My argument is this – anybody who wants to ‘steal’, or (if it’s legal) ‘retrieve’ a font they like from a site they’re visiting, they aren’t going to go digging in their browser cache (do you do so when you see an image you like on a site?). They’re going to view the page source, copy the link to the CSS file, and open it separately, thus obtaining the link the browser is using to grab the typeface before rendering. If your information is right above the @font-face declaration in that file, 99% of people interested in the font will be redirected to your page! This is much more reasonable, in my opinion, than requiring a link on the page itself. I don’t even include a link to myself on most of my pages, it’s far too much clutter. Maybe some people like fat footers, but most designers (and these are the ones that will be using your typeface, in all likely hood) will be put off by the bloat required for a return link.
tl;dr @font-face is AWESOME!