SiteExperts.com Logo Home | Community | Developer's Paradise | Jobs
User Groups | Site Tools | Site Information | Search

Inside Technique : Legacy Data and the Web: Getting Fonts to the Web!
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

Legacy Data and the Web Series
Part 1: Steps to a Successful Marriage
Part 2: More Steps to a Successful Marriage
Part 3: The Adventure Continues
Part 4: More fun with objects
Part 5: Pulling it all together!
Part 6: Getting it to the Web!
Part 7: Getting Graphics to the Web!
Part 8: Getting Fonts to the Web!
Part 9: WAPping it to the Web!
Part 10: Finding Font Solutions in Your Legacy-to-Web Adventure!
Part 11: Do your documents want to go to the web?
Part 12: Evaluating when documents need reformatting.



Legacy Data and the Web: Getting it to the Web!

FONT. The four-letter word of the information delivery industry.  Oh, I know.  You thought it was network or backbone or router, but those are technical issues that generally have tangible answers. FONT, on the other hand, is that hardest of problems because everyone sees things just a little bit differently.  Corporations have favorite fonts, logo fonts, and corporate image fonts. But before we delve into their mysteries, what do we mean by that dreaded word FONT?

At the baseline it is the concept of applying a unique design to each letter, number and symbol in an alphabetic set. This gets a bit tricky when you are talking about fonts that incorporate graphic elements or portions of a corporate logo, but you get the idea. The font is the unique combination of characters, and in our world of printing and viewing, they are manifested in a file we usually call a font file. Sometimes this is a set of font files which go into making up what actually displays on the screen. There is a long and involved history of why we use the terms FONT and TYPE, and if anyone is really interested, drop me a note and I can point you to references. 

Fonts we use come in a variety of flavors. Some font files contain a bitmap image of each character with the appropriate amount of space left above, below, and beside the character to make it display or print as needed.  Other bitmap font files contain no additional space around the characters and anticipate that the software that uses the font will fill in that detail.  Because bitmap fonts contain the actual images of each character you must have a separate font file for each size typefont you require. Still other fonts are stored as a program of vectors which cause the image of the characters to be drawn as needed. Because these are scalable you need fewer files to convey the needed typefonts to the paper or screen.  

Here is where we develop a problem in moving legacy data and having it appear in the new media in the same manner as it appeared in the old media (paper!). Font files developed for printing on high-speed laser printers (or even older impact printers) relied on developing the characters as bitmap fonts. The simplified version of font history is that they restricted the number of fonts available for printing due to memory considerations on the printer CPUs and disk space available on the printers or their support CPUs.  Each manufacturer had their own set of fonts, and if you printed on IBM printers you used their fonts, and if you printed on Xerox printers you used their fonts. Because the IBM fonts were originally developed for 240 dpi printers and the Xerox fonts for 300 dpi printers you didn't find too many similar fonts across the environments. By the mid-to-late 1980's there were many more shops trying to develop multi-vendor print solutions which gave birth to a number of companies and tools for making fonts available on alternative devices.  The truth is that many of the 240 dpi fonts did not translate well to 300 dpi, nor did the 300 dpi fonts translate well to the 240 dpi environment. To this day in multi-vendor print environments you will see some differences in the character shapes, intercharacter spacing, and even the line spacing for documents printing in both worlds. 

Enter delivery to the screen. Now, instead of having 240 dots per inch or 300 dots per inch to work with, we have a nominal 72 dots per inch to work with and a vast array of display devices, video drivers and screen sizes. Is your view intended for a 640x480 low end VGA screen or a 1024x768 high end SVGA screen, or something in the middle? And depending on the fonts used in your corporate documents and the nature of your corporate logos you may find that representation at such a low resolution is somewhat disappointing.  

You may also find that your corporate fonts have no real equivalent in the display world, either viewing the datastream in its native mode in a Windows environment or on the Web using a browser. Xerox P0612B is not a standard Windows font, and neither is Sonoran Serif or GT10. In fact, if your documents rely on the use of fixed pitch font for spacing you may have an even bigger shock since there is really no such thing as a fixed pitch font in the Web world. 

So what can you do? First things first.  Identify all of the fonts you use in your corporate environment.  This goes back to those lists we made at the beginning of our adventure. Identify how many fall into the category of  printer-specific fonts supplied by the vendor.  Then identify the fonts that appear to have Windows equivalents. Those are fonts like Helvetica, Time Roman, and Courier. If you have a font/type expert on board they can probably help you through the strange mappings like using Helvetica for Helios or Optima for Oracle. Sometimes very similar fonts have a number of names depending on the type foundry they were acquired from.  Remember that for legal purposes fonts are copyrighted entities. 

Now we have the hard part. Look carefully and try to determine how important a specific font is to your documents. If you transform your Xerox or AFP print file to HTML or PDF, but it looks jagged, uneven, or spotty using your desired font, would it really hurt to change to a more web-friendly font? 

What are your options? Not too many, though they are getting better over time. Today you could distribute an embedded font in a PDF file to guarantee that the font you want used actually displays on the viewers screen. Or you could use one of a number of proprietary technologies to embed fonts into HTML files. Microsoft, Bitstream and others have a number of interesting ways to ensure that you have the font image you want.  Of course, if the font you want just doesn't look good on the screen you still have that tough decision.  As a rule the pseudo-sans serif fonts like Optima and Oracle do not look as good when translated to the web. You'll find that corporate logos with fine detail may not look as good as you'd like either. 

So, FONT. The four letter word. No magic bullets. No easy answers. This one is going to be a judgment call. Remember to look at all of the screen variations. 

What's next? Tips on getting to the new devices like WAP Phones and PDAs.  As always, send your questions to siteexpert@mcgrewmcdaniel.com.

Copyright 2000 McGrew + McDaniel Group, Inc. 

Discuss and Rate this Article