The Importance of Fonts
Consider this image:
I clipped this from a tray insert at a fast food restaurant and blurred out the company name to hide the guilty party. Everything else is the same.
This image illustrates one of the reasons that software developers need to understand fonts and need to understand the process of using fonts.
Fonts are resources and should be treated as resources. By that, I mean that if font is used as an element in some context (document, UI), it cannot be guaranteed that it will always be present in the future. In other words, if a user can choose a font for a document, save and close the document, then uninstall the font and reopen the document. At this point the resource is no longer available and the document is not renderable with the user's intent. Mind you, the user created this situation, but it is still up to us to handle it gracefully.
One clever solution is to ship and install "standard" fonts with your product, but there are a couple reasons why this is problematic. The first is that a user can still tank your program by removing the fonts from his/her system. The second is that by installing a newer version of a previously existing font (newer is better, right?), you might be breaking someone else's application as well as pre-existing documents. Either case is bad citizenship.
Another case that is likely to occur is that the document, post-creation, might be handed off to another user on another system without the font in any form.
In all cases, these circumstances are detectable. With the software that made the ad, I suspect that the developer did the lazy thing and just put in question marks for all characters that couldn't be rendered and let it slide -- after all, that's better than crashing right?. This is not a solution. At the very least, the user should be warned that this has happened so that s/he might correct it. In a better scenario, you might offer a wizard to go through every place where an unavailable font was called out and let the user fix that section.
Another option, which most developers ignore is the possibility of fauxing the font. On Windows, you have ready access to the metrics that make up a font, and while they're not the smallest data structure on the planet, they're not that huge and will compress well. Given a set of metrics, it is possible to synthesize a new font on the fly that, at the very least, matches the size of the unavailable font. In the best case, you would also like to match the weight, blackness, and other characteristics of the missing font. The first step - taking a generic font and transforming it into a size-fit copy is straight-forward (and in most cases will look lousy, but at the least the formatting won't change). The next step, trying to match the feel of the original font, is substantially harder. For this you need a font rendering technology that has more dimensions than simply size. OpenType (and its predecessor MultipleMaster) provide that.
Further, if you're going to the trouble of saving the metrics (and you should), you can save font version information as well. A standard sanity check for any application that depends on fonts should be to
- verify that the font is installed on the current computer
- verify that even if the font is installed that it is identical (ie, same version and even with the same version, does it have identical metrics)
- alert the user and/or faux the missing font
In this particular example, there was also one more missing step in the process: nobody cared to proof the final document before committing it to dead trees.
Personally, I think all developers should take an interest in fonts and typography. If you're looking to learn more, you might consider reading Stop Stealing Sheep & Find Out How Type Works.