It's been coming for a while; been working through the freshen-up exercise, giving the Palm OS (OS 6, Cobalt, one that most people haven't seen) a new look and feel. You can't design a new look and feel without figuring out what fonts to use.
The concept comps have received pretty good feedback. But now that we're getting closer to implementation we need to decide for real what fonts will be included in our open source operating system. Do we update the existing fonts? Pick new ones? Doesn't seem like that hard a task, right? The boss said, "Decide on four fonts that will convey different attitude, will work on mobiles of dimensions from 176x220 up to 5x7 inches, and that you find creatively satisfying. You have a month."
The existing default font is Ocean Sans. We want some fresher selections. While we're validating alternatives, we're using Helvetica Neue in our creative presentations andsurpriseit is the default font for many mobiles. Heh. Got to pick something neutral, something distinctive, something fun, something businesslike. Well. It takes some look ahead and some technical investigation, not just creative chops! Figuring out what to investigate and who to involve took most of the week and involved font vendors, engineers, UX designers, and contract negotiators. And I thought this would be easy! At least we know what the next steps are: Reduce the list of available fonts to what looks good. I can handle that.
Ocean Sans is a fine font, and it was customized by the font vendor to work for small screens and to make it backward compatible from Palm OS 6 (Cobalt) with its predecessor, Palm OS 5 (Garnet). But it doesn't look as modern as we'd like. So we walked through the list of fonts that would work with the font engine we use. We evaluated them for general feel and tested them out in actual layouts and visual design concepts. This week we like Utah and Albany. Next weekwell, that probably depends on my mood.
It turns out that we can use both TrueType and OpenType fonts. Foreign typefaces, including multi-byte character languages, use OpenType.
Requirements are coming out of the woodwork. The fonts we choose have to meet EFIGS requirements: English, French, Italian, German, Spanish. It's a lot more than a, b, c... So when we need a font customized, we have to think about more than just letter forms; there's a lot of diacriticals and hinted letterforms so that the fonts look right at multiple sizes. The total number of different letterforms (boxes) for a font that supports EFIGS is approximately 218, give or takesurprising! Customization is time-consuming, detail-oriented work; we hope we won't have to have too much of it done.
Of course the font vendor wants specs. Why me? I'm the creative guy; I just want to choose something that looks nice. Okay, I understand it's not that simple; fonts have to look nice and crisp and readable at a variety of sizes. Most fonts were not designed to do this; many can be customized, but some absolutely won't scale down to the sort of dimensions we're talking about for mobile devices. Scaling up is not a problem, but scaling down produces blurry letterforms requiring hand-tuning, or "hinting," at various sizes. But verifying that things look nice isn't as easy as you might think. This week I had to review fonts to ensure that we could use the ones I like on a variety of small screens. And I discovered that you can't do this kind of testing on a desktop machine; you have to test it on the actual device because the lighting and pixel densities (PPI) are much different.
So off I went to show our visual design concepts to engineers where I discovered that there is not a very long list of fonts available, nor language support, for open source fonts. And the ability to turn anti-aliasing on and off (for small font sizes and screens) will depend on the font rendering engine. Am I back to last week's tasks? More requirements...
Reviewed fonts. And more fonts. Printed out samples. There's a lot of variety, but many are designed for print and re-engineered for use on small screen devices. At least they all work. But the ones we liked the most, after looking at many fonts and font foundries, didn't fit all of our technical criteria. Font vendors of course know all the details about their fonts (including whether what we're looking at was designed and tested on small-screen LCD devices), but unless they sense a good solid deal coming their way, they won't give free advice!
So in order to offer customizability to our platform licensees, we need to have at least three, probably four fonts. And they need to have different "feels" to them. So we decided all have to be extremely readable in very small sizes. The default will be very neutral; one for business attitude; one for casual attitude; one just because it's different and edgy. Oh boyedgy fontsthose angles and curves really don't scale down! And then there's the font family to consider: We decided each font family should include normal, bold, italic, bold italic, condensed. So there's some progress...
So this week we talked to three different font vendors. One had the edginess but little testing or design focused on small screens. Another didn't seem to know much about small screen devices, and gave useful (if general) criteria to look for; but they didn't understand the constraints of small screen (tiny text!), low-resolution (no anti-aliasing!) devices.
So back to the requirements document...
So finally, after doing all of this upfront research I feel like we are making some progress. A font vendor will be visiting our company to meet with our engineering staff. I've been told that we could join in that meeting to discuss our preferences for font designs after the engineers talk about their technical issues. When selecting a font for a small device, there are so many different teams involved in making a final decision that it is best to get them all in the same room at oncedesigners, engineers, licensing negotiators, font vendor, etc.
I have to hurry up and finish and format that requirements document to communicate to our vendor what we are looking for and to communicate to our internal people why we want to choose a different font to begin with. I'd better get back to the requirements document (again) and prepare some type samples...
We met a team of font vendors with mostly technical backgrounds. Choosing a font for mobile devices is mostly about technical issuesreadability, font metrics, language requirements, etc.
We talked about selecting Asian multi-byte characters. One of the font vendors explained that the minimum size needed (box height) to render a Chinese font is 14 pixelsimportant to know for Asian screen layout. He also introduced the concept of stroke fontsthese are fonts that consist of single strokes rather than an external outline. When used with Asian languages with thousands of characters, this results in huge file size savingsand mobile devices usually do not have a lot of internal storage, so it's important to keep the font footprint small.
Now we need to talk to a vendor's internal font guru to talk strictly about design and readability issues in selecting fonts for handhelds. I'm curious what special knowledge he has?
I learned the more requirements that you can write, the better your vendor can narrow down the list of font candidates so you don't fall in love with a font you can't use. That's the great thing about working with a vendorlet them do some of the work for you!
We're going to use a single vendor for all of our technical and font design needsit'd be a nightmare to use multiple vendors given all the different teams that need to work together!
More new requirements. Not only do the fonts we choose need to be able to work in all European languages, work with our technology, look cool, be readable, and do back flips, but also whatever we choose must look good both anti-aliased (or with smoothed edges) and non anti-aliased. I'll add that to the list as well and make sure to reevaluate our preliminary default font candidate. Luckily, our font vendor sent us a font simulator that shows how the fonts will render on devicevery, very different (better) than how Photoshop renders them!
ARGH! Now I hear that we are not sure what font engine we are using. If we choose fonts from our current vendor we need to be sure the font will work with the font engine that works with our open source platform. If we go with our current font vendor they can provide us with the fonts as well as the font-rendering engine and even test it for us. In theory, any TrueType font will work with any font engineor so I am told.
We are now able to make final font recommendations to the rest of our team. We know what fonts we can choose fromabout 300 and not 30,000. We have also developed a good sense of what is readable on a small LCD device. We decided to go with a font that is clean and modern looking and at the same time readable for the size and amount of text we will be displaying. With the help of our font vendor type gurus Desi Leyba and Allan Haley of Monotype Imaging (his title is Director of Words and Lettershow cool is that for a title?!) and our internal team, we choose three font families in addition to a default font for use in future customizations. Time to compile all of these recommendations together in a document so we can see how much this is going to cost!
Not all of the fonts we selected are available "off the shelf." And some are more work to hint than others. Some have been pre-hinted a bit for other clients, but every device requires the fonts to be fine-tuned for your particular LCD specifications. For a platform, it's hard to guess what displays your software will eventually use. I have been introduced to another new termfont Height Optimization. With a bitmap font, a 16 PPEM (pixels per em) bitmap is contained in a space of 16 square pixels. However, with scaleable fonts and European accents things can fall out of that space and be cropped when rendered on the devicevery bad.
Things have finally come close to the end. People are leaving me alone instead of saying "Where are those fonts?!" The vendor is busy preparing estimates and getting ready to do some font designing for us.
Are you selecting fonts for mobiles? My recommendation: Learn from my lessons and have fun! Selecting fonts can be very laborious, but you will gain a great deal of design and technical knowledge that will make you see the fonts differently afterwards. Following are some type samples for fonts we think work well on mobile devices.
As our licensing negotiator Larry says: May the fonts be with you!
Thanks to Philip Kim, UX architect, and Elizabeth Dykstra-Erickson, senior director, product concept and user experience, for their helpful comments on this articleand their relentless encouragement to keep this project going. Grateful thanks also to Allan Haley and Desi Leyba of Monotype Imaging for all they've taught us about fontsand especially, that they don't come straight off the shelf!
About the Author:
Joshua Larrabee is a visual designer at PalmSource, Inc., an ACCESS Company, in Sunnyvale, California. PalmSource, Inc., a wholly owned subsidiary of ACCESS Co., Ltd, is the Company behind Palm OS, a leading operating system powering mobile devices and phones. ACCESS is a global provider of mobile content delivery and Internet access technologies to the beyond-PC market.
Box height: the amount of space (or cell) usually measured in ppem (or pixels per em) that it takes to display any character in a font face including ascenders and descenders.
X-height: the height of the lower case letters in a font and is typically, but not always, the height of the lower case "x."
Ascenders and descenders: The portion of a letter that extends beyond the mid-line of a font is the ascender. For example, "d" and "b" both have ascenders. The portion that extends below the baseline (or the line on which fonts sit) of a font. For example, "g" and "q" have descenders.
Bowls, stems, and strokes: The bowl is the curved part of a letterform in letters such "d," "b," or "o." The stem is the vertical stroke of a letterform. The stroke is the overall width of the lines (or strokes) that comprise the various letterforms in a font.
Hinting: This is the technical process of adjusting a font outline so that it will display without distortion at a specific pixel grid size. Hinting is especially important when rendering fonts intended for high-resolution print use at small size on a low-resolution screen.
Font engine: On a handheld device, a font engine is the behind-the-scenes software used to determine how to render and display (or rasterize) an outline or stroke-based font on screen.
TrueType: This is an outline font standard developed by Apple Computer in the late 1980s as an alternative to other font formats. Additionally, it allows font developers more control over how individual TrueType fonts are displayed.
OpenType: This is Microsoft's scaleable computer font format introduced in 1996. OpenType also offers language-related options and support.
Rasterizer: A font rasterizer is a piece of behind-the-scenes software that generates bitmaps by reading the outline description of a font file.
Double-byte languages: Because of their visual complexity and number of characters, languages such as Chinese or Japanese require two bytes of information to display each character.
Strokes and Outlines: With stoke-based fonts, the points that describe a character are placed along the edges of a letterform, whereas with stroke-based fonts, the points are placed along the center line of a letterform using fewer points to describe the letterform.
"Stroke" is usually considered to be a single part of a character as in "diagonal stroke of the K." Stroke-based fonts do not display as nicely as outline-based fonts, but they are ideal for Asian languages when used on a mobile device where there is limited disk space.
PPI: In the LCD display world, this means Pixels Per Inch. Most desktop monitors have a display resolution or 72 or 96 ppi. Handheld devices can have 96 ppi displays, but often have much higher display resolution.
PPEM: This means Pixels Per Em. An em is typographical unit of measurement meaning the size of an imaginary square needed to display a font's letters separately. The term comes from the width of a capital letter "M" in a particular font.
Height Optimization: Font height optimization is technology used to make sure that an individual character in a font will have all of the space it needs to be displayed properly, without cropping things such as ascenders, descenders, and diacriticals.
Test fonts on an actual device on your target LCD or something verifiably close to that. Test on a font engine simulator or the actual font engine to see how fonts render at various sizes. Photoshop and other programs use a different font engine and thus will not generate the same results.
Narrow down your list to fonts that meet your technical and readability requirements before falling in love with a font that will never work with your font engine. This will save you from looking through thousands and thousands of fonts and give you a more manageable list to review.
Leverage any help you can get from a vendor if that is possible. They can provide technical and design expertise, saving you a great deal of time.
Consider condensed and semi-condensed fonts to fit more characters on small screen devices. Think about screen real estate; test to see how many characters will fit on a row of text for your device's resolution and dimensions.
Evaluate the font non-antialiased in addition to antialiased if you plan to use the font on very small, low resolution/low color displays.
Make sure the lower case characters of the font have a large enough x-height so that they are readable at small type sizes.
For Asian languages, make sure that you can use stroke fonts (as opposed to outline fonts) with your selected font engine if designing for devices with limited storage capacity. Storage requirements can be reduced by 90 percent or more (over outline fonts) with stroke based fonts.
©2006 ACM 1072-5220/06/0700 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.