Bitmapped fonts

Bitmapped fonts consist of a series of dots or pixels representing the image of each glyph in each face and size.

Overview

Bitmapped fonts, also know as bitmap fonts, are created by building a rectangular image to represent a character. This was the method used in all early computer systems and even printers used on home computer systems called dot matrix printers. Today, most alphabets used on computers, are built using the outline fonts as described in the article entitled Fonts, however bitmapped fonts continue to be used in some areas such as the command line interface. Adobe called these type 3 fonts. While most implementations of bitmapped fonts use a mono-space font style with all characters and spaces taking up the same horizontal number of pixels, this need not be the case. Bitmaps are also termed binary images since the defined shape is done using only binary values. A pixel is either on or off.

Bitmapped fonts versus Outline fonts can be compared to the difference in graphics systems, bitmap vs. vector. Bitmapped fonts are faster and easier to use in computer code, but inflexible, requiring a separate font for each size and each face. Outline and stroke fonts can be resized using a single font and substituting different measurements for components of each glyph, but are somewhat more complicated to use than bitmapped fonts as they require additional computer code to render them.

Even if the main alphabet uses outline fonts the special characters may use bitmapped fonts when the nature of the character is more graphic and can't be scaled easily. Bitmapped fonts may also be used if the font set does not contain the character that is needed. A bitmapped image can be inserted as an inline graphic directly in the text. This can have mixed results if the font size is changed but generally the eBook reader will try and scale the image as well.

While, in general, font attributes require a different glyph there are some exceptions. For example Apple emulated bold in one set of fonts by simply doubling the pixel width on the vertical lines. Others have done this on all fonts to lower the bandwidth requirements for the signal sent to the screen. This was done is some early computers that used a TV for a screen.

Bitmapped fonts are not only rendered quickly on a screen due to just displaying the pixels themselves as an image but they also provide very predictable results since they always exactly match the pixels on the screen. Having grayscale bitmaps even allow precomputed anti-aliasing to soften the angled edges and curves.

Font sets

Windows Codepage-437

Some font sets have been standardized.

• Microsoft Windows bitmapped font (FON) shown at right in 8x16 version.
• Portable Compiled Format (PCF) is a bitmap font format used by Xserver in its core font system, and has been used for decades. PCF fonts are usually installed, by default, on most Unix based operating systems.
• Glyph Bitmap Distribution Format (BDF) by Adobe is a file format for storing bitmap fonts. It was designed to be both human and computer read.
• Server Normal Format (SNF) is a bitmap font format used by X Window. It is one of the oldest X Window font formats. It is no longer used.
• PC Screen Font (PSF) is a bitmap font format currently employed by the Linux kernel for console fonts.

This font is sometimes referred to as ANSI or extended ASCII.

NFNT Resource

Initially all bitmapped fonts in a set were the same size, however as the need for fonts that matched the variable typset fonts there needed to be a way to describe the font set and thus a font resource was born. The NFNT (New Font Numbering Table) resource became the standard for early macs and palm units but this has now been merged into the new container specification talked about under fonts.

The resource provided a way to describe the entire family and a structure for describing the individual glyphs.

The bitmapped font header component consists of the elements listed below, each of which corresponds to a field in the FontRec data type.

