Font Embedding Technology

I have recently succeeded in one of the ongoing experiments I have, with one of the websites that I am maintaining, and still building.

After tons of vague code, and frustrating results, I managed to discover the tricks behind this relatively new technology. But before messing around with the loads of new fonts that are made available by this, you’ll want to know what all the options are. I have given some of the most widely used methods below:

1. PHP – Image Replacement
2. sIFR
3. @CSS font rules
4. WEFT™

---

PHP Image Replacement

PHP Image Replacement is a novel way in which to use fonts that otherwise would not be supported on the end-user’s computer(browser). If you haven’t heard of PHP, you can find out more about what it is, its pro’s and con’s here. PHP is filled with the sort of things that can set your imagination running! Anyway, getting back to font-embedding, this method, uses a PHP script to generate the image of the text, in the desired font, and it is then passed over to an adjoining JavaScript script, that handles positioning and rendering of the image by the browser. Again JavaScript is a common client-side scripting language; for more information, see this.

To see exactly how this works, I would highly recommend this site, which has done a commendable, and thorough job in explaining the in’s and out’s of this exciting technology. Again, if you want to get hands on with the script (as HTML\XHTML\CSS have very little to do with it), follow the links provided above, on information on PHP and JavaScript.

Incidentally, this method of font-replacement is called Dynamic Font Replacement, due to the fact that the images are produced automatically by the PHP script, and text can be changed at any time.
This was the old, most common, and nearly always effective way of going about the great obstacle that is Font Embedding. But Recently, newer, cleaner methods have evolved, from this very same technology. Enter sIFR.

---

Scalable Inman Flash Replacement

Okay, so I’ve gone on about how good PHP Image Replacement Technology is, so why do we have to use other methods of font-embedding? Well, if you tried this method, you would notice that the user cannot access the text that has been replaced, i.e., he is simply not allowed to select the text. Printing this text also becomes a problem, although there are workarounds for this. sIFR or Scalable Inman Flash Replacement. This may sound a little strange – ‘Using Flash…?’, but it is true, it uses a mixture of JavaScript, Flash technology, and CSS to achieve what was till now, impossible to do with the older PHP Image Replacement Technology – The Replaced Text is now Dynamic! The end-user can highlight it, copy it into documents, the developer can use it to make fancy links with; and most wondrous of all, it uses no images!

You may be wondering – ‘Okay, no images…but I thought I saw Flash…?’. You thought right, it does rely excessively on Flash Technology, and a major prerequisite for its implementation would be the same. All browsers that run the script will need Adobe’s Flash Plugin. This is no major drawback, as at least 80% of the multimedia available on the web is based on Flash Technology, so using it is no ‘biggy’. Another concern that jumps up at a prospective developer, would be the size of the flash replacements, and the extra usage of bandwidth whenever it is loaded. Even on this account, it does not pose too much of trouble, as download speeds have only been increasing, and small 20kB files are downloaded, rendered and displayed in a fraction of a second. Okay, so now we have cleared and answered most of our doubts over the viability of using this method, we can move on to actually learning to implement it.

sIFR may pose a few problems to the new web designer, so I have added a link to a website that offers one of the best, minimalistic introduction to sIFR. Basically, sIFR works on the principles of PHP Image Replacement, but without the PHP. It also uses the power of CSS to ‘merge’ in with the website, and with it the font can be scaled according to the dimensions of the element within which it is placed, thus ‘Scalable IFR’. I personally think that this is the best method, both in ease of implementation, and usability, but for the sake of completing the list, I have included two other(future) alternatives: @CSS method, and WEFT™

---

@CSS Font Attribute

Ah. CSS. It all seems as though we are all moving into a web powered by CSS. To anyone associated with the groovy world of CSS, we would have thought the best method to implement fonts is by CSS. After all what are the ‘font-family’ properties for? Well, wrong! The font-family property only just lets you define fonts that you want your text to be like, but it will only do so if that particular font is installed on the end-user’s computer. Very unspecific, and a risky chance to take. Enter the ‘@font-face’ selector. This radical selector allows you to import custom fonts on to your website. If the font is not present in the end-user’s computer, it is downloaded into the font cache, and is made temporarily available. Simple. Oh no it isn’t! There are some major drawbacks to implementing this method, which are:

• This was possible according to the CSS2 specifications (see this)
• This is not possible according to the CSS2.1 specifications (see this)
• The trouble is, that the most browsers don’t support (fully) the CSS2 rules (using CSS2.1 instead), and cannot display the fonts defined by the @font-face {…} rules.
• This will be possible (in the distant future) according to the CSS3 Working Draft, module: Web Fonts (see this)

So CSS seems to be a rather a broken reed to rely upon. If you don’t believe this, try it yourself:

/* Enclose within 'style' tags */
@font-face {
font-family: "font-name";
src: url(font-name.ttf);
}
.ClassWhereItIsUsed {
font-family: "font-name";
font-size: 230%;
}


Just put the above into any webpage, and test its capabilities (which aren’t exactly thrilling). Make sure you have a copy of the font file in the same directory. It does work on certain versions of different browsers, but not for the major ones such as IE and Mozilla Firefox.

---

The Web Embedding Fonts Tool

WEFT™ is Microsoft’s Solution to this, now age-old problem. Like most of Microsoft’s solutions (meaning no offence), it didn’t work out very well. Its been stagnant now for nigh on six years. But, for the sake of completing this list, I have mentioned it. WEFT™ converts True-Type and Open-Type fonts to Embeddable Fonts (*.eot), and uses its own CSS ‘@font-face’ selector for use in websites. And it works. Major Drawback: Only for IE. Apart from the fact that the embedded font loads in IE, it has no other advantage. It seems that it holds only to its trademark products. Anyway, its a moo-point to go on about it, but if you are interested (very unlikely), you can visit the website, here.

So, as this post draws to a distinct end I would like to read any comments/suggestions on this topic, and to let me know if I am incorrect on any point.

Cheers.

Advertisement