The available fonts are limited to the fonts that are widely installed on the computers, that is, you know, such as Arial, Helvetica, Verdana, Times and Georgia. Some of them are even very legible on screen and thus very usefull for webdesign. Others may be preferred, because the users are familiar with them and therefore able to actual read the squiggles. But it’s hard to get a unique typographic identity with that few fonts in the stock.
Anyway, you don’t have to surf the web for a long time to find that there are many welldone typographics out there. Typically logos, headings, menuitems, and sometime even whole webpages are converted to images. As an immediate advance you get control over the proportions of the page (apparentlyat least), and, first of all, it doesn’t matter if the user doesn’t have the font installed. And beyond that limitation, you can do the design, typographic design, as we know from magazines and ads. There are drawbacks, yes, and we have gotten used to them through the years, but they shouldn’t be rejected just like that:
- Pour print quality
- Text can't be edited
- Text is not scalable
The answer to these problems is to use vectorbased fontdescriptions rather that the bitmap conversions. And then to use a format within which the text remains editable as text – though not necessarly editable directly in HTML, but at least in a texteditor. With the standards of today, this means either SVG or embedded fonts.
The main technical objection to SVG is, that it demands a plug-in for the browser, and that it has a unflexible bounding box. If you want to know more about SVG, Adobe’s website is a good starting point.
Font-embedding can be used right away, or: the newest browsers understand and show embedded fonts. You just have to accept, that older versions don't show the right fonts, or that the user might have turned the »allow page to specify fonts« off. These users will still be able to see (and even read) the text, though not in the right dressing.
If necessary, get the SVG-viewer:
Three way to get the font transferred to the users computer:
The filesize does't differ much, weather this text is made as an bitmapimage (here gif), vectorgraphic (svg) or fontembedding (which is vector as well). But the gif-file suffers when printed or enlarged – actually, it can’t be enlarged by the browser at all.
The font embedding file can be used for all text on the whole website, it only has to be downloaded once to the browser’s cache. kan bruges til al tekst på en hel website og skal kun downloades en gang til browserens cache. The text is – as any HTML-text what so ever – editable is you usually HTML editing tool.
The SVG file can be opened in a ordinary text editor and changed just like that. The actual font description you better leave unchanged, but the other parameters are easy to recognize, and at least the concrete text easily changed (given that the new glyph descriptions allready are embedded in the file).
Take a look at the svg-file source here.
The font description, among other the vector curves of each glyph, is generated with a small application, and written to a file that can be linked to the HTML- or stylesheet dokcument. The filesize depends on the design and how many glyphs to be be included. A simple design and about 100 of the most used glyphs (that is capitals, minuscles, nummerals, and punctuations) will take no more than maybe 5-8 kilobytes. And that's all it takes to make a typographical identity for a whole website.
Unfortunately, and typical for the web, we suffer from competing standards. Today there is no standard that covers the whole market. Bitstream’s PFR-format (portable font resource) is the closest, and the application for this format, Webfontmaker, is possibly the easiest to use. The format can be used for both Explorer and Navigator, but not for Explorer for Macintosh, because Explorer need an Active-X component that's not available for Mac. Microsoft’s application WEFT generates an EOT-format (embedded open type), that only is interpreted in Explorer, but then both on Macintosh and Windows.
|The eot-file is being used by Microsoft Internet Explorer (right), the pfr-file by Netscape Navigator (left). Explorer for Windows can be made to interpret the pfr-file, but as the antialiasing is better with the eot-file, you should use this for both Macintosh and Windows. You don’t even have to take any precaution, since the HTML don’t get screwed up with links for both of them in the same document.
But it's really not necessary, because you might as well link to both font-files in the same document, because the browser will ignore the useless code. Thus there’s no reason to actually use the Active-X component that enables Explorer for Windows to understand the PFR-files. The only must is that the font is named the same in the two font-files. And that could be a problem, especially if you have Webfontmaker for Macintosh and WEFT (which is only) for Windows, because the naming differs on the two platforms. More serious is the expense, because you have to have the font installed on both platforms in order to generate the pfr- og eot-filerne – it's hardly the standard fonts that you want to use for font embedding. To avoid buying both version of the font, you may use the application TransType from FontLab for 50 US$ (and this is not a discussion about the licensing problem now).
<link rel=fontdef src="thefont.pfr">
font-family: thefont, verdana, sans serif;
This text is set with the font "thefont".
</html>The code you need in your HTML document to have the font »thefont« embedded.
The red codes are what you need for the pfr-file and eot-file respectively.
The grey code is the needed CSS, to make the <p> tagged text appear with the font (in this case black, 11px/15px thefont).
No need to write this down. Get the HTML-source here.