• Font type. An integer value that is used to specify the general characteristics of the font, such as whether it is fixed-width or proportional, whether the optional image-height and glyph-width tables are attached to the font, and information about the font depth and colors. This value is represented by the fontType field in the FontRec data type.
• First character code. An integer value that specifies the ASCII character code of the first glyph in the font. This value is represented by the firstChar field in the FontRec data type.
• Last character code. An integer value that specifies the ASCII character code of the last glyph in the font. This value is represented by the lastChar field in the FontRec data type.
• Maximum width. An integer value that specifies the maximum width of the widest glyph in the font, in pixels. This value is represented by the widMax field in the FontRec data type.
• Maximum kerning. An integer value that specifies the distance from the font rectangle's glyph origin to the left edge of the font rectangle, in pixels. If a glyph in the font kerns to the left, the amount is represented as a negative number. If the glyph origin lies on the left edge of the font rectangle, the value of the kernMax field is 0. This value is represented by the kernMax field in the FontRec data type.
• Negated descent value. If this font has very large tables and this value is positive, this value is the high word of the offset to the width/offset table. If this value is negative, it is the negative of the descent and is not used by the Font Manager. This value is represented by the nDescent field in the FontRec data type.
• Font rectangle width. An integer value that specifies the width, in pixels, of the image created if all the glyphs in the font were superimposed at their glyph origins. This value is represented by the fRectWidth field in the FontRec data type.
• Font rectangle height. An integer value that specifies the height, in pixels, of the image created if all the glyphs in the font were superimposed at their glyph origins. This value equals the sum of the maximum ascent and maximum descent measurements for the font. This value is represented by the fRectHeight field in the FontRec data type.
• Offset to width/offset table. An integer value that specifies the offset to the offset/width table from this point in the font record, in words. If this font has very large tables, this value is only the low word of the offset and the negated descent value is the high word. This value is represented by the owTLoc field in the FontRec data type.
• Maximum ascent. An integer value that specifies the maximum ascent measurement for the entire font, in pixels. The ascent is the distance from the glyph origin to the top of the font rectangle. This value is represented by the ascent field in the FontRec data type.
• Maximum descent. An integer value that specifies the maximum descent measurement for the entire font, in pixels. The descent is the distance from the glyph origin to the bottom of the font rectangle. This value is represented by the descent field in the FontRec data type.
• Leading. An integer value that specifies the leading measurement for the entire font, in pixels. Leading is the distance from the descent line of one line of single-spaced text to the ascent line of the next line of text. This value is represented by the leading field in the FontRec data type.
• Bit image row width. An integer value that specifies the width of the bit image, in words. This is the width of each glyph's bit image as a number of words. This value is represented by the rowWords field in the FontRec data type.

The glyph data component of the bitmapped font resource consists of five tables that describe the glyphs in the font.

• Bit image table. The bit image of the glyphs in the font. The glyph images of every defined glyph in the font are placed sequentially in order of increasing ASCII code. The bit image is one pixel image with no undefined stretches that has a height given by the value of the font rectangle element and a width given by the value of the bit image row width element. The image is padded at the end with extra pixels to make its length a multiple of 16.
• Bitmap location table. For every glyph in the font, this table contains a word that specifies the bit offset to the location of the bitmap for that glyph in the bit image table. If a glyph is missing from the font, its entry contains the same value for its location as the entry for the next glyph. The missing glyph is the last glyph of the bit image for that font. The last word of the table contains the offset to one bit beyond the end of the bit image. You can determine the image width of each glyph from the bitmap location table by subtracting the bit offset to that glyph from the bit offset to the next glyph in the table.
• Width/offset table. For every glyph in the font, this table contains a word with the glyph offset in the high-order byte and the glyph's width, in integer form, in the low-order byte. The value of the offset, when added to the maximum kerning value for the font, determines the horizontal distance from the glyph origin to the left edge of the bit image of the glyph, in pixels. If this sum is negative, the glyph origin is to the right of the glyph image's left edge, meaning the glyph kerns to the left. If the sum is positive, the origin is to the left of the image's left edge. If the sum equals zero, the glyph origin corresponds with the left edge of the bit image. Missing glyphs are represented by a word value of -1. The last word of this table is also -1, representing the end.
• Glyph-width table. For every glyph in the font, this table contains a word that specifies the glyph's fixed-point glyph width at the given point size and font style, in pixels. The Font Manager gives precedence to the values in this table over those in the font family glyph-width table. There is an unsigned integer in the high-order byte and a fractional part in the low-order byte. This table is optional.
• Image height table. For every glyph in the font, this table contains a word that specifies the image height of the glyph, in pixels. The image height is the height of the glyph image and is less than or equal to the font height. QuickDraw uses the image height for improved character plotting, because it only draws the visible part of the glyph. The high-order byte of the word is the offset from the top of the font rectangle of the first non-blank (or nonwhite) row in the glyph, and the low-order byte is the number of rows that must be drawn. The Font Manager creates this table.

eBook Fonts

Bitmapped fonts are used in some of the Hardware Readers in use today. The eBookwise-1150 and the REB 1200 as well as many others use bitmapped fonts. Other systems such as the Bookeen Cybook Gen3 use TTF. PDAs depend on the host system to determine the font system in use.

For more information

• NFNT Font resources - an older system developed by Apple and used on macs and Palm systems.
• http://www.dafont.com/bitmap.php - examples of various bitmapped fonts.
• Here is a download site for bitmap font images.
• http://www.babelstone.co.uk/Software/BabelMap.html is a source of Unicode characters in bitmapped fonts.
• Extended PML character table‎‎ in this wiki shows the use of some bitmapped fonts. These were taken from the wayback machine page which has a few more.