HTML, XHTML and CSS All-In-One for Dummies - Andy Harris [77]
Say I have a cool font called Happygeek. (I just made that up. If you’re a font designer, feel free to make a font called that. Just send me a copy. I can’t wait.) It’s installed on my computer, and when I choose a font in my word processor, it shows up in the list. I can create a word-processing document with it, and everything will work great.
If I send a printout of a document using Happygeek to my grandma, everything’s great because the paper doesn’t need the actual font. It’s just ink. If I send her the digital file and tell her to open it on her computer, we’ll have a problem. See, she’s not that hip and doesn’t have Happygeek installed. Her computer will pick some other font.
This isn’t a big problem in word processing because people don’t generally send around digital copies of documents with elaborate fonts in them. However, Web pages are passed around only in digital form. To know which fonts you can use, you have to know what fonts are installed on the user’s machine, and that’s impossible.
Part of the concern is technical (figuring out how to transfer the font information to the browser), but the real issue is digital rights management. If you’ve purchased a font for your own use, does that give you the right to transfer it to others, so now they can use it without paying?
Examining possible solutions
This has been a problem since the beginning of the Web. Many people have tried to come up with solutions. None of the solutions are good, but here are a few compromises:
♦ Embedded fonts: Netscape and Internet Explorer (IE) both came up with techniques to embed fonts into a Web page. Both techniques involved using a piece of software to convert the font into a proprietary format that allows it to be used for the specific page and nothing else. The two systems were incompatible, and both were a little awkward. Almost nobody used them. Firefox now completely ignores this technology, and IE can do it but with a separate tool. Until browsers come up with a compatible solution, I don’t recommend this technique.
♦ CSS 3 embedded fonts: CSS 3 (the next version of CSS on the horizon) promises a way to import a font file purely through CSS. You’ll be able to specify a particular filename and pass a URL (Uniform Resource Locator) to the file on your server, and it’ll be used for that particular page but not installed on the user’s system. Custom fonts have been handled this way in games for years. Take a look at Book I, Chapter 8 for a preview of this technology. It looks extremely promising.
♦ Flash: Flash is a vector format that’s very popular on the Web. Flash has very nice features for converting fonts to a binary format within the flash output, and most users have some kind of flash player installed. The Flash editor is expensive, somewhat challenging to figure out, and defeats many of the benefits of XHTML. These disadvantages outweigh the potential benefit of custom fonts.
I’m certainly not opposed to using Flash. I just don’t think it’s a good idea to build entire Web pages in Flash, or to use Flash simply to get access to fonts. If you’re interested in using Flash, you might want to check out another book I wrote, Flash Game Programming For Dummies. In the book, you learn how to make Flash literally sing and dance.
♦ Images: Some designers choose to forego HTML altogether and create their pages as huge images. This requires a huge amount of bandwidth, makes the pages impossible to search, and makes them difficult to modify. This is a really bad idea. Although you have precise control of the visual layout, you lose most of the advantages of XHTML. Content in images cannot be read by search engines and is entirely inaccessible to people with screen-readers. An image large enough to fill the screen will take many times longer to download than equivalent XHTML markup. The user cannot resize an image-based page, and this type of page does not scale well to phones or